NoSQL数据库介绍

Posted 2020-07-01 damipingzi

2 NoSQL潮流

     在这一章中，将一起讨论NoSQL潮流的动机和主要驱动力，以及NoSQL主张的批评和反馈。本章将通过不同的尝试得出结论来分类和描述NoSQL数据库。其中一个分类法将在随后的章节中被提出。

2.1 动机和主要驱动力

     NoSQL这个词汇首先用在1998年对关系数据库排除SQL使用的论文（[ Str10 ]）。这个词在2009年再次被选出来，并用于非关系数据库拥护者（如Last.fm的开发者Jon Oskarsson，他组织了三藩的NoSQL见面会）的会议（[ Eva09a ]）。一个博主，通常被认为使该词汇流行的人是Rackspace公司员工Eric Evans，后来提出了NoSQL运动的雄心是“寻求替代方案的重点是，要解决关系数据库不适合的问题”（[ Eva09b ]）。

     本节将讨论这一领域中发展和使用非关系数据库的实践者并展示理论上的成果。此外，将介绍NoSQL运动的起源和主要驱动力。

2.1.1 NoSQL实践者的动机

     在计算机世界杂志一篇关于三藩的NoSQL会面的报道，“NoSQLers来分享他们如何推翻缓慢而昂贵的关系数据库的暴政，有利于用更有效和更便宜的方法来管理数据。”（[Com09a ]）。它表示特别是Web2.0初创公司，已经在没有Oracle甚至没有以前很流行的mysql的环境下开始他们的业务。相反，他们建立了自己的数据存储如Amazon的Dynamo（[DHJ+07]）和Google的Bigtable（[CDG+06]）来存储和处理大量数据的出现，比如像他们在社交或云计算应用；同时，大部分这些数据存储变成开源软件。例如，Cassandra最初是为Facebook的新搜索功能开发的，现在是Apache软件项目的一部分。根据工程师Avinash Lakshman，它在写50GB大的数据库时比MySQL快2500倍（[LM09]）。

    

     计算机世界的文章总结了常用的开发和使用NoSQL数据存储的原因：

    

     避免不必要的复杂性  关系型数据库提供了多种功能和严格的数据一致性。但RDBMS实现的这种丰富的功能和ACID特性可能对特定应用和需求来说是超配的。

     例如，Adobe的ConnectNow持有三份用户会话数据；这些副本不必须接受RDBMS的所有一致性检查，也不需要持久化。因此，完全足以将它们保存在内存中（[Com09b]）。

    

     高吞吐  一些NoSQL数据库比传统RDBMS提供更高的数据吞吐率。例如，列存储Hypertable遵循Google的Bigtable方法，允许本地搜索引擎Zvent储存每天十亿数据单元[Jud09]。再举一个例子，Google每天能够处理20PB存储在Bigtable的数据，通过它的MapReduce方法[Com09b]。

     水平扩展性和在商用硬件上运行  “肯定的，数据量是变得如此巨大，人们在寻找其他的技术”，SpringSource工程师Jon Travis说（[Com09a]）。博客作者Jonathan Ellis同意这一观点，提到现有的关系型数据库的三个问题，NoSQL数据库试图解决（[Ell09a]）：

     1.扩展数据（如Digg的绿色徽章特性（注：不明真相）3TB，Facebook的inbox搜索50GB，eBay总量2PB。注：都是10年数据）

     2.单点性能

     3.刚性模式设计

     与RDBMS相反，大部分NoSQL数据库被设计为在水平方向可扩展，且不依靠高度可用的硬件。机器可以添加和删除（或崩溃），并避免造成如同RDBMS的集群方案中实施数据分片那样的操作努力；一些NoSQL数据甚至提供自动分片（如MongoDB截至2010年3月，参见[ Mer10g ]）。Javier Soltero，SpringSource的CTO是这样说的：“Oracle会告诉你，使用正确的硬件级别和正确的Oracle RAC（Real Application Clusters）配置和其他相关软件，可以实现相同的可扩展性。但是以什么代价？”（[Com09a]）。尤其是对Web 2.0公司，可扩展性方面的考虑对他们的业务至关重要，就像Last.fm的Johan Oskarsson指出：“Web 2.0公司能够抓住机会，他们需要可扩展性。当你将这两者组合，会使NoSQL非常引人注目。”（Johan Oskarsson，Last.fm的meetup组织者和web开发，参见[Com09a]）。博主Nati Shalom同意：“成本压力也迫使许多组织寻找更具成本效益的替代品，研究表明，基于商用硬件的分布式存储可以比许多现有的高端数据库更可靠”（参见[ Sha09a ]和进一步阅读[ Sha09c ]）。他总结道：“所有的这些导致了一个高效成本的‘扩展第一数据库’的需求”。

     避免昂贵的O-R Mapping  大部分的NoSQL数据库被设计成存储要么简单的、要么与关系数据结构相比更类似于面向对象编程语言的数据结构。它们不会使昂贵的对象-关系映射成为必需（如键/值存储或文档存储）。这对具有低复杂度的数据结构的应用特别重要，因其很难从关系数据库的特性中受益。Dare Obasanjo声称“所有你真的需要[作为一个Web开发人员]是支持某种程度的查询功能并具有良好的持久性语义的键-值或元组存储。”（[Oba09a]）。博主和数据库分析师Curt Monash也在这方面表示：“SQL是过程式代码的一个尴尬的选择，几乎所有的代码是过程式的。对用户希望做重的、重复操作的数据而言，映射数据到SQL的成本是值得的。但当你的数据库结构是非常非常的简单，SQL可能不是有益的。”SpringSource工程师Jon Travis同意：“关系型数据库给你太多。他们强迫你扭曲你的对象数据以适合RDBMS。”（在[Com09a]引用）。

     在一篇计算机世界的博客中，GigaSpaces首席技术官和创始人Nati Shalom指出以下驱动了NoSQL潮流（[ Sha09b ]）：

     数据库集群的复杂性与成本  他指出，NoSQL数据库被设计成在某种程度上“PC集群可以很容易和便宜地扩展并避免分片的复杂性和成本”，涉及到将数据库切分为多个表以便在大的集群或网格上运行。

     为更好性能妥协的可靠性  Shalom认为有“应用程序愿意为更好的性能而在可靠性上妥协的不同场景”。作为一个这样的妥协例子，他提到HTTP会话数据“需要在不同的网络服务器之间共享，但由于数据是暂时的，在本质上（当用户登出时它会消失）没有必要将它存储在持久存储中。”

     现有“一刀切”的数据库思想是错误的  Shalom认为“越来越多的应用场景不能用传统的数据库方法来解决”。他认为，“这种认识实际上并没有那么新”，因为Michael Stonebraker的研究（见下文）已经有很多年了，但过去几年，老的“新闻”已经蔓延到了一个更大的社区。Shalom觉得，对传统RDBMS的替代品的实现和研究可以用两个主要趋势解释：

     1.连续增长的数据量（需存储）

     2.在更短的时间内处理大量的数据的需求不断增长

     一些公司特别是Web系的，已经采用NoSQL数据库，Shalom预计随着这些数据存储的成熟，他们会找到自己的方式用于主流开发。博主Dennis Forbes同意这一观点，强调银行的要求不是普遍的，尤其是社交媒体网站有不同的特点：“数据的孤岛”、一个“非常低的用户/事务比值”和数据完整性的需求不强。考虑到这些特点，关于社交媒体网站和大型网络应用他有如下观点：

     “事实是，Facebook更新状态或推特或Slashdots评论不需要ACID。只要你的业务和表现层可以有力地处理不一致数据，这并不真的很重要。很明显这不是理想的，并且最好没有任何数据损失、不一致或服务中断，但是接受数据丢失或不一致（甚至只是暂时的）作为一种可能性，打破了迄今为止关系数据库世界最大的’障碍’，可以产生巨大的灵活性。

     这是许多社交媒体网站的情况：数据的完整性基本是可选的，保证完整性的费用是不必要的开支。成千上万的用户和成千上万的事务后，当你从广告点击赚到钱，你开始寻找优化。”

     Shalom建议小心走向NoSQL解决方案和熟悉他们的具体优势和劣势（例如：业务逻辑处理不一致的能力）。其他，像10gen（MongoDB背后的公司）的David Merriman也强调，数据存储没有一个单一的工具或技术，但数据库领域有一个分裂目前正在进行中，带来了新的和不同的数据存储，例如商业智能vs.在线事务处理vs.大量二进制数据的持久化（[Tec09]）。

     简易分布和集中数据模型划分的神话  Shalom进一步提到围绕这一直觉的神话，即数据模型最初设计为一个单一的数据库（集中式数据模型，正如他所指出的）经常不能轻易在数据库服务器间分区和分散。这意味着，如果没有进一步的努力，应用程序将既无法按需扩展也不能正确工作。Ajatus的专家同意这种说法，在博客中说，如果数据库会增长，首先应配置复本。此外，随着数据量的进一步增长，数据库分片需要昂贵的系统管理，需要大量资金或财产聘用DBMS供应商来经营分散的数据库（[ Aja09 ]）。Shalom报道了2009夏天eBay的一次架构峰会。与会者一致同意，虽然通常情况下，抽象被引入以试图隐藏应用程序（如通过代理层将请求路由到特定的服务器）中分散和分区问题，“这个抽象无法将应用与分区和分散的现实隔离。故障幅度在一个网络内完全不同于一台机器内的故障。应用程序需要注意到延迟、分布式故障等，使得它有足够的信息来做出具体的上下文相关的决定。系统是分布式的事实渗透到这种抽象中。”（[ Sha09b ]）。因此他建议设计数据模型以适应分区环境，即使最初只有一个集中式数据库服务器。这种方法提供的优势是避免极晚且昂贵的应用代码更改。

     Shalom总结，在他看来，DBMS将不会很快消失。然而，更专业的解决方案会有用武之地，因为一个“一刀切”的思想曾经是并且现在还是对于数据库的错误认识。

     编程语言和开发框架的潮流  博主David Intersimone额外观察了编程语言和开发框架（其提供对数据库访问的抽象时试图隐藏SQL以及关系数据库的使用（[ Int10 ]））的趋势。这一趋势在过去几年的例子包括：

•      Java和.NET世界中的实体关系映射，如Java持久化API（JPA，EJB3规范的一部分，[DKE06],[BO06]），实现如Hibernate（[JBo10a]），或带SQLMetal代码生成器的LINQ Framework（[BH05]），和从.NET version4 开始的ADO.NET Entity Framework（[Mic10]）。
•      同样的，流行的Ruby on Rails框架（[HR10]）和其他隐藏关系型数据库使用的尝试（如实现RoR中的动态记录模式）
•      NoSQL数据存储以及一些云计算供应商提供的数据库完全省略了关系数据库。这样的云数据存储的一个例子是Amazon的SimpleDB，一个无模式，基于Erlang的最终一致性的数据存储，其特点是作为一个实体的属性值（EAV）。它可以存储大量items的集合，其中items是装载由键值对组成的属性集的hashtable（[ Nor09 ]）。

     这些NoSQL数据库反应这一趋势，并尝试在他们的API中提供接近于编程语言的数据结构（例如，键/值结构，文档，图表）。

     云计算的需求  在一次采访中10gen（MongoDB背后的公司）的Dwight Merriman提到了在云计算环境中数据存储的两个主要需求（[ Tec09 ]）：

     1、高直到几乎无限的可扩展性，特别是在水平方向

     2、低管理开销

     在他看来，下面几类数据库在云中工作很好：

•      数据仓库型特定数据库，为批量数据处理和Map/Reduce作业设计的
•      简单，可扩展和快速的键值对存储
•      包含比键值对存储更丰富特性的数据库，填补了传统RDBMS的空白，并提供良好的性能和扩展性（如文档数据库）

     博主Nati Shalom同意Merriman，事实上应用领域如云计算等对NoSQL数据库是助力：“过去是只有少数相当高端的组织面对的利基问题，随着社交网络和云计算的引入更为普遍了（[ Sha09a ]）。

     RDBMS加缓存层模式/工作区 vs. 考虑扩展性从零开始构建系统  在他的文章“MySQL和Memcached：一个时代的结束？”中，Todd Hoff说“在云出现前，关系型数据库为主的世界”的可扩展性是“利用MySQL和memcached”的一个问题：

     “对MySQL分片以处理高写入负载，再memcached中缓存对象以处理高读负载，然后写了大量的胶水代码使其全部工作在一起。那曾经是艺术，那曾经是必须这样做的。今天许多主要网站的架构仍遵循这种模式，很大程度上是因为在投入足够的力气时，它可以工作。”（[ Hof10c ]）

     但随着可扩展性要求的增长，这些技术越来越不能够适应他们。此外，随着NoSQL数据存储的发展Hoff得出结论：“看远一点，很明显MySQL + memcached的时代正在过去。它将坚持一段时间。旧技术很少完全消失。”（[ Hof10c ]）。作为例子，他列举了大网站和玩家走向非关系数据存储包括LinkedIn、Amazon、Digg和Twitter。Hoff提到以下使用NoSQL解决方案的原因，已在本文前面解释：

•      关系数据库在读时计算，这对大型网络应用（如Digg）被认为是错误的。NoSQL数据库因此不提供或避免复杂的读操作。
•      应用程序的线性特性需要经常等待从数据存储的I/O，这对可扩展性和低响应时间不利。
•      大数据量和高的生长因子促进Twitter开始使用Cassandra，它被设计为可操作大尺度数据。
•      此外，像Twitter这样的公司运行和维护系统的运营成本不断上升。这种规模的网络应用因而“需要一个可以以更自动化的方式来发展并高度可用的系统”（在[ hof10c ]引用）。

     由于这些原因以及MySQL和memcached时代的“笨拙性”（Hoff所谓的），现在的大型（网络）应用程序可以利用从头开始建立可扩展性的、非阻塞和异步数据库I/O、海量数据、维护和操作任务的自动化处理的系统。他认为这些系统是更好的替代品，相比RDBMS加对象缓存。Amazon的James Hamilton同意这一声明，对许多大型网站的可扩展性，从零开始是至关重要的，甚至比与传统RDBMS相比缺少部分特性的劣势更重要：

     “扩展第一的应用程序是那些绝对必须不受约束地扩展，且无约束扩展这件事比更多的特性更重要。这些应用有大规模大型网站如Facebook、MySpace、Gmail、Yahoo和Amazon。一些网站实际上是利用关系数据库，但很多不是。所有这些服务的共同主题是，扩展比特性更重要，他们没有可能运行在一个单独的RDBMS上。”（参见[ Ham09 ]引用[ Sha09a ]）

     昨日的需要 vs. 今日的需要  在关于CouchDB的讨论中，Lehnardt和Lang指出对于数据存储的需要已经发生了很大的变化（[ PLL09 ]；这一论点由Stonebraker进一步迭代，见下文）。在上世纪60和70年代的数据库被设计为单一的大型高端机器。与此相反，今天，许多大型（网络）公司使用可能会故障的商用硬件。因此应用程序被设计来处理这样的故障，被认为是“操作的标准模式”，就像Amazon指出的（参见[ DHJ+07，205页]）。此外，关系数据库适合的数据是刚性结构的关系，并允许用一个复杂语言表示的动态查询。Lehnhardt和Lang指出，今天，特别是在网络领域，数据既不是严格的结构，也不需要动态查询，大多数应用程序已经使用准备语句或存储过程。因此，数据库内预定义查询和动态赋值给变量是足够的（[ PLL09 ]）。

     此外，关系数据库最初设计为集中部署，而不是分布。虽然对集群的强化已被加入，它仍然是通过传统的没有分布式的概念开始设计（像如下提出的“网络计算的设施”问题）。作为一个例子，通常同步未有效地实现，而是需要昂贵的协议，如两或三阶段提交。Lehnhardt和Lang看到的另一个困难是，关系数据库集群的尝试是“透明”的应用。这意味着应用程序不应该包含任何它在和一个单独的机器或一个集群进行交谈的概念，所有分布式的方面都试图从应用程序中隐藏。他们质疑这种保持应用程序感知不到任何分布式的后果的方法，如在著名的八个分布式计算的谬误中描述的（[ Gos07 ] ）：

     “基本上每个人，当他们初次构建一个分布式应用程序时，会做出以下八假设。它们在长期运行过程中都被证明是错误的，都会导致大麻烦和痛苦的学习经验：

     1、网络是可靠的

     2、延迟是0

     3、带宽是无限的

     4、网络是安全的

     5、拓扑是不变的

     6、有一个管理员

     7、传输的消耗是0

     8、网络是同构的”

     虽然典型的使用RDBMS的业务应用程序，在大多数情况下，尝试在应用中隐藏分布式细节（例如：通过集群、持久层做对象关系映射），但许多大型网络公司和大部分的NoSQL数据库不追求这种方法。相反，他们让应用程序知道并利用它们。这在Lehnardt和Lang眼中被认为是一个范式转变（参见[ PLL09 ]）。     

     进一步的动机  除了上面提到的，David Intersimone看到NoSQL潮流的以下三目标（[ Int10 ]）：

•      获得较关系数据库小的的开销和内存占用
•      通过Web技术和RPC调用访问
•      数据查询的可选形式

2.1.2 理论工作

     在广泛采用的论文“架构时代的终结”（[ SMA+07 ] ）中，Michael Stonebraker等得人出结论“现有的RDBMS的代码，试图成为一个’一刀切’解决方案，事实上不擅长于任何事”。在这种情况下没有任何东西意味着他们能与超越他们“1–2个数量级”（[ Sc05 ]、[ SBc+07]）的“数据仓库、数据流处理、文本和科学数据库市场的专用引擎”竞争，在他们熟悉的业务数据处理/在线事务处理（OLTP）市场也表现不好，其中一个麻省理工开发的名叫H-Store的原型在TPC-C基准上打败RDBMS将近两个数量级。由于这些结果，他们得出结论，RDBMS是“应退休的25岁的遗留代码，取而代之的是一系列‘从零开始’研发的专用引擎。数据库管理系统供应商（和研究界）应该开始用一张白纸为明天的要求设计系统，而不是继续为昨天的需求推动代码行和架构设计”。但Stonebraker等人如何得出这个结论？他们在关系型数据库管理系统中发现什么固有的缺陷？他们为“完全重写”提供什么建议？

     首先，Stonebraker等认为，RDBMS架构已经超过25年，当时硬件特性、用户需求和数据库市场与今天的不同。他们指出，“流行的RDBMS全部能追朔到20世纪70年代的System R”：IBM的DB2是一个System R的直系后代，微软的SQL Server从Sybase System 5进化而来（另一个System R的直系后代），Oracle在其第一个版本中实现了System R的用户界面。因而，System R的架构已经被70年代的硬件特性影响了。那以后，处理器速度、内存和磁盘的大小有显著增加，这些因素今天已经不像过去那样限制程序。然而，硬盘和内存间的带宽并不像CPU速度、内存和磁盘大小那样增加得快。Stonebraker等批评，硬件领域的发展没有影响RDBMS的架构。尤其是以下的System R的架构特点仍然在今天的RDBMS中可以找到：

•      面向磁盘的存储和索引结构
•      多线程来隐藏时延
•      基于锁的并发控制机制
•      基于日志的恢复

     在这方面，他们强调说，虽然“过去几年有了一些延伸，包括支持压缩、共享磁盘架构、位图索引、支持用户定义的数据类型和操作，但从一开始就没有任何系统的重新设计”。

     其次，Stonebraker等人指出，自20世纪70年代以来，新的市场和用例已经出现，但可用的只有商业数据处理。这些新兴市场的例子包括“数据仓库、文本管理和流处理”，“它们的需求与商业数据处理有很大的不同”。在先前的文章（[ Sc05 ]）他们已经说明了RDBMS“会在一些应用领域被专业的架构超过一个数量级或更多，包括：

•      文本（专业引擎如Google，Yahoo等）
•      数据仓库（列存储如Vertica，Monet等）
•      流处理（流处理引擎如StreamBase和Coral8）
•      科学和智能数据库（数组存储引擎如MATLAB和ASAP）”

     他们继续注意到，过去几十年用户界面和使用模式也改变了，从“操作员输入查询”的终端到富客户端和网络应用程序，今天互动查询和直接的SQL接口是罕见的。

     Stonebraker等现在给出了“目前RDBMS的架构甚至不适合业务数据处理的证据”。他们设计了一个OLTP的DBMS引擎称为H-Store，其在功能上适于跑TPC-C基准，比流行商用DBMS快82倍。基于这样的证据，他们总结“它们在任何一个市场都没有竞争力。因此，他们应该被视为超过四分之一个世纪的过时技术，完全重新设计和重构是适当的下一步”。

设计考量

     在一篇关于设计考量的文中，Stonebraker等人解释为什么即使在业务数据处理的老本行内RDBMS也被超越，以及他们自己的DBMS原型H-Store为何可以实现“比现有的RDBMS好得多的性能”。特别是他们的考虑反映过去几十年的硬件发展，以及它如何能或应该改变RDBMS的架构以便从更快和更大的硬件中获得好处，也给他们坚持的“完全重写”以注解。

     主内存  与70年代相比，大量的主内存变得便宜，因为“OLTP数据库绝大多数是小于1TB并且增长得相当缓慢”他们得出这样的结论：这样的数据库是“现在或在不久的将来能够部署在主内存中的”。Stonebraker等人因此认为OLTP市场在今天或在不久的将来是内存数据库市场。他们因此批评，“目前RDBMS供应商用面向磁盘的解决方案处理主内存问题。总之，摩尔定律的30年已使OLTP应用程序的面向磁盘的体系结构变得过时”。虽然有些关系数据库在内存中运行（例如TimesTen，SolidDB），但这些系统也从System R继承了“包袱”——Stonebraker等人对基于磁盘的恢复日志或动态锁定的称呼，这对这些系统的性能有负面影响。

     多线程和资源控制  如前所述，Stonebraker等人认为数据库是主内存市场。现在他们表示，事务通常只会影响到只有少数几个需要读/写的数据集（如TPC-C基准测试中最多200读），如果这个数据是保存在内存中且没有磁盘IO或出现用户中断，将是非常划算的。因此，他们认为在这样的主内存数据库中不需要多线程执行模型，这使得传统关系数据库中相当多的“详细代码”无关紧要，即多线程系统为了最大限度地提高中央处理器和磁盘的使用，资源管理者限制负载以避免使用消耗资源的和多线程的数据结构如并发B树。“这是一个更可靠的系统，一个有更高性能的系统”，他们说。为了避免在这样一个单线程系统中长期运行的事务，要求应用程序将此类事务分解为较小的事务，或——在分析的目的下——在为该任务优化过的数据仓库中运行这类事务。

     网格计算和在线扩容  此外，Stonebraker等人概述了70年代共享内存架构、80年代共享磁盘架构、今天和未来的无共享架构的发展，这“通常被称为网格计算或刀片计算”。作为一个结果，Stonebraker等人坚持数据库必须反映这一发展，比如（和最明显的）DBMS网格中多节点间的水平分割。此外，他们主张这种网格的增量水平扩展应该无需由管理员重新加载部分或所有数据，也不停机。他们指出，这些要求显著影响了DBMS的架构，如在不影响运行事务的条件下传输数据的能力，这可能不能很容易地添加到现有的RDBMS中，但可以在新系统的设计中考虑（像比较新的数据库如Vertica）。

     高可用性  Stonebraker等人陈述的下一主题是高可用性和故障转移。又一次，他们概述了这一问题的历史发展，从线下保存当灾难发生时再恢复的日志磁带，到将日志磁带挂在远程硬件上并提供灾备服务，到今天很普遍的热备份或多站点解决方案。Stonebraker等人把高可用性和内置的灾难恢复作为一个重要的功能，像他们提到的其它设计问题一样，在这些系统的架构和设计层面考虑。他们特别需要OLTP领域的DBMS具有：

     1、保持多个副本一致，需要在地理位置上分散的系统上无缝运行的能力

     2、开始在系统底层使用无共享的支持，用于取代SMP架构上多计算机的支持

     3、支持无共享架构的最好方式是，用“对等网络环境下的多台机器”以便“负载可以分散在多台机器，机器间的副本可用于容错”。在这样的配置中，普通操作下可以利用所有的机器资源，且故障只会导致退化的操作因为只是可用资源较少而已。相比之下，今天的HA解决方案在普通操作下有一个热备份只利用硬件资源的一部分，因为热备机器只是在等待活跃机器死掉。总之“这些观点说明应完全重新设计RDBMS引擎，使其在新架构下实现点对点的HA”，他们得出这样的结论。

     在这样一个Stonebraker等人要求的高可用系统，他们看不到任何重做日志的需要，如在一个站点故障的情况下，恢复活动“可在任一站点的数据上刷新”。因此，只需要一个撤销日志以允许回滚事务。这样的撤销日志不需要储存超过一个事务的周期，因此，“可以是一个主内存数据结构，在事务提交时被丢弃”。正如“在HA的世界，将没有持久化的重做日志，只有一个短暂的撤销日志”，Stonebraker等人发现另一个潜在的机会以去掉从重做日志恢复的复杂代码；但他们也承认，这种恢复逻辑只是转化为“当失败站点恢复运行时从运行中站点得到最新数据的新功能”。

     无调整  最后，Stonebraker等人指出当前的RDBMS是在一个“电脑很贵，人很便宜的时代”被设计的。今天恰恰相反，人员成本是一个IT公司的主要支出。他们特别批评说“RDBMS有大量复杂的

性能调整，这是旧时代的过时特性”但仍在使用，因为RDBMS的自动调整辅助“不会带来比一个熟练DBA的更好效果”。为取代提供这类只是为了调整而寻找更好配置的特性，Stonebraker等人需要一个数据库，没有这样的调整只有“自我的一切”（自我恢复，自我维护，自我调节等）。

关于事务，处理和环境的考虑

     探讨了自上世纪70年代时设计RDBMS以来IT企业的发展历史，以及这种发展对架构的影响，Stonebraker等人现在转向其他问题，这些会对系统的性能产生不利影响：

•      重做日志持久化必须避免，因为它们是“几乎保证是一个显著的性能瓶颈”。在HA/故障恢复系统上面它们可以完全省略。
•      客户端与数据库之间通过JDBC/ODBC接口的通信是他们提到的下一个引起性能衰退的问题。取代这样的接口，他们“提倡在数据库系统中‘在进程内’运行应用程序逻辑，通过存储过程的形式”，以避免“传统的数据库客户机/服务器模式所隐含的进程间开销”。
•      他们建议进一步消除撤销日志，“不管实际情况，因为它也将是一个重要的瓶颈”。
•      解决的下一个性能瓶颈是允许并发访问的动态锁。动态锁定的成本也应减少或消除。
•      多线程的数据结构导致事务加锁。如果事务的运行时间很短，一个单线程执行模型可以消除这种闭锁与多线程数据结构的开销，只会“在性能上有小损失”。
•      最后，两阶段提交（2PC）事务应尽可能避免，由于该协议造成的网络传输回合将导致性能下降，因为它们“通常以毫秒级的时间先后发生”。

     如果这些建议可以被满足，Stonebraker等人随后指出基于OLTP特点的事务和大纲（schema）特性。

事务和大纲特性

     除了以上讨论的硬件特性、线程模型、分布式或可用性要求，Stonebraker等人还指出了数据库大纲的特性以及事务属性也显著影响DBMS的性能。关于数据库大纲和事务，他们认为DBMS应该利用以下特点：

     树形大纲  是如下的数据库大纲：“每一个表除了一个叫根的节点，都有且只有一个与祖先节点是1-n关系的连接（join）。因此，大纲是一个1-n关系的树”。有此属性的大纲，特别容易在一个网格上的节点之间分布，“这样所有树中的等值连接跨度只有一个单一的站点”。这种模式的根表通常由它的主键分区并移动到网格的其他节点，使每个节点上有根表的分区以及其他表中该根表分区的主键值所对应的数据。

     受约束树应用（CTA）    在Stonebraker等人的概念中，CTA是一个有着树形大纲的应用程序，且只执行有下列特性的事务：

     1、每一个事务类中的每一个命令都有根节点主键的相等谓词

     2、“对一个站点而言，每一个事务类的每一个SQL命令是本地的”

    事务类是“相同的SQL语句和程序逻辑的集合，只有每个事务的运行时常量不同”，Stonebraker等人在他们的H-Store原型中预先定义了。他们进一步认为，目前的OLTP应用通常设计为CTA的，或至少可以以这种方式将其分解，并建议系统地应用大纲变换以使应用满足CTA（[ SMA+07，页1153 ]）。这些努力的好处是“CTA可以非常有效地执行”。

     单站点事务  只能在一个节点上执行，而不需要与DBMS网格的其他节点进行通信。如受约束树应用满足这种属性。

     一次性应用  完全由“可并行执行且不需要在站点中传输中间结果的事务”构成。此外，一次性应用中的查询从不使用更早的查询结果。这些属性允许DBMS分解事务“到一个单站点执行计划的集合，它可以被分派到适当的站点执行”。一个普通的使应用一次性的技术是在站点间进行垂直分表。

     两阶段事务  是指这样的事务：包含第一阶段的读取操作，该操作可以根据它的结果导致事务的取消，和第二阶段的写操作，该操作保证不会造成任何完整性冲突。Stonebraker等人说，很多OLTP事务具有这种属性，因此利用它在他们的H-Store原型中替代撤消日志。

     强两阶段事务  在两阶段事务之外，加入了第二阶段所有站点回滚或完成事务的属性。

     事务可交换性  由Stonebraker等人定义如下：“来自相同或不同的类的两个并发事务可交换，仅当不管怎么交织时单站点的子执行计划都产生同样的最终数据库状态（假设两个事务都提交）”。

     无菌事务类  是“和所有事务类（包括其自身）”可交换的事务类。

H-Store概述

     讨论了数据库管理系统设计时应考虑的参数，Stonebraker等人给出H-Store原型，在TPC-C基准中性能明显优于商业数据库。他们的系统草图不在本文中重复（详细信息可以在[ SMA+07页154 ]），但一些属性应当提及：

•      H-Store运行在网格上
•      表的每一行在内存中连续存放
•      使用B树索引
•      站点被划分成逻辑站点，每个对应一个CPU核
•      逻辑站点是完全独立的，具有自己的索引、元组存储和他们所在机器的主内存的分区
•      单线程工作，事务不可中断
•      仅允许运行以存储过程实现的预定义事务
•      省去了重做日志并试图尽可能避免写撤消日志；如果撤消日志无法避免它在事务提交时被丢弃
•      如果可能，查询执行计划利用上述讨论的单站点和一次性属性
•      尝试实现无调整和高可用性需求，以及通过“指定水平分区、复制位置、索引字段的全自动物理数据库设计器”实现事务的单站点变换
•      因为H-Store保存每个表的多个副本，需要事务地进行更新。读命令可以去表的任何副本，而更新是针对所有副本
•      H-Store利用上述事务和大纲特性进行优化，例如在两阶段事务中省略撤消日志

TPC-C基准

     当比较他们的H-Store原型与商业DBMS，Stonebraker等人应用了一些针对基准测试实现的重要技巧。首先，他们在对数据库大纲和它的副本分区时，使用了“分解模式，这样每个站点都有一个源于一个独特的仓库分区记录的子集”的方法。其次，他们讨论如何利用上面讨论的事务特性。如果基准将运行“在一个单核心，单CPU的机器”那么“每一事务类会是单站点的，且每个事务可以运行在一个单线程环境”。在一个“成对HA的站点，所有的事务类都可以当成强两阶段，这意味着所有事物将在这两个站点上成功或中止。因此，在一个单一的成对HA的站点上，ACID特性可以没有任何开销地实现”，通过进一步应用技巧，他们实现“使用[模式分区和复制的]基本策略并用上面描述的技巧增强，所有事物类成为一次性的和强两阶段的。只要我们加一个短延时，ACID特性可以在无任何并发控制开销的情况下实现。”

     基于此设置，他们实现了比商业DBMS的性能好82倍。他们还分析了在商业DBMS的性能开销，发现主要是由日志和并发控制引起的。

     据说Stonebraker等人仅实施TPC-C基准测试的一部分，且似乎并未调整TPC-C基准测试使之完全适合商业DBMS，就像他们为自己的H-Store原型做的，尽管他们聘请了专业的DBA调整与H-Store对比的DBMS，并尝试优化系统的日志以允许它更好地执行。

结论

     鉴于他们的分析，Stonebraker等人得出这样的结论：“我们正走向一个至少有5个（可能更多）专用引擎和‘一刀切’的过时系统死亡的世界”。这适用于关系模型以及它的查询语言SQL。

     Stonebraker等人说与“DBMS世界中只包含业务数据处理”的上世纪70年代相反，如今至少有以下市场需要专用DBMS：

     1、数据仓库  通常有星形或雪花形模式，如“一个中心事实表与周围的维度表作1-n连接，并可能进一步的与第二层的维度表作1-n连接，等等”。这些数据可以很容易地使用关系模型建模，但Stonebraker等人建议一个实体关系模型对建模和查询来说将更简单、更自然。

     2、流处理  这个市场有不同的需求，即“高速处理信息流[和]关联这样的流与存储的数据”。一个SQL的泛化称为StreamSQL，允许使用SQL的FROM语法混合流和关系型数据，引发了一些热情，并被建议当作此领域的标准。Stonebraker等人还提到在流处理中经常需要流数据是扁平的（如一些新闻机构提供的数据流），但也有层次化结构数据的需要。因此，他们“期待流处理厂商更积极地进军层次数据模型”，“他们一定会偏离Ted Codd原则”。

     3、文本处理  是一个关系型数据库从未被用到的领域

     4、面向自然科学的数据库  因为基础数据结构的原因更可能支持向量而不是表

     5、半结构化数据  该领域有用的数据模型仍在讨论。一些建议包括XML大纲（因为其复杂性争论激烈）和RDF

     “当关系模型为‘一刀切’的世界而设计，我们设想的各种专业系统可以让我们重新思考什么样的数据模型将更适合他们的特定需求”，Stonebraker等总结道。

     关于DBMS查询语言他们反对“一刀切的语言”如SQL，在他们看来，根本没有需要SQL的用例：在OLTP市场即席查询很少或不需要，应用程序以预备语句方式查询，或查询逻辑以存储过程形式被部署到DBMS中。与此相反，其他DBMS市场如数据仓库需要复杂的即席查询能力，这是SQL不能满足的。为此，Stonebraker等人看不到还需要这样的语言。

     针对上述市场中的专业DBMS，他们进一步探讨如何将这些语言与编程语言集成，且反对“连接到任何编程语言”的数据子语言如JDBC和ODBC做的。“[这]导致了高开销的接口”。Stonebraker等人因此建议“在编程语言中嵌入数据库的功能”。这样的语言嵌入例子包括，上世纪70年代的Pascal R和Rigel，或今天微软在.NET平台的LINQ方法。关于语言整合这样的能力，他们喜欢他们所谓的“小语种”如Python，Perl，Ruby和php，他们“开放源码，可以通过社区改进”，此外“比目前通用的语言（被看作编程语言世界中的一刀切的方案）更容易修改”。他们的H-Store原型中的存储过程计划从C++迁移到Ruby。

2.1.3 主要驱动

     在过去的几年中NoSQL潮流吸引了大量的企业和项目。特别运行大型和高频网站的大网络公司或企业已经从关系数据库（通常有一个缓冲层典型地如memcached，参见[ Hof10c ],[ Hof10b ]）切换到非关系数据存储。例子包括最初由Facebook开发的Cassandra（[ Apa10d ]）且今天还被Twitter和Digg使用（[ Pop10a ]、[ Eur09 ]），LinkedIn开发和使用的Project Voldemort，存储云服务如NoSQL存储Amazon SimpleDB（[ Ama10b ]），以及Ubuntu One，一种基于CouchDB的云存储和同步服务（[ Can10c ]、[ Hof10c ]）。这些NoSQL数据存储的用户，天然地对他们使用的非关系型解决方案的进一步发展非常感兴趣。然而，最流行的NoSQL数据存储所采用的思想是Google的Bigtable（[ CDG+06 ]）或Amazon的Dynamo（[ DHJ+07 ]）；Bigtable启发的NoSQL存储通常被称为列存储（例如HyperTable，HBase），而Dynamo主要影响键/值存储（如Cassandra[ Apa10d ]，Redis[ S+10 ]，Project Voldemort[ K+10a ]）。其他项目追求不同的尝试，如图形数据库形成一类自己的数据存储；和文件存储，这可以被看作是具有附加功能的键/值存储（至少允许键/值对具有不同的、通常是分层的命名空间，提供了“文档”的抽象）；后者中至少一个（CouchDB）是现有文档存储如上世纪90年代的Lotus Notes的重新实现，因此没有结合当前的网络技术进行设计（这被CouchDB开发者们批评，他们又从零开始实现他们的文档存储，参见[ Apa10c ]、[ PLL09 ]）。综上所述，可以得出的结论是NoSQL潮流的先驱主要是大型网络公司或运行大型网站的公司，如Facebook，Google和Amazon（[ Oba09a ]），和在这一领域的其他人通过他们的想法和修改以满足自己的需求。

2.2 批评

2.2.1 商业方面的怀疑

     在一篇计算机世界关于三藩的NoSQL见面会的文章，提到一些NoSQL数据库的业务相关的问题。它们中的大多数都是开源软件，被不关心许可证和商业支持问题的开发者欣赏。然而，特别是出问题后没有人可责备的情况会吓到商务人士。即使在Adobe，开发人员使用Terracotta集群替代关系数据库，也只有在让他们的经理看到了系统启动和运行时才能说服他们（参见[ Com09a ]）。

2.2.2 过度宣传的NoSQL

     一些企业开始谨慎面对NoSQL，因为这一潮流似乎是一个炒作，潜在地缺乏对承诺的履行。这是一种对新技术唤起热情的普遍怀疑态度，如James Bezdek在IEEE通讯中表述如下：

     “每一个新的技术开头总是天真愉悦，它的发明者通常淹没在他们自己的想法中；他们最初的同僚体验了大部分狂热的热情。大多数技术过度承诺，往往不是简单地生成资金继续这项工作，资金是科学发展的一个组成部分，除了它，只有最具想象和革命性的想法使它度过胚胎阶段。炒作是过度承诺的自然伴生，大多数技术快速构建以达到炒作的顶点。之后，几乎总是对没有得到充分开发的想法的过激反应，这不可避免地导致崩溃，接下去是一个时期的冷嘲热讽。许多新技术的发展到这一点，然后消失。幸存下来的那些是因为有人发现了一个基本思想的好应用（=真实的用户利益）。”（[ For10 ]引用[ Bez93 ]）

     三藩NoSQL见面会的参与者给出务实的建议：如果公司有一个关系数据库在工作，并且不切换到NoSQL数据库的话什么都不会失去，那就没有任何理由来取代它。即使见面会的组织者，Last.fm的Johan Oskarsson也承认，截至2009年6月Last.fm尚未在生产中使用NoSQL数据库。他还指出NoSQL数据库“目前和主流企业不相关，但一两年后可能会改变”（[ Com09a ]）。然而，NoSQL见面会的参与者建议如果可能的话看一下NoSQL方案，它是有意义的（例如，在开发新软件）（[ Com09a ]）。博主Dennis Forbes说在非关系型数据存储的发明者和开发者之间看不见任何过度热情（“他们大部分是聪明的，务实的开发者”），但使用这些技术开发人员却希望“这个潮流解决他们的弱点”。他——一个为金融、保险、电信、电力等行业做传统的关系数据库开发——却说“无疑是很多奇妙的工作发生的NoSQL阵营中，很关注可伸缩性”。另一方面，在他博客的评论中批评说：“争论的是，聚会的本身，被正在或希望建立非常大的网络公司的人劫持了（都希望成为下一个Facebook），该领域的价值观和判断投射到整个数据库产业——其包括一系列使社交媒体的边缘例子也相形见绌的解决方案——这真是讽刺”（[ For10 ]）。（注：不懂，好像是在骂人）

2.2.3 NoSQL没有什么创新

     类似于炒作的论点，对NoSQL的另一种批评是，NoSQL数据库没什么创新因为其他尝试如对象数据库已经存在了几十年。作为这个争论的例子，博主David Intersimone提到Lotus Notes可以归入早期的文档存储，且支持分布和复制而有利于并发控制的性能（除非另有说明，[ Int10 ]）。一个特别有意思的例子是，CouchDB的主要开发者，Damien Katz，曾为Lotus Notes工作几年。NoSQL的拥护者认为CouchDB是“Notes的成功”，因为Notes的分布特征并没有利用当前的网络技术，软件本身也不是一个精干的数据存储而是因业务相关的特性而臃肿（[ PLL09 ]）。

     例如Lotus Notes，商业分析或面向流处理的数据存储显示，这类关系数据库的替代品已经存在了很长的时间，博主Dennis Forbes因此批评，“一刀切”的说法只不过是一些人的挡箭牌，因为他们只使用过RDBMS作为处理所有的结构化和非结构化数据存储需求的工具（[ For10 ]）。

2.2.4 NoSQL代表完全的“没有SQL”

     首先，很多NoSQL的主张特别是在博客上的，将这个术语和潮流看作RDBMS的完全否定和这些系统的死亡宣告。“NoSQL”术语通常与Eric Evans联系在一起，虽然他不是第一个用它（见2.1节，如[ Ell09a ]）。2009年的一篇博客认为，现在这个词的意思是“不应只有SQL（Not Only SQL）”而不是“没有SQL”（[ Eva09b ]）。这个词已经被许多博客作者所采纳，因为它强调了数据库中的持久性不意味着只能使用RDBMS而是有替代品存在。博主Nati Shalom评论如下：“我认为我们所看到的是更多的一种现实，现有的SQL数据库方案可能不会很快消失，但同时他们不能解决世界上所有的问题。有趣的是，NoSQL这个词已经变为Not Only SQL，以代表这一思路”（[ Sha09a ]）。一些博主强调这个词语不精确，如Dare Obasanjo说，“还没有什么产品是‘NoSQL’数据库的确切技术定义，当事实上它不是一个关系数据库”（[ Oba09a ]）。其他人，如Michael Stonebraker声称，根本和SQL没半毛钱关系，应该叫“NoACID”之类，这是由Dennis Forbes提出的并在他的建议里引用了Stonebraker（[ For10 ]）。还有一些人如Adam Keys批评术语“NoSQL”只定义了它不代表什么趋势（[ Key09 ]）：“这个名字的问题是，它只定义了它不是什么。这使得它是对抗性的，它所包含或排除的东西不令人惊讶。我们看到的是，它终结了有价值的数据应该保存在某种关系数据库的假设；终结了SQL和ACID是解决我们问题的唯一工具的假设；终结了主/从模式的活力；终结了在我们的应用程序代码里编织关系模式”。他建议把这种潮流和数据存储归入“后关系型”而不是“NoSQL”：“我们看到关于应如何存储重要数据的思维爆炸；我们审视数据来看是否值得持久化；我们尝试新的语义结构、一致性和并发性。如同后现代主义是反思过去的艺术和建筑的方式，后关系型是软件开发商重新考虑自己方式的一个机会。正如后现代主义并不能否定整个艺术史，后关系型不会终结关系数据库的实用性。”（[ Key09 ]）。然而，像他博客的读者评论的，这个词并不比“NoSQL”更好，因为它仍只是定义这个潮流和这样的数据库不反映（或更好的：他们所省略）的东西，而不是它们主张什么。

     对这个词的刺激和作为关系数据库的忽视部分的第一观念，已经带来了NoSQL支持者们许多发人深省的语句，并造成一些无益的讨论和一些激烈争论（例如[ Dzi10 ]和它的响应[ Sch10 ]）。

2.2.5 Stonebraker对NoSQL数据库的关键观点

     在他的博文“‘NoSQL’讨论与SQL无关”（[Sto09]）中，Michael Stonebraker说近期已有大量对NoSQL数据库的讨论。在他的观点里美国的NoSQL研讨背后的驱动力是文档存储和键/值存储的

以上是关于NoSQL数据库介绍的主要内容，如果未能解决你的问题，请参考以下文章

NoSQL数据库介绍

NoSQL介绍

1.NOSQL介绍

NoSQL数据库介绍

NoSQL数据库介绍memcached安装

NoSQL介绍