NoSQL理论体系及应用

李冯筱，罗高松

（广州优亿信息科技有限公司 广州 510630）

1 引言

关系型数据管理系统（relationship database management system，RDBMS）在网络和商务应用中，对于存储结构化数据，目前仍然占有主导性地位。然而最近几年，越来越多的学者和大型网络公司开始质疑关系型数据库“以一适用所有”的想法。大数据时代的来临，使得传统RDBMS的瓶颈成为发展道路上的阻碍，于是新型数据库改革运动掀起了一股热浪，开发者们引用NoSQL作为运动的名称。NoSQL是一种概念，根据应用的不同，理解上也有所不同，有些人认为应该是not only SQL，也有些人认为是non-relational database，也有说法是non-SQL。无论说法上有什么区别，其描述的是越来越多的网络开发商（以下简称“网商”）打破传统局限，应用非关系型数据库方法进行革新的趋势。

2 NoSQL基础理论

NoSQL作为新兴数据库系统概念，由于其具有处理海量数据的能力，近年来受到各大IT公司的追捧。Facebook、Google等大型网商纷纷斥资进行相关研究。虽然相对成熟的RDBMS仍存在不少功能问题，但在这个数据爆炸的时代，由于数据处理需求的不断提升，预计这种发展热潮仍将持续下去，并且普遍化。谈及NoSQL数据库概念，首先应该了解支持NoSQL概念的理论三大基石：CAP理论、BASE思想和最终一致性。理解这三大理论，对于了解NoSQL的本源有着极其重要的作用。本文将对三大基石的理论基础和其之间的关系进行着重介绍。

2.1 CAP理论

Eric Brewer在发表于ACM的PODC中名为 “关于Robust分散式系统”的文章中首次提及CAP理论。此理论目前被大型公司广泛采纳，如Amazon和其他NoSQL拥护者。CAP 解释为一致性（consistency）、性能（availability）以及分区容忍性（partition tolerance）。具体描述如下。

一致性：一个数据系统如何处理读写操作的一致性问题。分布式系统对于一致性的要求为当更新写入操作完成时，其余读取操作需要及时看到数据的更新。当然有些系统对于一致性有更严格定义上的要求。

可用性：一个系统能够持续不间断使用的问题。严格定义上的高性能可用性意味着一个系统从设计到实施都应该能够提供可持续的操作（如读写操作），无论是操作冲突，还是软硬件部分因为升级而导致失效。

分区容忍性：可以被理解为系统在提供持续性操作时分区处理的能力。一旦开始将数据和逻辑分布在不同的节点上，就有形成分区的风险。假定网线被切断，就形成分区，在不同分区的节点A和节点B无法通信。由于Web提供的这种分布式能力，临时的分区是一个常见的情况，处理这种情况就属于分区容忍性。一些人认为分区容忍性也可以理解为一个系统灵活处理节点的增加和去除的能力。例如，处于维护目的时，去除然后再添加节点的行为可认为是一种分区容忍性的表现。

现在Brewer提出，在数据共享系统中这3种特性是无法同时实现的，最多只能选择其中两种执行，这个理论已经得到了大量的验证。很简单的例子，如复制必须能在多节点上进行，从而提升可用性，那么数据副本（replica）之间就面临调试。但为了在网络分区的情况下也能够正常工作，复制或数据间的调试就很难执行。所以CAP仅能得以部分保证。

Brewer指出了基于CAP理论的3种应用，选择其中的一些例子，见表1。

对于数据库，Brewer总结道，由于一致性和可用性无法兼得，大多数NoSQL拥护者都选择了一致性高于可用性的设计模式，除了NoSQL，这些理论也影响到了部分关系型数据库。表2总结了一些现存常用产品的设计架构的CAP取舍以及其对应的功能分类。

2.2 BASE思想

互联网中，类似于wikis、blogs和社交网站等，创造了大量的数据等待被处理、分析和传输。公司、组织和个人提供大量的相关应用和服务致力于满足性能、可信度、可用性、持久性需求。正如上面所讨论的那样，CAP理论指出，对于一致性、可用性和分区容忍性，必须要做出一个选择。越来越多的应用和使用案例，包括网络应用，特别是对于一些大型和超大型的案例，甚至于一些电子商务的范畴中，可用性和分区容忍性被认为比一致性更需要严格设计。这些应用设计更多倾向于降低一致性，而强调可用性和数据冗余机制（即有序地将数据分散于不同节点中）。这是因为大多数系统都在普通的机器上，而非高级的专用机器，此类模式能够帮助应对相关问题，并且更具有扩展性。传统ACID模式对于数据的属性要求非常高，在分布式系统中比较难以达到。所以在CAP理论的基础上，提出了BASE思想，对一致性进行概化处理。

表1 CAP理论应用特点及例子

表2 CAP理论数据库应用实例及功能分类

要解释BASE思想，首先要对ACID有一个了解，因为BASE是相对于DBMS中的ACID所提出来的新思想。ACID指的是传统数据库对于数据特性的要求，详细介绍如下。

·原子性（A）：即事务执行作为原子，不可再分离，整个语句要么执行，要么不执行，不可能停在中间某个环节。

·一致性（C）：在事务开始之前和事务结束之后，数据库的完整性约束没有被破坏。

·隔离性（I）:两个事务的执行互不干扰，一个事务不可能看到其他事务运行时中间某一时刻的数据。两个事务不会发生交互。

·持久性（D）:在事务完成以后，该事务对数据库所做的更改便持久地保存在数据库之中，并不会被回滚。

在数据库系统中，事务的ACID属性保证了数据库的一致性，如银行系统中，付款就是一个事务，从原账户扣除金额以及向目标账户添加金额，这两个数据库操作的总和构成一个完整的逻辑过程，不可拆分，为原子，从而保证了整个系统中的总金额没有变化。

然而，这些ACID特性对于大型的分布式系统来说，与高性能是不兼容的。比如，在网店买东西，任何一个人买东西的过程都会锁住数据库直到买东西彻底完成，买完时，每一个人都可以看到库存减少了。也就是说，不允许存在两个人同时买的情况。很明显对于大多数网上商城，尤其是大型网商来说，这个方法并不适用。

BASE思想实际上是CAP理论中AP的衍伸。它通过牺牲高一致性，保证高可用性和分区容忍性。它同时也是ACID的一个变种。BASE在英文中有基本的意思，也可以说实际上强调的就是能保证连续 “基本”可用的一种模型。BASE思想的组成有以下3个部分：基本可用、软状态、最终一致性。

BASE模式指的是一个应用在任意时间首先应该能完成最基本化的工作（即基本可用），并不需要总是一致（即软状态），但最终应该是一致（即最终一致性）的。ACID和BASE应该被看作同一范畴内的互相补充品，而不是替代品。其优缺点对比见表3。

表3 BASE与ACID的优缺点对比

2.3 最终一致性

有两种方式看待一致性。一种是从开发者/客户端的角度，如何观察数据更新；另一种是从服务器端，更新如何在系统中流动以及对于更新系统能提供什么样的保证。客户端观察到的一致性指的是，何时以及如何能观察到对存储系统中的数据对象所做的更新。

对于一致性的解释，根据强度的不同，分为强一致性和弱一致性两种。

强一致性，即所有的读取操作都必须返回最新的写入操作的数据，而忽略复写操作的路径。这样的需求要求对于数据的操作（写入和读取）都必须在同一节点上，否则强一致性将受到分布式事务传输协议的影响 （如2PC和Paxos）。因此，根据CAP理论，强一致性无法和可用性、分区容忍性同时实现。

弱一致性，即读取操作时能够见到写入操作，但仅限一定程度上的最新写入操作后的数据。那么，客户端在流程中会出现非一致性的数据。解决方法有很多，例如，在一个多数据副本的数据库中，更新操作会集中于一个节点，那么这个节点上的数据就能保持一定是最新的版本。

最终一致性属于弱一致性的一种，即存储系统保证如果没有新的更新提交，最终所有的访问都将获得最后的更新。如果没有故障发生，不一致性取决于通信时延、系统负载以及复制策略中涉及的副本数。实现最终一致性最常见的系统是DNS。根据name更新的传播、配置模式以及时间控制的缓存，最终所有节点都会看到更新。

弱一致性的系统能够同时提供更多元化和针对性的操作方案。

·Read Your Own Writes （RYOW）Consistency方案指的是一个客户端能够及时看到本方的实时数据更新，但其他方则不需要立即看到这类更新。

·Session Consistency指的是在一定范围内（通常为同一服务器内），客户端能看到同范围内的实时更新。

·Casual Consistency指的是一个客户端读取了X版本的数据，然后写入了版本Y，那么每个读取Y版本的客户端也能看到X版本。

·Monotonic Read Consistency提供时间单一性，保证每个客户端在之后的请求中获取到的是最新版本。

当同一片区的数据的不同更新同时发生，客户端并不需要依靠于读取数据的即时更新时，弱一致性是一个很好的选择。有关一致性模型的选择，需要考虑客户端如何请求数据和处理副本更新的方式。以下举例进行说明。

在GFS中，多客户端可以持续地修改或执行追加记录的操作。尽管不同时的写入操作有可能在多副本中显示同样的值，但实际上每一个客户端的写入操作是不明确的。追加记录操作在每一个副本中的文档区域内都能出现至少一次来保证原子性，以此来体现一致性。

Dynamo则用一种叫sloppy quorum的方法，通过请求一个总能写入的服务来保证显示和读取的一致性。Quorum协议判断的是系统用于读取、写入和每个操作在复制进程中所囊括的系统数量N，以此来防止由于网络分区造成的信息不一致。处理系统临时崩溃时，Dynamo允许其他并没有包含进程的系统用Hinted-handoff方法 （也就是sloppy quorum）执行一个主要query。它允许每一个系统都能处理可能在复制过程中发生数据不一致的数据版本，并且使用向量时间技术来判断参与进程的系统中数据修改的因果关系，一次保证每一个系统都能自动识别新的数据，并且当客户端能够决定时，通过传达版本号来决定数据的显示。

在Cassandra中，一致性的程度是可以调控的。用户可以决定在N个复制关系中有多少读写操作必须成功。在读取（0、任意、1仲裁和全部）时和在写入（1仲裁和全部）时，它都提供明确的方法。它与Dynamo相似，也通过时间戳顺序进行读取修复，从而提供读取的一致性。

2.4 三大基石的意义

三大基石是垫定NoSQL理论的基础。它在传统RDBMS的理论架构上，针对分布式数据存储理论进行了理论上的革新。CAP理论指出了传统数据库要求在分布式系统中是很难实现的，在基础架构中，必须要考虑到产品方向对一致性、可用性、分区容忍性的要求，从而进行合理的取舍。根据CAP理论，提出了传统ACID属性的变形体BASE思想。BASE思想弱化了传统ACID思想对事务属性的严格要求，提出了保证高可用性的基本工作、软状态和最终一致性想法。实际上就是根据CAP理论，在一定程度上放宽对一致性的要求，从而保证可用性和分区容忍性。最终一致性对传统一致性进行了再定义，并衍生出了很多新的处理方法。首先数据的一致性是必须要考虑的，放松不等于放任不管。最终一致性是一种考虑用户体验的折中办法，也是与传统RDBMS最大的不同之一。

三大基石互相补充，互相以各自为基础进行衍伸，形成了一个标准的理论体系。然而，由于开发应用尚未进入完全成熟的阶段，因此这个理论细节也在不断的变革中。与传统RDBMS“以一适用全部”的思想相比，NoSQL的理论体系发展更强调个体适应性。针对具体产品，需要有严格的考核思量过程，明确需要什么、可以放宽什么，进而进行合理设计。

3 NoSQL产品分类

目前NoSQL概念下的数据库应用非常多，根据数据模型、功能应用、分布方式、复制方式等分类各有不同。从另一方面来说，也反映了NoSQL理论体系的高扩展性和可能性。对现在NoSQL理论下的数据库进行分类，见表4。

4 NoSQL与RDBMS对比

众所周知，NoSQL的应用研究热潮是紧随着大数据时代来临掀起的。相对于传统RDBMS，NoSQL的发展并未成熟。那么为什么要选择NoSQL呢？是什么让各大公司纷纷从RDBMS转型做NoSQL呢？NoSQL和RDBMS之间究竟是什么关系呢？本节将从这些方面对NoSQL和RDBMS进行比较详尽的对比分析。

表4 NoSQL产品分类

4.1 传统RDBMS瓶颈

从时代背景来看，将来一定是大数据时代。所谓大数据，“大”在3个方面：数据量、分析量和数据种类（非结构化数据）。T级数据量向P级数据量转变时，传统RDBMS性能瓶颈频繁出现。单机处理已经很难胜任数据处理工作。之前人们致力于纵向扩展（scale-up）来解决数据量持续扩大的问题。但是事实证明无法有效解决问题，于是出现了通过向外扩展（scale-out）的方式进行针对性解决。

向外扩展对于RDBMS来说一直是一个难题，原因主要有以下几个方面。

（1）数据与事务要求过高，很难达成

假设RDBMS的表格被分散到几台电脑上，每一部分的数据在存储之前都进行了复制备份来保证高可用性。首先，执行分散性事务的同时还保证ACID特征，对于向外扩展来说是非常困难的。

·要保证原子性，那么2PC这样的协议就必须在与特定事务相关的全部系统中都用。

·要保证独立性，那么数据就必须基本上锁住。锁的单位可以是一个记录、一个表格或者一个字符。

所以要在分散式环境中保证原子性的独立性，当分布式事务协议被处理时，所有的相关系统都要被锁住；系统的服务越多，锁的任务越繁重。这就是向外扩展结构很难的原因。

（2）复制和分散数据是RDBMS向外扩展结构的另一个限制

·用2PC方法进行事务性的复制存在一个问题，就是当一个相关系统的复制操作失败时，事务本身也会失效并且变得不可用。

·WAL日志方法能够优化事务DBMS的事务提交过程。如果将系统中的复制进程看作主，变化应用进程是从，那么系统就是主从式或者多主式的。当用多主式时，就很难解决多个主进程同时写进程或阻止进程的冲突问题。

·数据本身存储结构为关系型，数据库本身的扩展限制很多，技术很麻烦。

（3）并行数据库

对于这些问题，RDBMS拥护者也做了很多研究，其中并行数据库处理就是一个很典型的例子，也取得了不少成功。

并行数据库起源于20世纪80年代，现在有很多比较成熟的版本，如Vertica、Greenplum等。这些数据库都支持标准SQL，在过去30年间实现了很多重要突破。其主要采用shared-nothing结构，将关系表在节点间横向划分，并且利用优化器对执行过程进行调度和管理。与NoSQL理论相似，其目标是高性能和高可用性。并行数据库的最大优势在于性能和其他功能支持，这主要得益于数据库近几十年的研究成果、许多先进的技术手段及算法，如索引、数据压缩、物化视图、结果缓冲、I/O共享、优化的数据连接等。但在大数据时代，数据移动的实现方式将影响其性能。

并行数据库通过SQL向外提供数据访问服务，SQL因其语言特性而被广泛使用。经过长时间的积累，市面上的大多数BI工具都支持SQL语言，数据库本身能兼容很多BI工具。不仅如此，某些数据库，如IBM DB2，还针对一些BI工具进行了优化。然而大数据却给SQL接口带来了巨大挑战。SQL的优势源于其对底层数据访问的封装，但封装却在一定程度上影响了其开放性。而且并行数据库提供的用户自定义函数大都基于单数据库实例设计，不能在机群上并行执行，也即意味着传统的实现方式不适合大数据的处理及分析。而且在并行数据库中实现用户自定义函数往往需要经过复杂的系统交互，甚至要熟悉数据库的内部结构及系统调用等，从而难以使用。并行数据库在扩展性、容错性、成本、对异构环境的支持等几项上有所欠缺，这几项实际上是相互影响的，如并行数据库大多支持有限扩展，一般可扩至数百节点的规模，尚没有数千节点规模的应用案例。

并行数据库扩展性的有限主要因为如下两点。

·并行数据库软件级容错能力较差，并行数据库基于高端硬件设计，并且假设查询失败属于稀有事件，因此当查询失败时，一般采取重做查询的方式；而在大规模机群环境下，查询失败将会变为一个普通事件，极端情况下，并行数据有可能出现不停重做查询的局面。

·并行数据库对异构硬件的支持非常有限，且对于处理较慢的节点反应敏感，容易出现“木桶效应”。所以RDBMS的功能虽然非常强大，但针对个别化问题的解决方案却很难进行扩展，于是出现了NoSQL来解决问题。

4.2 NoSQL优势

NoSQL的优势是基于其理论体系的革新理念，首先从思想上解放对数据的定义问题。得益于此，NoSQL提供一个非关系型的数据库系统，就长远发展来说，非表格化的模型允许系统的平行扩展。比起RDBMS，它没有那么结构化并且不保证ACID性，由于ACID被放弃，灵活性、扩展性和数据存储应用性都得到提升。所以它对于爆炸性数量的数据来说是很适合的。

将NoSQL的应用优势总结为以下3个方面。

（1）建立在低成本上的高性能

正如前面所说，NoSQL的简单数据模型令其本身的扩展性极强，节点的扩展也较为容易，并且由于分布式的结构，其设计理念就是建立在低成本的不稳定的机器上的，因此其可以比较低廉的成本获取高性能。另一方面的低廉指的是开发成本。目前大部分的NoSQL都是OSS（open source software），相对于要购买高额License的RDBMS来说，它是比较节省成本的。对于性能方面，NoSQL的写入性能非常优秀，在NHN的一个调查中，使用Cassandra对空的数据库插入5×107个1 KB大小的记录仅用了20 000 ps。

（2）维护简单

相对于复杂的并行RDBMS，NoSQL的设计一般都建立在低管理需求上，如自动修复、数据分布和简单数据模型都降低了管理成本。至少，这是开发目标。实际情况中，也许需要比较有经验和高素质的开发者来执行开发核心，但至少就总体来说，NoSQL对人力资源的消耗还是比较少的。

（3）易扩展

众所周知，传统RDBMS中对于添加字段等改动操作比较难以进行，必须要充分权衡，甚至要考虑崩溃问题。而NoSQL由于解放了数据限制，对于数据库的改动并不需要大成本的计算，对于列式数据库，增加一个列很简单。

4.3 NoSQL劣势

NoSQL也有很多不成熟的地方，开发上也有不少劣势。这里提到3个方面的劣势。

（1）开发消耗高

之前提到NoSQL的优势是开发成本低，这里为什么又说成本高呢？这是从学习转型的角度出发的。现在大部分公司都是RDBMS系统框架，平稳迁移的方式目前还不成熟。同时，目前NoSQL的专家级应用者还很少，公司很难寻找到合适的人员。就目前来说，人力资源的缺口还很大，人力成本并不会减少。另一方面，NoSQL的设计目标是减少人力维护资源，但现阶段并没有达成，因此相对RDBMS并没有特别明显的优势。对于用户来说，大部分仍保持观望状态，采纳的心理成本也需要考虑。

（2）商业资源模式少

现阶段大多数NoSQL都是OSS，商业性的资源比较少。由于OSS本身的发展模式尚未有很完整的体系，研究也不够深入。建立于其上的NoSQL开发也比较分散，商业资源集中度及力度都比较小。既是优势，让其能无束缚发展，但同时也是发展的一个限制，需要相关领域研究的支撑。

（3）功能不够齐全

相对于RDBMS，NoSQL还是新生代，功能支持度不高。相对RDBMS强大的功能，NoSQL仍需要时间进行改进。对于需要大量功能性操作的数据库，NoSQL并不一定是个好选择。

5 数据库选择

第4节讨论了RDBMS和NoSQL的比较。两者各自有优劣势，那么肯定会有人问，最终的选择应该是什么呢？这一节将对其进行一个指引性的讨论。

5.1 现阶段RDBMS是主流

RDBMS强大的功能确定了其主导性地位。其中，Oracle鹤立鸡群，其功能和性能都远远超出同行。对于SQL的分析功能，操作比较便捷也被广泛接受。

RDBMS在读取性能方面优势明显。对于需要读取多过写入的应用，RDBMS是一个不错的选择。

再者，最终一致性不是万能的，对于要求一致性很高的，如银行转账之类的功能，如果没有内置的ACID非常容易出问题。这时RDBMS也是一个不错的选择。

目前，RDBMS瓶颈可以通过一些向外扩展手段进行解决。如sharding技术可以帮助分区处理，从而提高性能。如果数据存储量非常大，也可以使用OwFS之类的产品。也有一些辅助的系统（如ARCUS缓存系统）来帮助提升性能。对于新型的并行数据库，如Grennplum、Aster等一些基于PostSQL的并行数据库，在性能上都还不错。

5.2 NoSQL是重要发展

什么时候考虑放弃RDBMS而使用NoSQL呢?笔者总结了以下几种情况。

·当只需要将应用实体以一个持续且一致的方式存储时，那么RDBMS太过庞大，key-value式的NoSQL也许是个好选择。

·当有一个继承式的应用对象并且需要加入一些事务处理机制时，那么所有的NoSQL方式都很适合。RDBMS也能用ORM做到，但需要掩盖复杂性本身的复杂结构。

·当需要存储大型的树状结构或网状结构式的数据时，图型NoSQL数据库比较实用。

·当运行基于云系统并且需要数据库的持久性和可用性时，Dynamo和BigTable类的NoSQL数据库比RDBMS表现更为出色。

·列式数据库对于分析有很好的作用，因为它保存了数据本身的自然性。如果需要在独立的机器上进行大型计算，Hadoop之类的MapReduce解决方案则很适合。

6 NoSQL Benchmarking

本节将提供一些NoSQL的标杆测试的理论和方法，以帮助在众多的NoSQL产品中选择合适产品。NoSQL产品众多且应用范围广，并不存在一个绝对完美的选择，但存在相对合适的产品。性能测试方面，目前有多种方法。作为开发建立性能模型的第一步，首先要能够模拟实际情况的运用，因此需要一些标杆测试工具来帮助模拟用户与数据库的实际操作情况。一个好的NoSQL标杆测试解决方案需要能够调整参数来模拟应用的特性，而在市面上存在的一些开源方法中，选择最常见的YCSB作为参考。

6.1 测试需求

数据库的测试最主要的是考虑读取和写入能力，这是大多数性能测试的基础。虽然看似简单，但对于NoSQL来说，一个好的性能测试档案应该充分考虑到特定应用在不同环境中的表现。目前大部分NoSQL方案中，无论是读取性能还是写入性能都是乐观的。所以有必要在测试时，使用不同的读写比例以多种工作负荷对性能做比较全面的分析。此外要考虑到环境的复杂性，比如Web环境中的请求率是一直改变的，所以标杆工具也要能对请求率进行调控。进入路径对于不同的应用来说，需求也是不同的。有些网络应用会含有一组经常被请求的简化数据。如网店里的打折物品，会经常被请求数据并且购买写入数据。也有些应用会对最新的记录进行大量请求，如新闻，最近的文章就会被更多地请求。因此NoSQL标杆测试工具也要能对不同的请求分布进行支持。另外一个重要的需求是提供公正的对比。应用的范畴是不尽相同的，不同的NoSQL方案应该在符合应用特性的环境下测试，才能够真正起到指导选择的作用。

6.2 YCSB

YCSB（Yahoo!cloud server benchmark）是 NoSQL 数据库标杆的代表性应用。YCSB是Yahoo!开发的一个测试框架，可以对市面上比较流行的几个NoSQL方案提供详细的对比资料，包括HBase、Cassandra、MongoDB等，未包含的数据库可以使用提供的API自行编写测试。

YCSB提供的测试框架非常灵活，用户可以对特定的参数进行设置，以针对特别产品进行分析。YCSB提供两个标杆层。第一个层次主要是测试存储性能，而第二个层次是测试扩展能力。测试性能的第一层主要是在相同硬件设置下，对比请求时延和输出的取舍。常见基本测试方法为记录工作量增加时时延的变化，直到系统饱和时输出结束。第二层次主要是测试系统增加减少节点时的性能，如增加机器时如何表现，或者在系统运转时加入机器的变化。此外YCSB提供如分布请求、读写率等多种参数，能够尽可能地模拟实际情况，做出相对正确的结论。

实际上除了YCSB，还有NoSQL等很多测试框架，如VoltDB等。这些测试框架各有千秋，对于实际应用设计还需要能够对专门的参数设置进行全面分析。针对现在的一些标杆测试，有学者提出无用居多，究其原因就是忽略了实际环境的一些问题，而比较单纯地进行基础比较。所以对于NoSQL的标杆，也需要针对具体问题进行实际测试。

7 结束语

经过上述讨论，对NoSQL有一个概念上的认识，并且对NoSQL和RDBMS的对比有了一个大致的了解。实际上NoSQL和RDBMS并不是一个完全对立的概念，也有很多产品致力于整合双方优势而取得突破。其根本性差别是数据属性。如HadoopDB是在非关系型数据库上层加入SQL层，而ASTER是在关系型数据query中应用MapReduce。面对NoSQL的众多产品群体，标杆测试必须要考虑实际环境情况，对参数的设置分析有一个比较全面的了解，尽量避免架空测试。

综上所述，对于数据库的选择，在大数据时代来临的压力下，需要更严密的思考。并不存在一个绝对正确的选择，权衡利弊，多方调查才是上策。

1 Padhy R P,Patra M R,Satapathy S C.RDBMS to NoSQL:reviewing some next-generation non-relational database’s.InternetionalJournalofAdvanced Engineerin Sceince and Tecnologies,2011,11(1)

2 Christof S.NoSQL Database.Hochschule Der Medien,Stuttgart,2011

3 Lee K J.What is NoSQL for.http://www.Cubird.com,2011

4 王珊，王会举，覃雄派等.架构大数据:挑战、现状与展望.计算机学报,2011(34)

5 Tudorica B G.A comparison between several NoSQL databases with comments and notes.Roedunet International Conference(RoEduNet),Iasi,Romania,2011

6 Cattell R.Scalable SQL and NoSQL Data Stores.ACM SIGMOD Record,2011

7 孟小峰.云数据管理与NoSQL运动.中国计算机学会通信，2011,4(7)

8 Michael S.SQL databases vs NoSQL databases.Communications of the ACM,2010,53(4)

9 Laurent A,Sala M,Laurent B,et al.Reduce,you say:what NoSQL can do for data aggregation and BI in large repositories.22nd International Workshop on Database and Expert Systems Applications(DEXA),2011

10 Tauro C J M,Aravindh S,Shreeharsha A B.Comparative study of thenewgeneration,agile,scalable,highperformance NoSQL databases.International Journal of Computer Applications,2012,48(20)

11 Schneider S A.Big data:big challenge,big opportunity.http://www.globant.com,2012