在大数据处理领域，NoSQL无疑是一颗璀璨的明珠。近年来，NoSQL数据库凭借其易扩展、高性能、高可用、数据模型灵活等特色获得了大批互联网公司的青睐，百度、阿里巴巴、京东等都分别在自己的业务系统中尝试了NoSQL解决方案。随着传统的RMDBS在某些业务场景下越来越乏力，可以预见的是，越来越多的组织将会乐意尝试使用NoSQL解决方案来解决实际问题。
我认为，学习一门技术，起点很重要。如果初学者将自己的起点定位在某一种NoSQL产品上，那么学习完这种产品，得到的知识只是NoSQL技术中很小的一部分。但如果将起点定位在NoSQL的架构、模式上，那么初学者很快就会对NoSQL的全貌有个清晰的认识，这样在学习具体产品时，就会事半功倍。
——范东来
准确定义NoSQL本身就具有挑战性。NoSQL这个术语其实是有待商榷的，因为它并没有真正意义上揭示NoSQL运动的核心主题。这个术语来源于一群定期在湾区开会并讨论一些共同关注的可扩展的开源数据库的人们，它就这样出现了。不管它形不形象，它似乎出现在所有地方：行业期刊、产品说明和各种会议。在本文，我们将用NoSQL区别于传统的关系型数据库管理系统（RDBMS）。
按照我们的目标，我们将从以下几个方面定义NoSQL。
NoSQL是关于快速而高效地处理数据，专注于性能、可靠性和敏捷性的一组概念。
这听起来有些宽泛，是吧？它没有排除SQL或者RDBMS，对吗？这其实并没有错。重要的是，我们需要搞清楚NoSQL背后的核心主题：它是什么，最重要的是，它不是什么。那么NoSQL究竟是什么？
同样重要的是，NoSQL不是什么。
NoSQL应用采用很多数据存储类型（不同的数据库）。有简单的表现键值关系的键值存储、表现关联关系的图存储、用以存储可变数据的文档存储，每一种NoSQL数据存储类型都有其独特的属性和使用场景，如表1-1所示。
表1-1 NoSQsL数据存储类型——4种主要的NoSQL系统及其代表产品
NoSQL系统拥有独特的特性能够使其单独使用或者与已有系统配合使用。许多机构认为NoSQL系统这样做的原因是为了克服一些常见的问题，如数据的容量、流动的速度、数据的种类和数据的敏捷性以及NoSQL运动背后的商业驱动所使然。
哲学家、科学家Thomas Kuhn提出了“模式转变”（paradigm shift）的概念来描述在科学试验中反复出现的过程，也是这样才有很多创新的思想爆发出来，并以非线性的方式影响了世界。我们将采用Kuhn对于模式转变的定义去思考和解释当今NoSQL运动以及思维模式、架构、涌现的方法的改变。
许多使用基于单CPU的关系型系统的机构都面临着技术的十字路口：机构的需求正在发生变化。企业通过不断采集和分析海量的可变数据获得价值，并基于获得的信息对业务作出快速调整。
图1-1展示了来自于数据容量、流动速度、多样性和敏捷性的需求是如何在NoSQL解决方案的涌现中起关键作用的。正由于这些商业驱动都对单处理器的关系型模型产生压力，它的基础正变得不那么稳定，再也不能满足机构的需求。
图1-1 我们看见了诸如数据容量、处理速度、多样性和敏捷性的商业驱动是如何对单CPU系统产生压力，甚至导致崩溃。数据容量和流动速度涉及处理飞速到达的大型数据集的能力，而多样性则涉及如何将各种不同类型的数据转化为结构化的表，敏捷性则涉及系统如何快速地对业务改变进行响应
毫无疑问，迫使机构关注他们目前的RDBMS的替代品的关键因素是需要通过商用处理器集群查询海量数据。直到2005年左右，对性能的提升还停留在购买更快的处理器。但现在，提高处理器的处理速度并不是一个合适的选择。这是因为随着芯片集成度的提高，当芯片过热时，热量将不再能够及时地消散。这种现象，被称之为“功率墙”（power wall），也正是如此，迫使了系统的设计者将注意力从提高单个芯片的处理速度转移到让更多的芯片协同工作。规模向外扩展（也叫横向扩展）而不是规模向上扩展（更快的处理器）的需求，使机构将数据问题切分成独立的路径并交给独立的处理器去分而治之地工作，也就是从串行执行到并行执行。
尽管海量数据已经成为了一个使用户放弃RDBMS的原因，但是单处理器系统的快速读写能力的瓶颈亦是关键。许多基于单处理器的RDBMS已经不能满足由一些面向公众的网站所发出的实时写入和在线查询的需求。每当新加入一行，RDBMS都会频繁地对该行的许多列新建索引，这个过程会影响系统性能。当RDBMS被作为网上商店的后台，网络拥塞所引发的随机突发事件会使系统对所有人的响应变慢，而且对系统进行调优以满足必须的高速读写吞吐量的代价是非常高的。
基于 RDBMS 构建应用最复杂的部分莫过于数据读取和写入的过程。如果你的数据具有嵌套和重复子组的数据结构，你就需要一个对象关系映射层（ORM）。该层负责根据对数据库的增删改查的操作在关系型数据库持久化层对对象数据进行导出或导入。这个过程并不简单，并且当开发新应用或者修改现有的应用需要快速改变时，该层并不能很好地作出变化。
通常，对象关系映射的工作需要对对象关系映射框架（如Java的Hibernate或者.Net系统的NHibernate）非常熟悉和有经验的工程师。但就算是有经验的工程师，小小的改动也将拖慢开发速度和测试流程。
从上面可以看到，速度、容量、多样性和敏捷性是与NoSQL运动关系最紧密的驱动力。现在你已经熟悉了这些驱动力，你也可以审视一下自己的机构，看看NoSQL的解决方案是否能够对这些驱动力产生积极的影响，从而帮助业务面对当今竞争激烈的市场的需求变化。
我们的经济正在发生变革，企业想要保持竞争力就必须找到吸引并留住客户的新方法。要做到这一点，就必须得到技术和相关技术人员及时有效的支持。在这个技术前沿时代，解决方案需要运用新的思考方式，即如何实现从传统的思维方式向流程化、技术化的思维方式转变。
以下的案例研究展示了如何用打破陈规的思维方式更快、更经济、更有效地解决问题。表1-2总结了NoSQL解决方案用于解决特定业务问题的5个案例研究。表中展示了问题、业务驱动因素和最终结果。当你查看后面详细案例研究部分的内容时，你会发现这些案例都有一个共同的主题：很多业务问题需要新思路和新技术来提供最佳的解决方案。
表1-2 与NoSQL相关的关键案例研究——所选方案的案例名称/标准、业务驱动、结果（发现）
LiveJournal博客系统的工程师们正致力于研究如何运用他们最宝贵的资源——每个Web服务器中的RAM——来运行系统。LiveJournal网站存在一个问题：这个网站太受欢迎了，浏览网站的用户数量也在不断增长。要满足这种不断增长的需求就需要不断增加Web服务器，并且每个服务器都要有自己单独的RAM。
为了提高性能，LiveJournal工程师发现了一些将最常被数据库查询的数据保存在RAM中的方法，避免了在数据库中进行相同SQL查询的昂贵成本。但是查询数据的副本是保存在各自Web服务器的RAM中，所以即使是同一个机架上的服务器也不会知道旁边的服务器已经在RAM中保存了查询数据的副本。
因此，LiveJournal的工程师发明了一个简单的方法来区分每一个SQL查询，那就是为每一个SQL查询设计一个“签名”。每个签名或散列值就代表一个SQL SELECT语句。Web服务器之间只需要发送一个请求，就可以知道其他服务器中是否已经有执行的SQL结果的副本。如果其中一个服务器已有副本，它会将查询结果回传给发出请求的服务器，这样就避免了已经不堪重负的SQL数据库数据往返的昂贵成本。他们将这个新系统称作Memcache，这是因为它管理了RAM中的内存高速缓存。
许多其他软件工程师在以前也遇到过这个问题。大型的共享内存的服务器资源池这个概念其实并不新，不同的是这次LiveJournal的工程师们在这个概念上领先了一步。他们不仅让这些系统运行（并且运行良好）并通过开放资源许可共享了他们的软件，还标准化了Web前端的通信协议（被称为memcached协议）。现在，如果有人想缓解因用户反复查询而导致的数据库超负荷运行的话，前端工具是一个不错的选择。
关于NoSQL运动最有影响力的一个案例研究就是Google的MapReduce系统。在本节，Google将和我们分享如何使用廉价的商用CPU将大量的Web数据转换为内容搜索索引。
尽管它们分享的内容是标志性的，但其实映射函数和化简函数的概念并不新。映射函数和化简函数仅仅是数据转换两个阶段的名称而已，如图1-2所示。
图1-2 Map和Reduce函数可以在独立的转换系统中将大数据集划分成小块。关键是要将每个函数隔离，这样就可以将其扩展到多个服务器
转换的初始阶段被称为映射操作（map operation），它们负责数据的提取、转换和过滤。然后将结果送到下一层，即化简函数（reduce function）。化简函数将结果进行排序、整合和汇总，从而得到最终结果。
映射和化简函数背后的核心概念基于坚实的计算机科学工作，那还是在20世纪50年代，麻省理工学院的程序员通过当时比较有影响力的LISP系统实现了这些函数。与其他编程语言不同，LISP重视转化独立列表数据的函数，这是许多在分布式系统下表现出色的函数式编程语言的基础。
Google扩展了映射和化简函数使其能够处理数十亿网页并能在数以千计的低成本商用CPU上可靠运行。利用这两个函数，Google 在海量数据上实现了让映射任务和化简任务经济高效地运行。Google对MapReduce的运用使其他人对函数式编程的威力以及函数式编程系统通过数以千计的低成本CPU进行扩展的能力刮目相看。一些软件包，如Hadoop，很大程度上就是模仿这些函数。
MapReduce的应用启发了来自雅虎和其他组织的工程师们对Google的MapReduce创建了开源版本。它让我们逐渐意识到传统过程编程的局限性并鼓励我们使用函数式编程系统。
当Google发布Bigtable系统白皮书《A Distributed Storage System for Structured Data》的时候也影响了许多软件开发人员。Bigtable 背后的动力是存储用网页爬虫在互联网上收集到的HTML页面、图片、声音、视频和其他媒体的需求。这些数据太过庞大，以至于不太适合用单个关系型数据库进行存储，所以Google建立自己的存储系统。该系统建立的基本目标是可以轻易扩容以应对不断增长的数据存储需求并且不需要在硬件上投入过多。它既不是一个完整的关系型数据库也不是一个文档系统，Google称它为与结构化数据一起工作的“分布式存储系统”。
据说，Bigtable项目非常成功。它通过创建一个大表存储Google开发人员所需的数据从而为他们提供了数据的单一表格视图。此外，这个系统还允许物理硬件位于任何数据中心甚至世界上的任何角落，在这样的环境中，开发人员不需要关心自己所操控的数据所在的物理位置。
Google的工作主要关注如何使分布式的批处理和报表生成更简单，而没有考虑对高度可伸缩的Web店面每天24小时运行需求的支持。在这方面，亚马逊考虑到了。亚马逊发表了另一篇的标志性论文《Amazon's 2007 Dynamo: A Highly Available Key-Value Store》。Dynamo背后的业务驱动是亚马逊需要创建一个高可用的Web店面来支持来自世界各地每天24小时不间断的交易。
在几个不同地点经营的传统实体零售商的优势在于他们的收银机和销售设备只需要在营业时间运行，而在非营业时间可以做日常报告、备份和软件升级。亚马逊的运营模式与之不同，亚马逊的客户来自世界各地，每时每刻都有人在网站上购物。在购买周期内，任何的宕机都可能带来数百万美元的损失，所以亚马逊的系统在服务过程中需要用铁一般的可靠性和可伸缩性来确保零损失。
在Dynamo刚开始应用时，亚马逊使用关系型数据库来支持它的购物车系统和结账系统。他们拥有RDBMS软件的无限许可和充足的咨询预算，允许他们为项目雇用最好的和最精明的顾问。尽管有着充足的预算和权力，但他们最终还是意识到仅靠关系模型无法满足未来的业务需求。
NoSQL社区里面的很多人都把亚马逊的Dynamo白皮书视为NoSQL运动的重要转折点。在关系模型还广泛使用的年代，NoSQL挑战了当时的现状和当时的最佳应用。亚马逊发现，键值存储接口简单，更易于复制数据且更加可靠。最终，亚马逊用键值存储的形式构建了一个可靠的、可扩展的，并且可以支持每天24小时运行的商业模式的一站式服务系统，这使得亚马逊成为世界上最成功的网络零售商之一。
2001年，一群住在旧金山湾区附近富有文档搜索经验的工程师们成立了一家专注于处理海量XML文档的公司。由于XML文档包含标记（markup），所以他们将公司命名为MarkLogic。
MarkLogic定义了两种类型的集群节点：查询和文档节点。查询节点接收查询请求并协调与执行查询相关的所有活动。文档节点包含XML文档，并负责在本地文件系统上执行查询。
查询请求被发送到一个查询节点后，即被分发到每个包含XML文档索引的远端服务器。所有符合要求的文档会被返回至查询节点。当所有文档节点完成响应后，查询结果即被返回。
MarkLogic的架构是将查询任务移动至文档而不是将文档移动至查询服务器，这样的架构对千兆字节的文档具有线性可扩展性。
MarkLogic发现他们在美国联邦政府系统中的产品有一个需求，即TB级的智库信息以及大型出版物需要存储和搜索它们的XML文档。自2001年以来，MarkLogic已经发展成为成熟的、通用的、高度可扩展的文档存储并对ACID事务和细粒度的、基于角色的访问控制提供支持。最初，MarkLogic开发者使用的主要语言是XQuery与REST的组合，新版本支持Java和其他语言的编程接口。
MarkLogic 是一个商业产品，对于任何超过 40 GB 的数据集都需要软件许可。NoSQL 与商用产品和开源产品联系紧密，为业务问题提供了创新的解决方案。
为了展示这些概念在这本书中如何应用，我们将为您介绍Sally的解决方案。Sally在一个有许多业务部门的大型组织中担任解决方案架构师。解决方案架构师帮助存在信息管理问题的业务部门选择最好的解决方案来应对这些信息挑战。Sally致力于解决需要定制开发的应用程序项目，她对于SQL和NoSQL技术有着深入的了解。Sally的工作就是为业务问题寻求最适合的解决方案。
现在让我们通过两个案例来看看Sally是如何应用她的知识的。在第一个案例中，一个需要跟踪硬件采购的设备授权信息的团队来寻求Sally的建议。由于在RDBMS中已经保存了硬件的信息，并且这个团队在SQL方面很有经验，Sally推荐他们扩展RDBMS以包含授权信息并使用连接操作创建报表。在这种情况下，SQL就很合适了。
在第二个示例中，一个负责在关系型数据库中存储数字图片信息的团队找到 Sally。他们遇到的问题是数据库性能正对他们的Web应用页面产生负面影响。在这种情况下，Sally推荐他们将所有图片移至键值对形式的存储系统，用一个URL代表一个图片。键值存储对读密集型应用程序做了优化并能与内容分发网络相协作。当我们把图片管理负载从RDBMS迁出之后，Web应用程序以及其他应用程序的性能都得到了改善。
请注意，Sally没有将她的工作简单地按照非此即彼的方式，即不是RDBMS就是NoSQL的方式进行选择。有时最好的解决方案是兼收并蓄的。
以上内容节选自人民邮电出版社出版的《解读NoSQL》。
作者
Dan McCrearay是一个对行业标准具有强烈兴趣的数据架构咨询师。他曾经在贝尔实验室（负责集成电路设计）、超级计算行业（负责移植UNIX）以及史蒂夫•乔布斯（Steve Jobs）创办的NeXT计算机公司（软件布道师）工作，也创办了自己的咨询公司。Dan于2002年开始参与制定美国联邦数据标准，该标准也在国家信息交换模型（NIEM）中获得了启用。在2006年面对用原生XML数据库存储数据时，Dan开始了他的NoSQL开发历程。他还是万维网XForms标准制定小组的客座专家以及NoSQL Now!会议的联合创始人。
作者
Ann Kelly是Kelly McCrearay咨询公司的软件咨询师。在从事多年保险行业软件开发和管理项目之后，她于2011年开始转投NoSQL领域。从那时起，她就开始为客户构建能快速高效地解决业务问题的NoSQL解决方案，同时还提供管理应用的培训。
译者
范东来，北京航空航天大学硕士，BBD（数联铭品）大数据技术部负责人，大数据平台架构师，极客学院布道师，著有《Hadoop海量数据处理：技术详解与项目实战》。研究方向：图挖掘、模式分类。
译者
滕雨橦，清华大学苏州汽车研究院大数据处理中心高级研发工程师。常年从事基于 HBase、Redis、Cassandra等NoSQL数据库的应用开发，具有丰富的NoSQL系统架构和性能调优经验。研究方向：大数据处理、数学机械化。
