NOSQL的必要性和效率、成本分析

原文：http://hi.baidu.com/webtalk/blog/item/ee99730983f221b82fddd436.html

NOSQL的必要性和效率、成本分析

2011年05月16日 星期一 09:56

http://www.bopor.com/?p=1098

背景

前段时间国内外对NoSQL的讨论非常热烈，Digg和Reddit使用Cassandra，Facebook经过一些变化后依然对NoSQL进行测评，NoSQL取代SQL的呼声高涨，因为互联网行业使用MySQL的概率非常高，加之Oracle收购的消息，一时间似乎MySQL将成为NoSQL数据库的牺牲品，一场轰轰烈烈的技术革命就要到来了。之所以有如此动向是因为基于MySQL + sharding + cache的构架随着数据量爆炸式增长，重构的人力成本太高，换用扩展性更好的NoSQL数据库，以达到控制人力成本的目的，从而减少总体成本。

几个月过去了，NoSQL并没有像大家所想象的那样席卷全球，很多人设想中的MySQL与NoSQL的战争也仅存于设想中，国内不要说使用了，测评NoSQL的机构也是寥寥，究其原因，笔者认为：MySQL与NoSQL是两种不通性质的技术，它们代表的是两种完全不通的技术思想，均有其适应的土壤，究竟孰优孰劣，取决于诸多因素，而它们是否适用的根本因素，是“人”与“物”的成本变化。

什么是NoSQL

在“NoSQL”一词，实际上是一个叫Racker的人创造的，当约翰埃文斯埃里克要组织一次活动来讨论开源的分布式数据库。这个名称和概念都由此而来。

有些人反对NoSQL术语，因为它听起来像我们定义自己是什么．在一定程度，但长期仍然是有价值的，因为当一个关系数据库是唯一的工具，你知道，每一个问题，看起来像一个大拇指。 NoSQL是让人们知道有其他选择哪里。但我们并不反对关系数据库，因为当这确实是工作的最佳工具.

一个与NoSQL名称真正关注的是，它是一个很大的帐篷，有非常不同的设计空间。如果这不是在讨论清楚的，它在各种产品混乱的结果。因此，我要建议沿着三个轴的思考很多数据库选项：可扩展性，数据和查询模型和持久性的设计。

前所未有的数据量正推动企业关注传统的关系数据库技术，已服务了30多年良好替代品。总的来说，这些替代品已被称作“NoSQL数据库。”

最根本的问题是关系数据库不能处理很多数据量。有三个具体的问题：扩大向像Digg新闻评论网站的（3TB绿色徽章）或Facebook的（50TB收件箱中的搜索）或EBay（整体2PB），

并支持每个服务器性能和严格的架构设计。

像许多关注这一领域的人一样，我不喜欢从本质上将SQL与NoSQL这一术语对立起来。同时我对该术语现有的解释”Not Only SQL”也不甚满意。对我来说，我们这里所讨论的并非是是否使用SQL。(相反的是，我们仍然可以选择类似SQL这样的查询接口(缺少对join等的支持)来与这些数据库交互，使用现有的资源和技术来管理开发伸缩性和可维护性。) 这一运动是要找到存储和检索数据的其他高效的途径，而不是盲目地在任何情况下都把关系数据库当作万金油。因此，我认为’Non Relational Database’(非关系型数据库)能够更好的表达这一思想。

无论采用哪个名字，“非关系型数据库”这一范围所传达出来的“囊括所有”类型的意味，使得这一概念比较模糊(并且它还是否定型的)。这又使得人们(特别是企业中的决策者)对于哪些是属于这个范围，哪些不是，更重要的是，对他们来说这到底意味着什么，感到非常迷惑。

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

所谓“非关系型数据库”指的是

使用松耦合类型、可扩展的数据模式来对数据进行逻辑建模(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 等)，面向Column Family的(BigTable，HBase，Hypertable 等)，面向文档的(Couch DB，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型数据库在扩展的时候有诸多不便，业务重构、代码重写、压力测试、上线，意味着网站开发、运维人员无数个不眠之夜，但人力成本较之买服务器的成本来说，可能当时绝大部分互联网公司都会选择前者。

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

如何将其与企业IT融合

如今的企业中，并非所有用例都直观地倾向于使用关系型数据库，或者都需要严格的ACID属性(特别是一致性和隔离性)。在80年代及90年代，绝大部分存储在企业数据库里的数据都是结构化的业务事务的“记录”，必须用受控的方式来生成或访问，而如今它已一去不复返了。无可争辩的是，仍有这一类型的数据在那里，并将继续也应该通过关系型数据库来建模，存储和访问。但对于过去15年以来，随着Web的发展，电子商务和社交计算的兴起所引起的企业里不受控的非结构化并且面向信息的数据大爆炸，该如何应对呢？企业确实不需要关系型数据库来管理这些数据，因为关系型数据库的特点决定了它不适用于这些数据的性质和使用方式。

上图总结了现今以web为中心的企业中信息管理的新兴模式。而“非关系型数据库” 是处理这些趋势的最佳选择(较之关系型数据库来说)，提供了对非结构化数据的支持，拥有支持分区的水平伸缩性，支持高可用性等等。

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

日志挖掘——集群里的多个节点都会产生服务器日志、应用程序日志和用户活动日志等。对于解决生产环境中的问题，日志挖掘工具非常有用，它能访问跨服务器的日志记录，将它们关联起来并进行分析。使用“非关系型数据库”来定制这样的解决方案将会非常容易。

分析社交计算——许多企业如今都为用户(内部用户、客户和合作伙伴)提供通过消息论坛，博客等方式来进行社交计算的能力。挖掘这些非结构化的数据对于获得用户的喜好偏向以及进一步提升服务有着至关重要的作用。使用“非关系型数据库” 可以很好的解决这一需求。

外部数据feed聚合——许多情况下企业需要消费来自合作伙伴的数据。显然，就算经过了多轮的讨论和协商，企业对于来自合作伙伴的数据的格式仍然没有发言权。同时，许多情况下，基于合作伙伴业务的变更，这些数据格式也频繁的发生变化。通过“非关系型数据库”来开发或定制一个ETL解决方案能够非常成功的解决这一问题。

高容量的EAI系统——许多企业的EAI系统都有高容量传输流(不管是基于产品的还是定制开发的)。出于可靠性和审计的目的，这些通过EAI系统的消息流通常都需要持久化。对于这一场景，“非关系型数据库” 再次体现出它十分适用于底层的数据存储，只要能给定环境中源系统和目标系统的数据结构更改和所需的容量。

前端订单处理系统——随着电子商务的膨胀，通过不同渠道流经零售商、银行和保险供应商、娱乐服务供应商、物流供应商等等的订单、应用、服务请求的容量十分巨大。同时，由于不同渠道的所关联的行为模式的限制，每种情况下系统所使用的信息结构都有所差异，需要加上不同的规则类型。在此之上，绝大部分数据不需要即时的处理和后端对帐。所需要的是，当终端用户想要从任何地方推送这些数据时，这些请求都能够被捕获并且不会被打断。随后，通常会有一个对帐系统将其更新到真正的后端源系统并更新终端用户的订单状态。这又是一个可以应用“非关系型数据库”的场景，可用于初期存储终端用户的输入。这一场景是体现“非关系型数据库”的应用的极佳例子，它具有高容量，异构的输入数据类型和对帐的”最终一致性”等等特点。

企业内容管理服务——出于各种各样的目的，内容管理在企业内部得到了广泛的应用，横跨多个不同的功能部门比如销售、市场、零售和人力资源等。企业大多数时间所面临的挑战是用一个公共的内容管理服务平台，将不同部门的需求整合到一起，而它们的元数据是各不相同的。这又是“非关系型数据库”发挥作用的地方。

合并和收购——企业在合并与收购中面临巨大的挑战，因为他们需要将适应于相同功能的系统整合起来。“非关系型数据库” 可解决这一问题，不管是快速地组成一个临时的公共数据存储，或者是架构一个未来的数据存储来调和合并的公司之间现有公共应用程序的结构。

但我们如何才能准确的描述，相对于传统的关系型数据库，企业使用“非关系型数据库”带来的好处呢？下面是可通过非关系型数据库的核心特点(正如上一节所讨论的)而获得的一些主要的好处，即企业的任何IT决策都会参考的核心参数——成本削减，更好的周转时间和更优良的质量。

业务灵活性——更短的周转时间

“非关系型数据库”能够以两种基本的方式带来业务灵活性。

模式自由的逻辑数据模型有助于在为任何业务进行调整时带来更快的周转时间，把对现有应用和功能造成影响减到最少。在大多数情况下因任意的变更而给你带来的迁移工作几乎为零。水平伸缩性能够在当越来越多的用户负载造成负载周期性变化，或者应用突然变更的使用模式时，提供坚固的保障。面向水平伸缩性的架构也是迈向基于SLA构建(例如云)的第一步，这样才能保证在不断变化的使用情形下业务的延续性。更佳的终端用户体验——更优越的质量

在现今企业IT中，应用的质量主要由终端用户的满意度来决定。“非关系型数据库”通过解决如下终端用户的考虑因素，能够达到同样的效果，而这些因素也是最容易发生和最难以处理的。

“非关系型数据库” 为提升应用的性能带来了极大的机会。分布式数据的核心概念是保证磁盘I/O(寻道速率)绝不能成为应用性能的瓶颈。尽管性能更多的是由传输速率来决定。在此之上，绝大部分解决方案支持各种不同的新一代的高速计算的范式，比如MapReduce，排序列，Bloom Filter，仅可追加的B树，Memtable等。现今用户满意度的另一个重要的方面就是可靠性。终端用户希望在想要访问应用时就能访问到，并且至少是在当他们分配到时间的时候能随时执行他们的任务。所以不可用的应用需要不惜代价的避免。许多现代的“非关系型数据库”都能适应并支持这一类有着严格和最终一致性的可用性的需求。更低的所有者总成本

在如今的竞争市场中，企业IT支出随时都要仔细审查，以合理的成本获取合理的质量才值得赞许。在这一领域中“非关系型数据库”在一定程度上胜于传统的数据库，特别是当存储和处理的数据容量很大时。

水平伸缩性的基本前提保证了它们可以运行于廉价机器之上。这不仅削减了硬件资本的成本，同时还削减了诸如电力，维护等运维成本。同时这还进一步的为利用诸如云、虚拟数据中心等下一代低成本的基础设施打下了基础。从长期来看，更少的维护能带来更多的运维成本优势。对于关系型数据库，这绝对是一个需要存储大容量数据的场景。为大容量的数据调优数据库需要高超的技艺，也就意味着更高的成本。相较之下，“非关系型数据库”始终提供快速和响应的特点，就算是在数据大幅上升的情况下。索引和缓存也以同样的方式工作。开发者不必过多担心硬件、磁盘、重新索引及文件布局等，而是把更多的精力投入了应用程序的开发上。企业采用中所面临的挑战

抛开所有这些长远的好处，在企业拥抱“非关系型数据库”之前，当然还需要经历各种各样的挑战。

不考虑因现有思想的转换和缺乏信心而产生的来自高层的阻力，目前我认为的最主要的战术性挑战是：

为“非关系型数据库”认定正确的应用/使用场景

尽管从理论上容易论证并非所有的企业数据都需要基于关系和ACID的系统，然而由于关系型数据库与企业数据间多年的绑定关系，要作出所有的数据可以通过非关系的解决方案而解耦的决定仍然有很多困难。许多时候IT经理(以及其它对于应用程序负有核心的底线责任的各级人员)不明白他们将会失去什么，这样的担忧对于从关系型数据库转变出来比较不利。企业IT最有价值的资产就是数据。因此，要作出决定使用一种不太明确或者未被广泛采用的解决方案来管理同样的数据，这种能力不仅需要转换思维方式，同时还需要来自高层的强大的支持(和推动)。

我们如何选择最适合我们的产品/解决方案

另一个重大的挑战是找出合适的产品/工具来提供“非关系型数据库”。正如前面所提到的那样，现今业界里面有多于25种不同的产品和解决方案，它们在四个方面有着不同的特点。正因为每个产品在这四个方面特点各异，所以要选择一个产品来应对所有的需求显得尤为困难。有的时候，可能在企业的不同部门使用到多种类型的非关系型数据库，最后人们可能会完全出于对标准的需要而转向关系型数据库。

如何获得规模经济

这一想法本质上是从前一个问题分支出来的。如果一个组织需要使用多个非关系型数据库解决方案(由于单个方案的适用问题)，那么保证在技术(开发者，管理者，支持人员)，基础设施(硬件成本，软件许可成本，支持成本，咨询成本)，以及工件(公共组件和服务)方面的规模经济就是一个大问题。这一方面与传统的关系型数据库解决方案比较起来确实更为严峻，因为大部分时间组织的数据存储都是以共享服务的模式在运行的。

我们如何保证解决方案的可移植性

从“非关系型数据库”的发展来看，我们可以很直观地推测在未来的几年中这一领域会有许多变化，比如供应商的合并，功能的进步以及标准化。所以对于企业来说一个更好的策略是不要把宝押在某个特定的产品/解决方案上，以后才可以更灵活的转换到一个更好的经过考验的产品。 由于现在的非关系型产品/解决方案大部分是私有的，因此IT决策者在考虑尝试“非关系型数据库”之前，不得不认真考虑可移植性这一重要的问题。这纯粹是出于保护现有投资的需要。

我们如何获得合适的产品支持类型

现在的“非关系型数据库”能通过外部组织而提供支持方案的少之又少。就算有，也无法与Oracle，IBM或者微软等相比。特别是在数据恢复，备份和特定的数据恢复方面，由于许多“非关系型数据库”在这些方面未能提供一个健壮而易于使用的机制，对于企业决策者来说，仍存在很大的问题。

我们如何预算整体成本

与重量级的关系型数据库相比，“非关系型数据库”通常在性能和伸缩性特征方面能提供的数据更少。我也没有发现有TPC基准程序方面和类似的其它方面的数据。这将企业决策者置于了一个“没有方向”的情况下，因为他们不知道需要在硬件、软件许可、基础设施管理和支持等方面支出多大的费用。要得出一个预算估计，缺乏判断的数据就成了一个主要的障碍。因此在项目启动阶段，大部分情况下决策者还是会选择基于熟悉的关系型数据库的解决方案。

有时候，就算可以得到这些数字，但也不足以用来形成TCO模型并与传统的基于关系型数据库的数据存储和非关系型数据存储进行整体的成本分析(Capex+Opex)比较。通常情况下水平伸缩性所要求的大量的硬件机器(以及软件许可成本，支持成本)，如果与垂直伸缩性乍一比较，会让人觉得战战兢兢，除非由此带来的好处经过基于TCO模型的全方位比较仍然被证明是可以持续的。

关于如何采用NOSQL的两点思考

这是否意味着目前来看企业应该对NoSQL运动持观望的态度呢？并非如此。诚然，“非关系型数据库”对于广泛的采用来说还未到完全成熟的阶段。但“非关系型数据库”作为未来企业骨架的潜力仍不能忽视。特别是不远的将来企业将更多地处理大容量的半结构化/非结构化以及最终一致性的数据，而不是相对而言小容量的，严格结构化的遵循ACID的数据。 所以现在而言至关重要的是做企业的关键决策人的思想工作，让他们明白企业的数据处理需要使用“非关系型数据库”。在这一过程中，要采取一些渐进的步骤把“非关系型数据库”应用到企业IT的一些关键的方面(技术，人员和流程)，并产生一定的价值。这样，就可以用一种缓慢而稳健的方式从整体上来解决我们之前所总结出来的一系列问题。

采用一个产品/解决方案

如今市场上的选择非常多样化，可根据“非关系型数据库”侧重的面不同而进行差异化的处理。与此同时，企业应用场景可能需要不同类型的特点。然而以不同的解决方案来处理不同的应用/使用场景从规模经济的角度出发对于企业是不适宜的。因此最好是根据目标应用的需要最终落实到某一个具体的产品/解决方案上。需要注意的是大多数的解决方案在特性上都会有一些折中，有些特性可能在其它的产品中可以获得，有些可能只是在发展路线图当中暂时设定了一个位置。因为大部分的产品会在不久的将来不断趋于成熟，因此可以通过不同配置来提供不同的解决方案。所以只要现有的解决方案能适合目前大部分的需要，不妨作为一个起点将其采纳。

选择产品/解决方案的经验法则

支持所需要的逻辑数据模型应当被给予更高的权重。这将从实质上决定该解决方案在当前或未来能否灵活地适应不同的业务需求。调查该产品所支持的物理数据模型的合适与否，据此对这一解决方案所需要的水平伸缩性、可靠性、一致性和分区性作出合理的评估。这同样能表明备份和恢复机制的可能性。接口支持需要与企业标准的运行环境对齐。由于这些产品支持多样的接口，所以这一点可以得到很好的处理。只要产品支持水平伸缩性，对于持久化模型的选择就不再重要了。

这里有一份一系列“非关系型数据库”的对照表。对于现在正认真考虑采用的企业来说，这是一个不错的起点。为了更贴近企业本身的情况，从25+的集合中挑选出的子集所用到的的关键选择标准是：

最重要的一点首先是企业应用程序必须支持有一定复杂程度的数据结构。否则的话，应用程序管理复杂性的责任将变得非常大。我认为比较合理的应当是介于纯粹的键值对与关系型模式中间的一种方案。出于这方面的考虑像Vlodemort，Tokyo Cabinet等产品就排除在了我的列表之外。第二点是以低成本的分片/分区为大容量数据提供水平支持。缺乏这样的支持就使得解决方案与任何关系型数据库无异了。因此像Neo4J(尽管他有丰富的基于图的模型)，Redis，CouchDB等此时此刻就被过滤出我的列表之外了。最后一条评判标准，在企业级推广之前我会考虑一定程度的商业支持。否则的话，一旦出现生产环境的问题，我该去找谁呢？出于这一点，我不得不将现在的一些明星产品排除在外，比如Cassandra(尽管有很大的可能不久的将来Rackspace或者Cloudera就会对其提供支持，因为它已经被用于一些生产环境里边了，比如Twitter，Digg，Facebook)。

有了这些过滤标准，我可以精简这一列表，符合目前企业可用的产品有 MongoDB (下一版本就会提供shards支持)，Riak，Hypertable和HBase。下面这个表格中总结了这四个产品的主要特性。一个企业可以基于自己具体的实际情况从中作出选择，找到最适合自己需要的特性。

特性	MongoDB	Riak	HyperTable	HBase
逻辑数据模型	富文档，并提供对内嵌文档的支持	富文档	列家族(Column Family)	列家族(Column Family)
CAP支持	CA	AP	CA	CA
动态添加删除节点	支持(很快在下一发布中就会加入)	支持	支持	支持
多DC支持	支持	不支持	支持	支持
接口	多种特定语言API(Java，Python，Perl，C#等)	HTTP之上的JSON	REST，Thrift，Java	C++，Thrift
持久化模型	磁盘	磁盘	内存加磁盘(可调的)	内存加磁盘(可调的)
相对性能	更优(C++编写)	最优(Erlang编写)	更优(C++编写)	优(Java编写)
商业支持	10gen.com	Basho Technologies	Hypertable Inc	Cloudera

数据访问抽象

为数据访问创建一个单独的抽象层对于“非关系型数据库”来说是必须的。它可以带来多方面的好处。首先，应用开发者可以与底层解决方案的细节完全隔离开来。这对于技术方面的伸缩性带来了好处。同时未来如果需要更改底层的解决方案也很方便。这也以一个标准的方式满足了多个应用的要求(即去掉了Join，Group by等复杂特性的SQL)。

为性能和伸缩性创建模型

不管选择怎样的解决方案，使用标准技术(比如排队网络模型，分层排队网络等)来对性能和伸缩性进行建模都是高度推荐的。它能够为基本的服务器规划、拓扑以及整体的软件许可证成本，管理运行等提供必要的数据。这将实质上成为所有预算计划的主要参考数据，并对作出决策提供帮助。

构建显式的冗余

要防止数据丢失，除了将数据复制到备份服务器上，没有其它的办法了。尽管许多非关系型数据库提供自动复制功能，但仍然存在主节点单点失效的风险。因此最好是使用次节点备份，并准备好用于数据恢复和自动数据修复的脚本。出于这样的目的，应当充分的了解目标解决方案的物理数据模型，找出可能的恢复机制备选方案，基于企业的整体需求和实践来对这些选项作出评估。

构建公共数据服务平台

就像公共共享服务的关系型数据库一样，也可以构建非关系型数据库的公共数据服务来促进规模经济效应，满足基础设施和支持的需要。这对于未来进一步演化和更改也有帮助。这可以作为愿望列表上的最终目标，通过中期或长期的努力来达到这一成熟水平。然而，初始阶段就设立这样的远景有助于在整个过程中作出正确的决策。

壮大企业的技术力量

每个组织都有一部分人对于学习新生的和非传统的事物充满热忱。成立这样的小组，并挑选人员(全职的或兼职的)，密切关注这方面的动向，了解问题和挑战，进行前瞻性的思考，能够为使用这些技术的项目提供方向和帮助。同时，这个小组还可以为决策者澄清炒作的疑云，提供来自真实数据的观点。

建立与产品社区的关系

选择了产品之后，与产品社区建立起良好的关系对于双方的成功都有极大的好处。许多非关系型数据库目前都有十分活跃的社区，非常愿意相互帮助。企业与社区之间的良好合作能给大家带来一个双赢的局面。 如能提前对问题和解决方案有了解，那么企业在对某些特性或版本作出决策时就能成竹在胸。反过来，企业又能对产品特性的路线图产生影响作用，这对他们自身和社区都是有利的。另一方面，社区也能从实际层次的问题中得到反馈，从而丰富和完善产品。来自大型企业的成功案例同样能让他们处于领先。

迭代前进

考虑到非关系型数据库相对的成熟度，风险最小的采用策略就是遵循迭代开发的方法论。构建公共数据服务平台和标准化数据访问抽象不可能是一蹴而就的。相反，通过迭代和面向重构的方式能更好的达到目标。运用不太成熟的技术进行转型的过程，中途改变解决方案也不会太意外的。与此同时，采用敏捷的方式来看待事物，能够帮助建立起一个能从管理和实现两方面不断吸引改进的开放态度。

然而，在这一问题上实现迭代，非常重要的一点是定义一个决策条件矩阵。比如操作指南(和例子)，来判断一个应用的对象模型是否适合关系型或非关系的范围，对基础设施规划作出指导，列出必需的测试用例等等。

一个简单的NOSQL实例

NoSQL的好处是可伸缩性

即对数据库规模的扩大以支持并发读取与复制更容易，比如到多台机器自动分区的数据，是一种“分布式数据库。”这其中包括Cassandra，HBase，Riak，Scalaris，Voldemort，等等。如果你不想手动分区管理并且如果你写卷或数据容量超过一台机器可处理，那么这些是你的唯一选择。

有两件事情看在分布式数据库：1）支持多种数据中心和2）能够添加新的机器现场集群的应用程序的透明。

企业的非关系型数据库采用过程中最大的挑战就是转变决策者的思想观念——让他们相信并非所有的数据/对象都适合关系型数据库。 最能证明这一点就是选择合适的用例去尝试非关系型数据库，进而证实在合适的背景下，非关系型数据库是比关系型数据库更有效的解决方案。 找到一些“非关键业务”(但能立竿见影的)适合于非关系型数据库的项目。这些项目的成功(甚至失败)都能有助于观念的改变。这也能有助于不断学习如何才能以一种不同的方式来更好的采用非关系型数据库。这些少儿学步般的尝试所作出的努力与投入都是值得的，如果企业想要在将来使用“非关系型数据库”来重塑其信息管理体系的话。我选择了一些作为NOSQL数据库的例子

NoSQL数据库使用

1． NoSQL数据和查询模型

非分布式NoSQL数据库包括CouchDB，MongoDB，Neo4j，Redis，和Tokyo Cabinet。这些可以作为分布式系统持久层; MongoDB提供有限的共享支持，做了单独的休息室为CouchDB项目，和Tokyo Cabinet可作为Voldemort存储引擎使用。

数据和查询模型

在NoSQL里有很多不同的数据模型和数据库的查询API.

一些重点：

该columnfamily模型Cassandra共享和HBase的是由谷歌的Bigtable文件，第2节描述的启发。 （Cassandra下降，历史版本，并添加超级列。）在这两个系统，你必须像你行和列习以为常，但稀疏行：每一行可以有许多或尽可能少列的需要，以及列不必须提前定义。

键/值模型是最简单和最容易实现的，但效率低，只有当你在查询或更新的值的一部分感兴趣。这也是难以执行的分布式圈顶更复杂的结构/价值。

文档数据库基本上是下一阶段重点/值，允许嵌套的值与每个键关联。文件数据库支持查询的效率比每次返回了整个BLOB更简单。

Neo4J有一个真正独特的数据模型，对象存储在图和节点和边的关系。对于查询适合这个模型（例如，分层数据），它们可以是1000倍速度比替代品。

Scalaris是独特的，提供跨多个键分布式事务。 （讨论与贸易之间的一致性和可用性权衡超出了这个职位的范围，但另一个方面就是要牢记在评价分布式系统。）

持久性设计

通过持续的设计，“如何在内部存储的数据？” 持久性模型告诉我们很多这些数据库能够善于什么样的工作量.

在内存数据库是非常，非常快的（Redis达到每秒超过100,000操作一台计算机上），但不能与数据集的工作，超出可用的RAM。耐久性（保留数据，即使服务器崩溃或断电）也将是一个问题的数据量，可以预期损失之间的冲（复制数据到磁盘）可能非常大。 Scalaris，其他内存数据库，我们的名单上，意向处理与复制耐久性问题，但由于它不支持多个数据中心的数据将仍然容易受到停电的事情一样。

Memtables和SSTables缓存在内存中写入（1“memtable”）后，以书面追加只承诺为耐久性日志。当写够已被接受的memtable排序并写入到磁盘上的所有一次作为“sstable。”这提供近内存中的表现，因为没有涉及要求，同时避免了纯粹的耐久性问题，在内存的方法。 （这是详细描述在第5.3和先前提及的5.4 Bigtable的文件，以及在该日志结构合并树。）

B-树已被用于从数据库中实际上是时间的起点。索引他们提供强大的支持，但表现欠佳的旋转盘（这仍然是迄今为止最具有成本效益，因为多）要求读或写什么工作。

一个有趣的变体是CouchDB的追加，只有B -树，它避免了管理费用的目的在限制CouchDB一写一时间成本.

本文来自网络上的内容整合。