NoSQL的必要性和效率成本分析Word文档下载推荐.docx

NoSQL的必要性和效率成本分析Word文档下载推荐.docx

《NoSQL的必要性和效率成本分析Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《NoSQL的必要性和效率成本分析Word文档下载推荐.docx（12页珍藏版）》请在冰豆网上搜索。

那个名称和概念都由此而来。

　　有些人反对NoSQL术语，因为它听起来像我们定义自己是什么.在一定程度，但长期仍旧是有价值的，因为当一个关系数据库是唯独的工具，你明白，每一个问题，看起来像一个大拇指。

NoSQL是让人们明白有其他选择哪里。

但我们并不反对关系数据库，因为当这确实是工作的最正确工具.

　　一个与NoSQL名称真正关注的是，它是一个专门大的帐篷，有专门不同的设计空间。

假如这不是在讨论清晰的，它在各种产品纷乱的结果。

因此，我要建议沿着三个轴的摸索专门多数据库选项：

可扩展性，数据和查询模型和持久性的设计。

　　前所未有的数据量正推动企业关注传统的关系数据库技术，已服务了30多年良好替代品。

总的来说，这些替代品已被称作〝NoSQL数据库。

〞

　　最全然的问题是关系数据库不能处理专门多数据量。

有三个具体的问题：

扩大向像Digg新闻评论网站的（3TB绿色徽章）或Facebook的（50TB收件箱中的搜索）或EBay（整体2PB），并支持每个服务器性能和严格的架构设计。

　　像许多关注这一领域的人一样，我不喜爱从本质上将SQL与NoSQL这一术语对立起来。

同时我对该术语现有的说明〞NotOnlySQL〞也不甚中意。

对我来说，我们那个地点所讨论的并非是是否使用SQL。

（相反的是，我们仍旧能够选择类似SQL如此的查询接口（缺少对join等的支持）来与这些数据库交互，使用现有的资源和技术来治理开发伸缩性和可爱护性。

）这一运动是要找到储备和检索数据的其他高效的途径，而不是盲目地在任何情形下都把关系数据库当作万金油。

因此，我认为’NonRelationalDatabase’（非关系型数据库）能够更好的表达这一思想。

　　不管采纳哪个名字，〝非关系型数据库〞这一范畴所传达出来的〝囊括所有〞类型的意味，使得这一概念比较模糊（同时它依旧否定型的）。

这又使得人们（专门是企业中的决策者）关于哪些是属于那个范畴，哪些不是，更重要的是，对他们来说这到底意味着什么，感到专门困惑。

　　为了解答这些疑问，我尝试通过以下几点特点的描述，来刻画〝非关系型数据库〞的内在本质。

　　所谓〝非关系型数据库〞指的是

　　使用松耦合类型、可扩展的数据模式来对数据进行逻辑建模（Map，列，文档，图表等），而不是使用固定的关系模式元组来构建数据模型。

　　以遵循于CAP定理（能保证在一致性，可用性和分区容忍性三者中中达到任意两个）的跨多节点数据分布模型而设计，支持水平伸缩。

这意味着关于多数据中心和动态供应（在生产集群中透亮地加入/删除节点）的必要支持，也即弹性（Elasticity）。

　　拥有在磁盘或内存中，或者在这两者中都有的，对数据持久化的能力，有时候还能够使用可热插拔的定制储备。

　　支持多种的’Non-SQL’接口（通常多于一种）来进行数据访问。

　　围绕着图中四个特点的（数据持久性、逻辑数据模型、数据分布模型和接口）〝非关系型数据库〞的各种变形，在最近的一些文章中有详尽的描述，同时在因特网上有着广泛的传播。

因此我就不做过多繁复的描述，而是通过一些例子对关键的方向进行总结，供快速参考：

　　接口——REST（HBase，CouchDB，Riak等），MapReduce（HBase，CouchDB，MongoDB，Hypertable等），Get/Put（Voldemort，Scalaris等），Thrift（HBase，Hypertable，Cassandra等），语言特定的API（MongoDB）。

　　逻辑数据模型——面向键值对的（Voldemort，Dynomite等），面向ColumnFamily的（BigTable，HBase，Hypertable等），面向文档的（CouchDB，MongoDB等），面向图的（Neo4j，Infogrid等）

　　数据分布模型——一致性和可用性（HBase，Hypertable，MongoDB等），可用性和可分区性（Cassandra等）。

一致性和可分区性的组合会导致一些非额定的节点产生可用性的缺失。

有味的是目前还没有一个〝非关系型数据库〞支持这一组合。

　　数据持久性——基于内存的（如Redis，Scalaris，Terrastore），基于磁盘的（如MongoDB，Riak等），或内存及磁盘二者的结合（如HBase，Hypertable，Cassandra）。

储备的类型有助于我们辨别该解决方案适用于哪种类型。

然而，在大多数情形下人们发觉基于组合方案的解决方案是最正确的选择。

既能通过内存数据储备支持高性能，又能在写入足够多的数据后储备到磁盘来保证连续性。

　　随着网站的连续进展，NOSQL成为大网站进展的必定性选择

　　随着数据量和访问量的增长，网站构架大致有这么几个进展时期（以PHP+MySQL+Memcached为例）：

　　1:

PHP+MySQL

　　2:

PHP+MySQL（Master+Slaves）

　　3:

PHP+MySQL（Master+Slaves）+Memcached（Middleware）

　　4:

PHP+MySQL（Sharding+Master+Slaves）+Memcached（Middleware）

　　5:

PHP+MySQL（Sharding+Master+Slaves）+Memcached（Middleware）+NoSQL

　　从上面的进展历程能够看出，随着复杂度的增加，开发难度和复杂性也随之提升，数据量增加之后每次重构需要的人力成本急剧增加，因此为了操纵成本，增长重构的周期，将一些数据量庞大，增长快速的业务迁移至NoSQL上储备。

　　因此大伙儿不必要言必NoSQL，NoSQL也可不能取代MySQL，不同的业务有它最适合的低成本储备方式，最终选择什么数据库是由系统成本决定的。

　　MySQL的优势在此不再赘述，其最大的特点是尽可能的压榨机器的性能，在上世纪末互联网泡沫破灭时，压缩成本的意识就差不多深入每一个互联网公司的血液，MySQL顺应时代的需求，为幸存的互联网公司尽可能的节约着每一分资金，不知有多少互联网故事都有以下的开头〝XX年，几个刚毕业的大学生用两台服务器创办了XXX〞，那时，不管是在美国，依旧在中国，硬件的成本相比人力资源，差不多上比较高的，专门是在中国，一台中等配置服务器的价格，几乎相当于一个技术新手一年甚至更多的薪水。

尽管SQL型数据库在扩展的时候有诸多不便，业务重构、代码重写、压力测试、上线，意味着网站开发、运维人员许多个不眠之夜，但人力成本较之买服务器的成本来说，可能当时绝大部分互联网公司都会选择前者。

　　再看十几年后的今天，网站的数据量比过去更大，用户更多，应用更复杂，业务的变化更加快速，人力资源的成本不断上涨，即便是金融危机之后的美国，一个一般MySQLDBA的工资依旧在十几万美元以上，至于高级开发，架构师的成本更是以数十万美元计，而硬件的成本却大大降低，NoSQL尽管在执行效率上远低于SQL型数据库，但其扩展的便利性导致不需要投入更多的人力来对系统和应用进行重构与改写，间接的降低了人员的成本，关于许多差不多有成百上千台服务器和上百万用户的美国互联网公司来说，节约下的人力成本，足够买上百台服务器来补偿NoSQL效率上的缺陷，如此的好事，因此许多公司差不多上期望进行尝试的。

　　如何将其与企业IT融合

　　现在的企业中，并非所有用例都直观地倾向于使用关系型数据库，或者都需要严格的ACID属性（专门是一致性和隔离性）。

在80年代及90年代，绝大部分储备在企业数据库里的数据差不多上结构化的业务事务的〝记录〞，必须用受控的方式来生成或访问，而现在它已一去不复返了。

无可争辩的是，仍有这一类型的数据在那儿，并将连续也应该通过关系型数据库来建模，储备和访问。

但关于过去15年以来，随着Web的进展，电子商务和社交运算的兴起所引起的企业里不受控的非结构化同时面向信息的数据大爆炸，该如何应对呢?

企业确实不需要关系型数据库来治理这些数据，因为关系型数据库的特点决定了它不适用于这些数据的性质和使用方式。

　　上图总结了现今以web为中心的企业中信息治理的新兴模式。

而〝非关系型数据库〞是处理这些趋势的最正确选择（较之关系型数据库来说），提供了对非结构化数据的支持，拥有支持分区的水平伸缩性，支持高可用性等等。

　　以下是支持这一观点的一些实际应用场景：

　　日志挖掘——集群里的多个节点都会产生服务器日志、应用程序日志和用户活动日志等。

关于解决生产环境中的问题，日志挖掘工具专门有用，它能访问跨服务器的日志记录，将它们关联起来并进行分析。

使用〝非关系型数据库〞来定制如此的解决方案将会专门容易。

　　分析社交运算——许多企业现在都为用户（内部用户、客户和合作伙伴）提供通过消息论坛，博客等方式来进行社交运算的能力。

挖掘这些非结构化的数据关于获得用户的喜好偏向以及进一步提升服务有着至关重要的作用。

使用〝非关系型数据库〞能够专门好的解决这一需求。

　　外部数据feed聚合——许多情形下企业需要消费来自合作伙伴的数据。

明显，就算通过了多轮的讨论和协商，企业关于来自合作伙伴的数据的格式仍旧没有发言权。

同时，许多情形下，基于合作伙伴业务的变更，这些数据格式也频繁的发生变化。

通过〝非关系型数据库〞来开发或定制一个ETL解决方案能够专门成功的解决这一问题。

　　高容量的EAI系统——许多企业的EAI系统都有高容量传输流（不管是基于产品的依旧定制开发的）。

出于可靠性和审计的目的，这些通过EAI系统的消息流通常都需要持久化。

关于这一场景，〝非关系型数据库〞再次表达出它十分适用于底层的数据储备，只要能给定环境中源系统和目标系统的数据结构更换和所需的容量。

　　前端订单处理系统——随着电子商务的膨胀，通过不同渠道流经零售商、银行和保险供应商、娱乐服务供应商、物流供应商等等的订单、应用、服务要求的容量十分庞大。

同时，由于不同渠道的所关联的行为模式的限制，每种情形下系统所使用的信息结构都有所差异，需要加上不同的规那么类型。

在此之上，绝大部分数据不需要即时的处理和后端对帐。

所需要的是，当终端用户想要从任何地点推送这些数据时，这些要求都能够被捕捉同时可不能被打断。

随后，通常会有一个对帐系统将其更新到真正的后端源系统并更新终端用户的订单状态。

这又是一个能够应用〝非关系型数据库〞的场景，可用于初期储备终端用户的输入。

这一场景是表达〝非关系型数据库〞