详情
本书从NoSQL的相关理论开始，深入浅出地探讨了NoSQL最核心的架构模式、解决方案和一些高级主题，内容循序渐进，从理论回归于实践。全书分4部分，第一部分介绍NoSQL的相关理论，第二部分介绍NoSQL最核心的架构模式，第三部分展现一些常用的NoSQL解决方案，最后一部分讨论NoSQL的一些高级主题。全书理论与实践并重，每章后面还有通俗的案例。
书名：解读NoSQL
ISBN：978-7-115-41110-5
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
• 著 [美] Dan McCreary Ann Kelly
译 范东来 滕雨橦
责任编辑 杨海玲
• 人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
• 读者服务热线：(010)81055410
反盗版热线：(010)81055315
Dan McCreary 和Ann Kelly领导了一家独立的培训与咨询机构，专注于NoSQL解决方案，并且他们还是NoSQL Now！会议的联合发起人。
购买本书后，读者享有由Mannning出版社运营的私有网页论坛的免费访问权。在该论坛上，读者可以评论本书、询问技术问题以及从作者和其他用户那获得帮助。如果想访问和订阅这个论坛，读者可以访问www.manning.com/MakingSenseofNoSQL。这个页面提供了如何在注册后登录论坛、可以获得哪些帮助以及论坛行为规范等信息。
Mannning出版社对读者承诺，要为读者与读者、读者与作者之间有意义的交流提供一个空间。这不是一个针对任何特定数量的作者的承诺。任何在论坛中做出过贡献的作者都是志愿且不计酬劳的。因此，我们建议读者试着询问作者一些更具挑战性的问题，以免他们对问题毫无兴趣。
只要书籍仍在印刷，这个作者在线论坛和历史讨论存档就一直可以通过出版社的网站访问。
Dan McCrearay是一个对行业标准具有强烈兴趣的数据架构咨询师。他曾经在贝尔实验室（负责集成电路设计）、超级计算行业（负责移植UNIX）以及史蒂夫•乔布斯（Steve Jobs）创办的NeXT计算机公司（软件布道师）工作，也创办了自己的咨询公司。Dan于2002年开始参与制定美国联邦数据标准，该标准也在国家信息交换模型（NIEM）中获得了启用。在2006年面对用原生XML数据库存储数据时，Dan开始了他的NoSQL开发历程。他还是万维网XForms标准制定小组的客座专家以及NoSQL Now!会议的联合创始人。
Ann Kelly是Kelly McCrearay咨询公司的软件咨询师。在从事多年保险行业软件开发和管理项目之后，她于2011年开始转投NoSQL领域。从那时起，她就开始为客户构建能快速高效地解决业务问题的NoSQL解决方案，同时还提供管理应用的培训。
这本书非常适合想要了解或者开始使用那些超越SQL数据库模型的新型数据存储和分析技术的读者阅读。这本书文字平实，并且使用了许多示例、用例和图解，阐述了NoSQL的概念、特性、优点、潜力和局限性。
读者先从将熟悉的数据库概念与准备替代或补充这些概念的新的NoSQL模式进行对比入手，然后探索关于大数据、搜索、可靠性和业务灵活性的案例（这些案例已经将新模式应用到业务问题中）。读者还将了解到NoSQL系统如何利用现代云计算和具有多路CPU的数据中心的资源。最后几章将向读者介绍如何根据自身需求选择正确的NoSQL技术。
“易于理解，对于技术经理、架构师和开发者有很高的实践价值。”
——摘自Dstaversity公司CEO Tony Shaw为本书所做的序
“剖析专业术语，给你需要知道的信息。”
——Craig Smith，Unbound DNA
“从大数据到搜索，简洁而全面地介绍了NoSQL的许多方面。”
——Join Guthrie，Pivotal
“为NoSQL带来了普遍的认知。”
——Ignacio Lopez Vellon，Atos Worldgrid
“超越其他人……现在进入NoSQL的快车道！”
——Ian Stirk，Stirk Consultancy有限公司
Original English language edition, entitled Making Sense of NoSQL by Dan McCreary and Ann Kelly published by Manning Publications Co., 209 Bruce Park Avenue, Greenwich, CT 06830. Copyright ©2014 by Manning Publications Co.
Simplified Chinese-language edition copyright ©2016 by Posts & Telecom Press. All rights reserved.
本书中文简体字版由Manning Publications Co. 授权人民邮电出版社独家出版。未经出版者书面许可，不得以任何方式复制或抄袭本书内容。
版权所有，侵权必究。
本书从NoSQL的相关理论开始，深入浅出地探讨了NoSQL最核心的架构模式、解决方案和一些高级主题，内容循序渐进，从理论回归于实践。
全书分为4个部分。第一部分介绍NoSQL的相关理论，如CAP理论、BASE理论、一致性散列算法等；第二部分介绍NoSQL最核心的架构模式——键值存储、图存储、列族存储、文档存储；第三部分展现一些常用的NoSQL解决方案，如HA、全文搜索等；第四部分讨论NoSQL的一些高级主题，如函数式编程。
全书理论与实践并重，每章后面还有通俗的案例。对于NoSQL的初学者来说，不失为一本了解NoSQL技术全貌的优秀读物。
在大数据处理领域，NoSQL无疑是一颗璀璨的明珠。近年来，NoSQL数据库凭借其易扩展、高性能、高可用、数据模型灵活等特色获得了大批互联网公司的青睐，百度、阿里巴巴、京东等都分别在自己的业务系统中尝试了NoSQL解决方案。随着传统的RMDBS在某些业务场景下越来越乏力，可以预见的是，越来越多的组织将会乐意尝试使用NoSQL解决方案来解决实际问题。
得益于工业界和学术界的高度关注和大力支持，许多NoSQL产品在短时间内大量涌现，方兴未艾，如 HBase、Cassandra、CouchDB、MongoDB、Redis、Neo4j 等。如此多的产品为架构师提供了大量的选择，但却给初学者带来一些学习的困扰。
我认为，学习一门技术，起点很重要。如果初学者将自己的起点定位在某一种NoSQL产品上，那么学习完这种产品，得到的知识只是NoSQL技术中很小的一部分。但如果将起点定位在NoSQL的架构、模式上，那么初学者很快就会对NoSQL的全貌有个清晰的认识，这样在学习具体产品时，就会事半功倍。
本书对于NoSQL的学习者来说是一本很好的读物，它能让初学者快速地领略到NoSQL技术的全貌，为后面的学习打下坚实的基础。本书的两位作者Dan McCreary和Ann Kelly是两位经验丰富的架构师，具有高屋建瓴的视角，更为难得的是，他们这本书还具有深入浅出的特点。我相信，本书作为技术人员的第一本NoSQL书籍来说是很合适的。
在本书翻译过程中，得到了BBD小伙伴们的大力支持，在此对曾途、尹康、何宏靖、刘世林、赵飞、颜如宾、王维、杨舟、陈丽竹Ju、利晓蕾、李倩、黄艳、宋开发、丁梦希、夏阳、唐婷婷、吴松珏等表示感谢。
就像本书第2章提到的CAP理论，无论是RMDBS还是NoSQL都不可能同时满足CAP理论的三个方面，要学会接受缺憾。技术如此，人生亦如此。
范东来
2015年10月于成都
范东来
北京航空航天大学硕士，BBD（数联铭品）大数据技术部负责人，大数据平台架构师，极客学院布道师，著有《Hadoop海量数据处理：技术详解与项目实战》。研究方向：图挖掘、模式分类。
滕雨橦
清华大学苏州汽车研究院大数据处理中心高级研发工程师。常年从事基于 HBase、Redis、Cassandra等NoSQL数据库的应用开发，具有丰富的NoSQL系统架构和性能调优经验。研究方向：大数据处理、数学机械化。
如果一个主题被定义为它不是什么而不是它是什么，我们该如何向别人解释它？相信我，按照一位过去3年在这个领域传道授业的人的说法，这是非常困难的，这也是许多专家、学者、技术厂商的共识。尽管很少人认为NoSQL这个名字是最好的，但似乎每个人都同意，它比其他术语更加贴切地定义了这一类产品和技术。所以我强烈建议不要由于NoSQL的定义方式，而放弃学习这些新的技术。要我来说，这些是值得你花费时间的。
接下来，是一些个人背景的简要介绍：作为一个信息管理方面的出版商，我听说过NoSQL这个词，但当时并不知道它的含义，直到3年前我在多伦多参加一次会议时，在走廊上碰到了 Dan McCreary。他告诉了我一些情况，使我了解了他目前的项目、使用的令人兴奋的技术和优秀的工作伙伴。他使我相信NoSQL技术将呈星火燎原之势蓬勃发展，像我这样的人应该尽可能地学习这方面的知识。这无疑是一个极佳的建议，于是从那时起，我们就建立了良好的伙伴关系，如共同参加学术会议、发起在线研讨会、共同撰写论文。同所有NoSQL社区的参与者一样，Dan是一位才华横溢的技术高手。
就像从事一些复杂而深奥的工作的人一样，为了使那些不具备和我同等学习热情和背景的人理解，我经常试图用简单的词汇来解释复杂的事物。但就算你理解了一次完美的电梯演讲的价值，或者拼命地想要向你的母亲解释你将要做的事情，正确的解释仍然是模糊的。有时向更有学识的人解释新事物反而更加困难。这尤其体现在NoSQL方面，由于RDBMS拥有庞大的社区和无数的拥簇者，他们只需要一个查询工具就高效而愉快地工作了30年。
这就是《解读NoSQL》出现的原因。如果你参与企业信息系统的建设并且正试着理解NoSQL的价值，那么你将会庆幸这本书的出现，因为它对你来说非常直观。诚然，新技术的使用能够使技术先驱者尝到甜头，但是对于企业IT从业人员来说，仍然存在一些令人望而生畏的障碍。其中的一个原因是由于这些年来成熟技术的沉淀和积累，周围的人会质疑你到底是为了什么想要将数据转换成一个“四不像”而不是用优美的、有序的表来进行存储。
本书的作者也意识到了这一点，并且针对你将会面对到的技术架构之间的取舍问题做了大量的研究分析。除此之外，我还欣赏他们付出了大量努力所提供的贯穿全书的案例研究。案例通常是说服的关键，当你向你的组织介绍这些新技术时，这些源自真实线上应用的案例对于你想要表达的主题来说，其价值是难以估量的。
虽然Dan McCreary和Ann Kelly给出了第一个NoSQL全面的定义和为什么在生产环境中使用NoSQL的原因，但本书并不仅仅是一本单纯的技术书籍，它背后包含了作者与架构师、开发人员一起付出的大量努力以确保不同NoSQL产品的细节和特点都在本书得到了完整呈现。
本书是一本易于理解的NoSQL指南，对于技术经理、架构师和开发人员来说有很高的参考价值。它适合需要全方位了解数据管理解决方案以应对世界上日益增长的、复杂的、海量的、快速流动的数据所带来的严峻挑战的任何人。第1章的标题是“NoSQL：明智的选择”，当你选择这本书的时候，你已经做出了一个明智的选择。
Tony Shaw
Dataversity创始人和首席执行官
有时候，现实迫使我们重新审视我们认为已经了解的事物。在花费了大量的工作时间专注于以行式数据结构存储数据的数据建模任务之后，我们发现，其实建模环节并不是非做不可的。但是这些信息并不意味着我们现有的知识体系是无效的，它迫使我们去审视应该如何解决企业的技术难题。有了新的知识、技术和解决问题方式的武装之后，我们的思路才能得以扩展。
2006年，在一个涉及房地产交易的项目中，我们花了好几个月的时间设计XML的语言模式和形式以存储层次结构复杂的数据。根据我的一个朋友 Kurt Cagle 的建议，我们发现，用原生XML 数据库对数据进行存储为我们的项目节省了数月的对象建模、设计关系型数据库以及对象关系映射时间，并最终形成一个可以由非专业人员进行维护的异常简单的架构。
对进入NoSQL领域的人来说，能意识到企业数据可以用RDBMS以外的架构进行存储是重要的转折点。最初，我们可能对这些消息持怀疑态度，会带着恐惧和自我怀疑的复杂心情来看待这些信息。我们会质疑自己的技能和为我们提供培训的教育机构以及那些强调RDBMS和对象是解决问题唯一途径的组织。但是，我们如果要公平地对待客户和用户，就必须进行一种全方位的尝试来寻找解决企业问题的最佳方案并评估其他数据库产品架构。
2010年，一直缺乏关注的NoSQL数据库技术得以在大型企业数据会议中露面，当时我们和来自 Dataversity 的 Tony Shaw 一起讨论了关于启动一个新的会议的议题。该会议旨在为所有对NoSQL技术感兴趣的人提供一个平台，供他们学习和展示如何使用NoSQL数据库技术。2011年8月第一届NoSQL Now!会议在加州圣何塞成功举行，吸引了大约500名感兴趣和好奇的参会者。
在会议上，我们发现没有任何一份资料覆盖了NoSQL架构，或者客观地介绍了一个针对业务来选择NoSQL数据库产品的流程。人们想要的不仅仅是开源项目中的“Hello World”示例，而是一本能够帮助他们根据具体业务选择技术架构并像评估商业数据库系统那样评估开源技术的指南。
找到一家能够认同我们现有技术文档的出版机构是第一步，幸运的是，我们发现Mannning出版社理解这种出版价值。
我们要感谢Manning出版社的每一个人，是你们帮助我们把最初的思想转化为一本书。Michael Stephens带领我们的工作步入正轨；Elizabeth Lexleigh是我们的开发编辑，她非常耐心地阅读每一章的每一版；Nick Chase完成了所有的技术工作；还有市场营销和生产团队以及每一个幕后工作者，我们衷心感谢你们的努力、指导和鼓励。
感谢那些回顾了案例研究和为我们提供真实NoSQL案例的人们，感谢你们宝贵的时间和专业知识：George Bina、Ben Brumfield、Dipti Borkar、Kurt Cagle、Richard Carlsson、Amy Friedman、Randolph Kahle、Shannon Kempe、Amir Halfon、John Hudzina、Martin Logan、Michaline Todd、Eric Merritt、Pete Palmer、Amar Shan、Christine Schwartz、Tony Shaw、Joe Wicentowski、Melinda Wilken和Frank Weige。
感谢那些在书稿修改过程中提出了宝贵意见和反馈的评阅者们，有了你们的参与，我们的书才会更好：Aldrich Wright、Brandon Wilhite、Craig Smith、Gabriela Jack、Ian Stirk、Ignacio Lopez Vellon、Jason Kolter、Jeff Lehn、John Guthrie、Kamesh Sampah、Michael Piscatello、Mikkel Eide Eriksen、Philipp K. Janert、Ray Lugo、Jr.、Rodrigo Abreu和Roland Civet。
在此，特别感谢我们的朋友Alex Bleasdale为我们提供NoSQL安全机制对应章中有关基于用户的访问控制的案例研究的代码。特别感谢Tony Shaw为本书撰写的序和Leo Polovets在出版前对最终书稿的技术审校。
编写本书的过程中，我们抱着两个目标：第一个目标是介绍NoSQL数据库；第二个目标则是为读者展示将NoSQL系统作为独立解决方案的方法，以及扩展当前SQL系统解决业务问题的途径。我们欢迎任何对NoSQL感兴趣的读者将本书作为参考。你会发现本书包含的信息、例子以及案例的目标受众是那些有兴趣学习NoSQL的技术经理、解决方案架构师和数据架构师。
本书将会帮助你客观地评估 SQL 和 NoSQL 数据库系统以明白它们各自解决了哪类业务问题。如果你想要的是一本关于某个产品的编程指导，那么本书可能就不是你想要的。在本书中，你将了解到NoSQL兴起背后的动机以及相关的术语和概念。对于书中有些章节介绍的内容，你可能已经了解，可以根据实际情况略看或直接跳过该部分，而把精力集中在你仍然不了解的部分。
最后，我们非常重视和关注行业标准。SQL 系统相关的行业标准允许应用在使用统一语言的情况下自由切换底层数据库。但遗憾的是，NoSQL系统还不能作出这个保证。在不久的将来，NoSQL应用提供商会敦促NoSQL数据库供应商采纳一系列标准以使其能像SQL一样具备兼容性。
本书分为4部分。第一部分由NoSQL定义和NoSQL运动背后的基本概念回顾组成。
在第1章“NoSQL：明智的选择”中，我们定义了术语NoSQL，讨论了触发NoSQL运动的关键性事件，并阐述了NoSQL系统带来的大局上的商业收益。熟悉NoSQL运动及其商业收益的读者可以选择略过本章。
在第2章“NoSQL概念”中，我们引入了NoSQL运动中的核心概念。读者在初次通读的过程中，可以选择略过本章，但这一章对于帮助理解之后的章节非常重要。我们建议将本章作为一个参考指导，在遇到相关概念时再返回本章仔细阅读相关内容。
在第二部分“数据库模式”中，我们深入回顾了SQL和NoSQL数据库的架构模式。我们探讨了不同的数据库结构、如何访问它们，并通过用例展示了每种架构最适用的场景。
第3章介绍了“基础数据架构模式”。本章以回顾关系型数据库背后的驱动力以及ERP系统需求如何塑造出现今关系型数据库和商业智能/数据仓库（BI/DW）系统开始，还简略地讨论了其他数据库系统，如对象数据库、修改控制系统。如果已经熟悉了这些系统，可以略过本章。
在第4章“NoSQL数据架构模式”中，我们介绍了NoSQL相关的数据库模式。我们探讨了键值存储、图存储、列族存储（BigTable）以及文档存储。本章将用定义、示例和案例研究等内容辅助读者理解。
第5章覆盖了“原生XML数据库”的内容。因其低廉的成本和对标准的支持，该数据库常被用于政府和出版应用。我们为读者展示了两个来自金融和政府出版领域的案例。
第三部分探讨了将NoSQL系统应用到大数据、搜索、高可用性以及敏捷网站部署等问题上的方法。
在第6章“用NoSQL管理大数据”中，你将了解到配置NoSQL系统在商用硬件上高效处理大体量数据的方法。我们还有一个关于分布式计算和横向可扩展性的讨论。同时，我们还为读者展示了一个不能通过商用硬件扩展完成巨型图分析的案例。
在第7章“用NoSQL搜索获取信息”中，你将学习到如何通过实现文档模型和保留文档内容的方式提升搜索质量。我们讨论了采用MapReduce转化技术创建倒排索引并最终获得快速搜索性能的方法，还回顾了用于文档和数据库的搜索系统，并展示了采用结构化搜索解决方案获得准确的搜索结果排序的方法。
第8章的内容覆盖了“用NoSQL构建高可用的解决方案”。我们阐述了如何使用NoSQL系统自带的复制和分布式特性提升系统可用性。你将了解到在采用了数据同步技术的情况下，如何使用大量低廉CPU来提供更长的在线时间。我们的案例研究揭示了纯点对点架构能比其他分布式模型提供更高可用性的原因。
在第9章中，我们讨论了“用NoSQL提升敏捷性”。因为移除了对象关系映射层，NoSQL软件开发变得更简单且能快速适应业务需求的变更。你将了解到这些NoSQL系统是如何将富有经验的开发人员和非编程人员整合到软件开发生命周期过程中的。
在第四部分中，我们先介绍了函数式编程、安全等“高级主题”，然后，回顾了一个正式的NoSQL系统选型过程。
在第10章中，我们介绍了关于“NoSQL与函数式编程”和类似MapReduce的分布式转化架构的要求这两方面内容。我们探讨了函数式编程对NoSQL解决方案能使用大量低廉CPU能力的影响，以及许多NoSQL数据库系统采用类似Erlang的基于角色的框架的原因。我们还通过NetKernel系统的案例介绍了结合函数式编程和面向资源编程构建性能可扩展的分布式系统的方法。
第11章覆盖了“安全：保护NoSQL系统中的数据”相关的内容。我们回顾了NoSQL解决方案中安全性方面的历史以及关键的安全性问题。我们还通过例子为读者展示了键值存储、列族存储和文档存储实现一个健壮的安全模型的能力。
在第12章“选择合适的NoSQL解决方案”中，我们遍历了企业为业务问题选型合适数据库的正式流程。最后，我们将以一些关于这些技术会如何影响业务系统选型的想法和信息结束本章。
清单和文本中的源代码会以等宽字体出现，以便和普通文本区分开。你可以从Mannning出版社的网站（www.manning.com/MakingSenseofNoSQL）上下载清单中的源代码。
在第一部分中，我们将介绍NoSQL。我们将定义什么是NoSQL，讨论为什么NoSQL运动开始流行，了解NoSQL的核心主题，讨论基于NoSQL的解决方案能给企业带来什么样的好处。
第1章从定义NoSQL开始，然后谈到NoSQL流行背后的商业驱动和动机。第2章会在第1章的基础上进行扩展，并对NoSQL相关的核心概念进行探讨。
如果你对NoSQL运动已经足够熟悉，你可能会希望略过第1章和第2章中介绍NoSQL相关概念的部分，但是我们仍然鼓励所有人都阅读第2章中的相关概念，因为这些概念将从始至终贯穿全书。
本章主要内容
最小部件所耗费的复杂度约每两年增长一倍。当然，如果这个增长速度不再增长的话，短期内这样的增长速度仍然会继续。
——Gordon Moore（戈登·摩尔，Intel创始人之一），1965
……你最好开始游泳，否则你将沉入水底……因为时代在变革。
——Bob Dylan
我们编写本书有两个初衷：第一，介绍NoSQL数据库；第二，展示如何使用NoSQL系统作为独立的解决方案或对现有SQL系统进行补充以解决实际业务问题。尽管我们希望所有对NoSQL感兴趣的人都能够将本书作为指南，但是本书中的内容、样例、案例研究面向的是希望学习NoSQL的技术经理、解决方案架构师和数据架构师。
本书将帮你评估SQL数据库系统和NoSQL数据库系统能够胜任的业务场景。如果你在寻找一本详细的、具体的编程指南，那么本书不适合你。在这里你会发现NoSQL背后的发展动机、相关技术和概念。或许你已经理解本书某些章节所提到的主题，那么可以略过它们并专注于那些新的知识。
最后，我们对标准表示强烈的关注。SQL系统的相关标准使得应用可以使用一种通用的语言在不同的数据库产品之间进行迁移。遗憾的是，NoSQL系统目前并没有相关的标准。在将来，NoSQL应用的开发者将会向NoSQL数据库厂商施压，迫使它们采用一系列标准，以使NoSQL应用的移植性能够媲美SQL。
在本章，我们将给出NoSQL的定义并探讨使NoSQL产品如此有趣并在业界流行的原因。最后，我们将看到5个通过实施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的Memcache技术 |
需要提高数据库查询性能 |
通过使用散列和高速缓存来共享RAM中的数据，这减少了发送到数据库的读取请求并提高了性能 |
| Google的MapReduce |
需要基于低成本的硬件为搜索服务生成数十亿的网页索引 |
通过使用并行处理，数十亿的网页索引可以通过大量的商用处理器迅速完成 |
| Google的BigTable |
需要在分布式系统中灵活地存储表格数据 |
通过使用这种稀疏矩阵模式，用户可以认为不需要提前定义数据模型，数据是存储在一个由数十亿行、数百万列组成的表格中 |
| 亚马逊的Dynamo |
需要每天24小时不间断地接收网络订单 |
键值存储，有着简单的查询接口，即使是海量数据也能完成复制操作 |
| MarkLogic |
需要用标准的查询语言来查询存储在商用硬盘中的大量的XML文档 |
通过将包含XML文档索引的查询分发至商用服务器，每个服务器通过在本地磁盘处理数据，并将结果返回至查询服务器的方式进行响应 |
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 的概念，回顾了 NoSQL 运动背后的核心业务驱动力。然后展示了性能瓶颈如何迫使系统设计师使用高度并行处理设计，用创新的思维来管理数据。你也可以了解到，使用对象-中间层和RDBMS数据库的传统系统需要使用复杂的对象-关系映射系统来操作数据。这些层通常会阻碍组织对变化作出快速反应的能力（敏捷性）。
任何一项新的技术都是有风险的，至关重要的是要理解每个领域都有自己解决问题的模式，这些模式所使用的技术是明显不同的。从SQL过渡到NoSQL也不例外。NoSQL是一种新的范型，需要一系列新的模式识别的能力、新的思维方式和新的解决方案。也就是说它需要我们具备一种新的认知风格。
选择使用NoSQL技术可以帮助企业在他们所处的市场中获得竞争优势，使他们更敏捷、更好地适应不断变化的商业环境。NoSQL可以利用大量的商用处理器为公司节省时间和金钱，并提高服务的可靠性。
正如在案例研究中看到的，这些变化带来的影响比早期的技术用户带来的影响还要大：使世界各地的工程师认识到RDBMS并不是我们唯一的选择，它是可以被替代的。新的公司专注于新思维、新技术以及新架构的涌现不是由于一时兴起，而是缘于解决那些不适用于关系模型的真实业务问题的必要性。随着企业持续变化和进入经济全球化时代，这一趋势将继续扩大。
在下一章中，我们将开始讨论关于NoSQL的核心理念和技术。我们将讨论其简洁的设计，同时会构建一个模块化、可扩展以及低成本的NoSQL系统的基础。
本章主要内容
少即是多。
——Ludwig Mies van der Rohe
在本章，我们将介绍一些NoSQL系统的核心概念。阅读完本章之后，你将有能力识别和定义NoSQL的概念和术语，了解NoSQL厂商的产品及其特性并且能够决定这些特性是否适合你的NoSQL系统。接下来，我们将讨论如何在应用开发过程中利用简单的组件来降低复杂性和促进重用，从而使你在系统设计和维护时节约时间、降低开销。
如果你和关系型数据库打交道，那么你应该知道它们是多么复杂。一开始，它们是一个简单的系统，当被请求时，从单一的平面文件返回一个被选择的行即可。随着时间的迁移，它们需要管理不止一张表、执行连接操作、对查询进行优化、复制事务、运行存储过程、设置触发器、保证安全性、维护索引等。对于这些复杂的问题，NoSQL系统另辟蹊径，通过在网络中构建简单的分布式应用来满足不同维度的需求。保持架构级别的组件简单使得在不同的应用中可以重用这些组件，帮助开发人员理解和测试，而且应用的架构迁移也变得更容易。
NoSQL的观点认为，简单就是好的。构建一个应用时，并不需要在一个软件中包含所有的功能，应用的功能可以被分发到多个NoSQL（或者SQL）数据库上完成，这些系统由许多简单工具组成并具有简单的接口和清晰定义的功能。NoSQL产品遵循的原则是做好几件事。为了说明这一点，我们来看看系统是如何通过清晰定义的功能构建而成，并关注基于这些功能组合成新的功能是多么地容易。
如果你对UNIX操作系统熟悉的话，你应该对UNIX管道的概念不陌生。UNIX管道是一组相互连接的进程，前一个进程的输出正好是下一个进程的输入。与 UNIX 管道类似，NoSQL 系统由许多协同工作的功能模块构成。如图2-1所示，这是一个由一些小功能通过UNIX管道连接用来统计书中出现figure单词的次数。
图2-1 UNIX管道是个复用一些简单功能以实现新功能的例证。该图显示将一个目录中的所有章节文件连接起来并对所有章节的图片数量进行统计。通过使用UNIX管道，我们可以将3个简单的命令拼接成一个字符串：连接（cat）、搜索函数（grep）和单词计数（wc）。没有多余的代码，每一个函数接受前一个函数的输出并进行处理
这个例子的显著特点是通过键入 40 来个字符你就可以创建一个有用的函数。如果是在不支持UNIX风格函数的系统中，情况就困难得多。事实上，在原生XML数据库上执行的查询可能还会比这条命令更短，但这并不是通用的。
许多NoSQL系统都遵循利用协同工作的模块化组件这一思想。为了取代单一的大型数据库层，它们经常采用通过重新组合许多更加简单的模块的方法来满足不同应用的需求。例如，某一个功能允许通过内存（或者是memcache）共享对象，另一个功能负责运行批处理作业（如MapReduce作业），还有一个功能负责存储二进制文档（以键值对的方式存储）。我们注意到大多数UNIX管道的设计宗旨是在单一的处理器之上通过拼接线性的管道来达到传输面向行的数据流。而NoSQL的组件，尽管模块化，却不仅仅是一系列的线性管道组件。它们专注于那些常用于增强分布式Web服务的高效的数据服务。NoSQL系统可以是文档、消息、消息存储、文件存储或者是通过通用的API提供基于REST、JSON或XML的Web服务，它们还提供装载、验证、转换和输出海量数据的工具，而UNIX管道实际上是被设计成只能在单处理器之上工作。
标准观察：用来处理结构化数据的通用管道
你这时候可能会问是否还能用UNIX管道背后的思想来处理结构化数据。如果你使用的是JSON或者是XML的标准，那么答案是肯定的。并且W3C已经意识到管道的思想可以用来处理任意非结构化的数据以满足通用的需求，他们提供了管道式处理数据的标准：XProc。一些NoSQL数据库已经内建并实现了XProc作为它们架构的一部分。XProc标准允许一个NoSQL内建的数据转换管道不经任何修改就可以连接到其他XProc系统。可以通过http://www.w3.org/TR/xproc/找到更多有关XProc的信息。另外还有一个XML语法风格的UNIX脚本工具：XMLSH。可以通过http://www.xmlsh.org找到更多有关XMLSH的信息。
关于NoSQL系统的简单功能的概念将是反复出现的主题。哪怕是NoSQL系统不能在单一系统中满足所有的需求，也要敢于建议使用或者真正去使用NoSQL系统。可以把它们看作是工具的集合，如果对它们的组合使用方法了解越多，它们会变得越有用。接下来，我们将来看到这个简单的概念对于基于NoSQL的应用层的开发的重要性。
了解分层应用在整体架构上的作用对于客观地评估一个或者多个应用架构来说是很重要的。当功能分布到每一层时，你可能无法立即做到管中窥全豹。如果想客观公正地比较系统之间的差异，最好的方法是进行整体分析，看看所有架构层次的应用是如何满足系统需求的。
在架构中采用应用分层的思想可以构建弹性的、可重用的应用。采用应用分层的思想，当必须做出一些改动时，可以选择新增或者修改某一个特定的层次，而不是重写它。在接下来的例子中，通过比较关系型数据库系统和NoSQL系统，可以发现NoSQL应用的功能分布是不同的。
当应用设计者开始考虑存储持久化数据的软件系统时，他们有很多选择。其中一个就是决定是否需要将整个应用的功能通过应用层进行划分。确定每一个应用层将应用分拆为架构独立的组件，有助于软件设计者决定每一个组件需要承担的功能。这种分离的特性有助于设计者向其他人解释系统时将复杂问题简单化。
如图2-2所示，应用层通常被描绘为分层蛋糕的样子。图中，用户事件（如用户点击网页上的按钮）在用户接口层触发代码运行。用户接口层的输出或响应将被发送至中间层。中间层可能会通过发送信息返回至用户接口层的方式进行响应，也可能访问数据库层。数据库层会运行查询并将查询结果返回至中间层。接着中间层将会利用收到的信息产生报表并将报表发送至用户。无论是使用微软的Windows、苹果的OS X，或者是点击Web浏览器的HTML链接，这一过程是相同的。
图2-2 应用层通常用来简化系统设计。NoSQL运动主要关注在最小化整个系统的性能瓶颈，这意味着有时需要将某些关键组件移出所在的应用层并将其移动至另一个应用层
在设计应用时，很重要的一点是对将功能分层的利弊进行权衡。因为关系型数据库已经存在了很长一段时间，也非常成熟，数据库厂商通常会在数据库层上增加功能并和它们自己的软件一起发布，而不是复用已经开发或者交付的组件。而NoSQL系统的设计者知道他们的软件必须能与其他应用一起在复杂的环境中工作，重用和无缝的接口是必需的，所以他们倾向于构建小巧独立的功能，图2-3展示了RDBMS和NoSQL应用的差异。
图2-3 RDBMS和NoSQL系统的应用层次结构对比。左边的RDBMS为了保证安全性和事务完整性，把许多功能放置在数据库层，中间层用来将对象转换为表中的数据。右边的NoSQL系统并不使用对象-关系映射的概念；它们将一些数据库的功能移动到中间层，并利用了一些额外的服务
在图2-3中，我们比较了关系型数据库和NoSQL将应用的功能分布至中间层和数据库层的方法。正如你看到的，无论选取哪种方法，都需要系统架构顶端的用户接口层。在关系型数据库中，大多数应用的功能都能在数据库层找到。而在NoSQL应用中，大多数应用的功能都集中在中间层。此外，NoSQL系统还利用了更多的服务来管理二进制大对象数据（键值存储）、排序全文索引（Lucene索引），以及执行批处理作业（MapReduce）。
一个好的NoSQL应用设计在考虑将功能放置在数据库层还是中间层时，一定是仔细地分析了两种方案的优势和劣势。NoSQL解决方案允许你仔细考虑所有选项，并且如果需求包括了高扩展性组件，可以选择保持数据库层的简单性。在传统的关系型数据库系统中，数据库层的复杂性影响了应用的整体扩展性。
记住，如你只专注于某一个单独的层次，你将不会得到一个客观的比较。当在RDBMS与NoSQL系统之间进行权衡分析时，同样需要考虑数据的重分区对各个层次功能的影响程度。这个过程比较复杂并且需要熟悉RDBMS和NoSQL的架构。下面列举一些优势和劣势供做权衡分析时参考。
RDBMS的优势如下。
RDBMS的劣势如下。
NoSQL的优势如下。
NoSQL的劣势如下。
理解应用层中存在的功能的作用对理解应用如何执行是很重要的。另一个需要考虑的重要因素是存储，如RAM、SSD和磁盘会如何影响你的系统。
数据库集群技术
NoSQL业界经常提到由处理节点组成的数据库集群。一般来说，一个集群都是由一些放置在机架上的商用计算机硬件组成，如图2-4所示。
图2-4 一些应用于分布式数据库集群中的术语。集群是由一系列被称作节点的处理单元构成，分机架组织在一起。节点都是商用处理计算机，每一台都有自己的CPU、RAM和磁盘 每一个独立的计算机称为一个节点
本书的初衷，除非我们讨论的是定制的硬件，否则我们都将节点定义为包含一个被称为CPU的逻辑处理器的处理单元。每个节点都有自己的本地RAM和磁盘。CPU某种程度上来说是由各种各样的芯片组成，每一个CPU都包含了多个内核处理器。磁盘系统也由多个独立的驱动器组成。
节点分机架组织在一起，一个机架内的节点具有很高的连接带宽。数据中心内的多个机架组合在一起形成一个数据库集群。一个数据中心可能包含多个数据库集群。正因为如此，我们注意到一些NoSQL事务必须在两个不同地理位置的节点存储相关的数据才会被认为成功。
NoSQL系统如何通过不同类型的存储介质来提升系统性能？通常，传统的数据库管理系统不会关注存储管理方面的选项。与之不同，NoSQL系统被设计成使用最少的昂贵的资源提供快速的用户响应。
如果你对数据库架构不熟悉，那么分清查询从RAM（易失的随机读取记忆体）取得的数据和从磁盘驱动器取得的数据之间存在的性能差异，无疑是一个良好的开始。大多数人都知道，当他们关闭了工作了漫长一天的电脑，在RAM中的数据都会消失并且在下次使用时需要重新加载。而保存在固态硬盘（SSD）和机械硬盘（HDD）中的数据将会一直存在。我们还知道RAM的读取速度大大超过硬盘的读取速度。假设1纳秒近似等于0.3米，这是由于光通过0.3米所消耗的时间实际上近似等于1纳秒。那意味着，RAM距离你是3米，而磁盘驱动器与你的距离达到3000米，即3千米。如果采用固态硬盘，访问速度还是会低于RAM，但是已经明显超过了机械硬盘（如图2-5所示）。
图2-5 为了得到访问硬盘获取数据和访问RAM缓存获取数据之间的存在显著差异的感性认识，先想想从你家后院取一样东西（RAM）的时间。再想想驱车去你的邻居处拿取（SSD）的时间，最后再想想如果你在芝加哥要去洛杉矶拿取（HDD）的时间。该图显示了从本地缓存返回查询结果的效率大大优于需要读取HDD的开销高的查询
让我们来到伊利诺伊州的芝加哥。如果你想要从RAM获取某些东西，通常就好像你在你家后院找东西；如果你正好把东西存储在固态硬盘中，就好像顺路去某个地方拜访一下你的邻居；但是如果你想从硬盘驱动器中获取某些东西，就好像需要去离这3000米的加州洛杉矶市。如果可以避免，你一定不想经常来一次这样的往返旅行。
与其想尽各种办法往返洛杉矶，不如在邻居家先看看他们是否已经有你需要的数据了。如今在芯片中完成一次计算所耗费的时间就好像光穿过芯片那样短暂。当等待你所需要的数据从洛杉矶返回时，你完全可以完成上万亿次的计算。这就是为什么计算散列值比访问磁盘快得多，你拥有越多的RAM，那么你需要进行长途往返旅行的可能性也就越低。
搭建响应更加快速的系统的关键在于将所需要的信息尽可能多地保存在RAM中，并且检查本地服务器是否保存有副本。这种本地的快速数据存储经常被称作RAM缓存或者是内存缓存。但是，搭建一个这样的系统并决定某些数据是否需要存储在缓存中是一个难题。
许多内存缓存对缓存中的每一块内存都采用简单的时间戳进行标记，以此作为保存最近使用的对象的依据。当内存被占满，时间戳经常被用于判断内存中最老的对象并将其覆盖。一个更精确的视图能够计算出重新生成数据集并将其保存至内存所耗费的时间或者资源。这个“成本模型”使得代价更高的查询结果保存在RAM中的时间长于那些能够快速生成出来的简单条目。
有效利用RAM缓存的关键在于对下面的问题作出有效的判断，“我们以前运行过这个查询作业吗？”或者类似地，“我们以前见过这个文档吗？”一致性散列算法（consistent hashing）可以解答这个问题散列，它能让你知道一个对象是已经被保存至缓存，还是需要从SSD、HDD中重新获取。
我们已经知道了将经常使用的数据保存在RAM缓存中的重要性，以及如何通过减少非必要的磁盘访问来提升数据库性能。NoSQL系统将基于这个概念进行深入探讨，并采用了一致性散列（consistent hashing）的算法使访问最频繁的数据保存在缓存中。
在评估NoSQL系统如何工作时，一致性散列算法是一种有效的通用流程。一致性散列算法能很快判断出一个新的查询或者文档是否和缓存中的某一个对象是相同的。了解这些将有助于减少不必要的磁盘访问并且使数据库保持高速运行的状态。
生成散列字符串（也称作校验和或者散列），是通过检查文档中的每一个字节并计算出一个字母序列的过程。散列字符串对于每个文档来说都是独一无二的标识，可以用来判断当前的文档和已有的文档是否一致。如果两个文档存在差异（即使是一个字节），那么散列的结果也会不同。从20世纪90年代开始，散列字符串就可以通过一些标准化的算法生成，如MD5、SHA-1、SHA-256和RIPEMD-160。图2-6展示了一个典型的散列处理过程。
图2-6 散列过程示例。一个文档（如商业发票）被作为一个散列函数的输入。散列函数处理的结果是一个字符串，这个字符串对原始的文档来说是独一无二的，哪怕是一个字节的改动都会导致散列函数处理的结果不同。散列可以被用来检测文件是否被修改或者对象是否已经存储在RAM缓存中
简单的查询或者是复杂的JSON和XML文档都可以生成散列值。一旦拥有了散列值，就可以用它来确保每次发送给其他人的信息是一致的。一致性散列使得网络中运行在不同节点上的两个不同的进程对于同一个对象能够生成同样的散列值。一致性散列确认了文档中信息没有被改动并且可以用于决定某个对象是否应该留在缓存或消息存储中，通过只在必要时才重新运行进程来节省宝贵的资源。
一致性散列也是同步分布式数据库的关键。例如，Git、Subversion之类的修改控制系统不仅对目录中的单个文档求散列值，还会对目录中的所有文件进行散列校验。通过持续地对所有文件进行校验，可以发现本地目录与远程的目录是否同步，如果不同步，可以只对那些改变的项目执行更新操作。
一致性散列是维护当前缓存和系统高速运行的重要工具，即使缓存被分散到许多分布式系统中，一致性散列也可以对其进行维护。一致性散列也被用来将文档分派到分布式系统的数据库节点，并在需要同步时能快速地比较远程数据库。分布式的NoSQL系统依靠散列显著地提升了数据库的读能力，并且没有妨碍到写事务。
散列冲突
两个不同的文档仍然存在极小的机会可能生成同样的散列值，这将会导致散列冲突（hash collision）。发生冲突的可能性取决于散列值的长度和需要存储的文档数。散列值越长，发生冲突的可能性就越低。如果增加文档数，发生冲突的可能性会增大。许多系统采用MD5散列算法生成128位的散列字符串。一个128位的散列可以生成大约1038种可能的输出。那就意味着，如果想将冲突的可能性保持在一个比较低的水平，如1018分之一以下，那么需要将维护的文档数降低到1013以下，或者限制在105亿文档左右。
对于大多数使用散列的应用，偶然的散列冲突并不是我们关注的焦点。但有些需要避免散列冲突的情况是我们关注的重点。那些使用散列作为安全验证的系统，如政府或者高度安全系统，需要超过128位的散列值。在这些情况中，更倾向于使用一些能生成超过128位散列值的算法，如SHA-1、SHA-256、SHA-384或者SHA-512。
兼顾性能和一致性的事务控制在分布式计算环境下是很重要的。通常会在两种事务控制模型中选择其一使用：ACID用于RDBMS，BASE用在很多NoSQL系统。即使数据库事务只有很少一部分需要事务完整性，但了解RDBMS和NoSQL系统能够采用这些事务控制策略也是很重要的。这两种模型的区别在于应用开发人员所付出的努力和事务控制所发生的位置（层级）。
让我们从一个简单的银行业务案例来展现一个可靠的事务。如今，许多人都有两个银行账户：储蓄账户和支票账户。如果你想将一些资金从一个账户转账到另一个账户，银行在网站上会有转账页面，进行如图2-7所示的一个资金转账流程。
图2-7 这一系列原子步骤将资金从一个账户转账到另一个账户。第一步从储蓄账户扣除所要转账的金额。第二步将相等的转账金额增加到支票账户。由于事务应该是可靠的，所以所有步骤要么都执行要么都不执行。在事务步骤之间，任何显示账户总额由于交易金额而减少的报表都不应该被允许运行
当点击了网页上的转账按钮，两个独立的操作必须共同执行。首先从储蓄账户中扣除转账金额，然后再加到支票账户中。事务管理是确保这两个操作作为一个整体一起发生或者一起不发生的过程。如果计算机在第一个步骤完成后而第二个步骤还没开始时崩溃了，你要损失1 000美元，你当然会对银行产生极大不满。
传统的商业数据库都以在金融事务方面的稳定和可靠而闻名。这不仅因为它们已经存在了相当长的时间，且一直不断地进行着优化，还因为它使得程序员通过在事务开始和结束的地方进行声明就可以很容易地保障关键事务的可靠性。这些声明被称作启动事务（OPEN TRANSACTION）和结束事务（END TRANSACTION）。通过添加它们，开发者能够获得高可靠的事务支持。如果两个原子操作中的一个没有完成，那么所有操作都会被回滚至它们最初的状态。
系统同样确保了不会有任何账户报表在操作进行到一半时生成。如果你在事务过程中执行生成账户余额报表，它将不会显示先有1 000数额的减少然后再增加1 000。如果报表在事务的第一个步骤进行时开始生成，它将会被阻塞，直到整个事务完成。
在传统的RDBMS中，事务管理的复杂性由数据库层负责解决。应用开发者只需要处理在整个事务失败时，如何通知正确的组件或者不停重试直到事务完成。应用开发者并不需要知道如何撤销一个事务的各种部分，因为这已经成为了数据库内建的一部分。
由于可靠的事务对于大多数应用系统是很重要的，接下来的两小节将深入研究RDBMS的事务控制——ACID和NoSQL系统的事务控制——BASE。
RDBMS的事务控制通过原子性、一致性、隔离性和持久性（ACID）属性来保证事务是可靠的。接下来将对每一个属性进行定义。
如果你认为处理这些规则的软件一定很复杂，那么你是正确的。确实非常复杂，这也是关系型数据库非常昂贵的原因之一。如果你自己正在编写一个数据库，那么有些必需的软件模块的数量很容易增至2倍或是3倍。这也是新数据库产品经常在第一个发布版中不支持数据库级别的事务管理的原因，而是在产品成熟后才会加入。
许多RDBMS将事务发生的范围限制在单个CPU之内。如果考虑这种情况：你的储蓄账户的信息存储在纽约的一台计算机里，你的支票账户信息存储在旧金山的一台计算机里，那么复杂程度将会增加，因为这种情况有更多的失效点并且需要阻塞的基于这两个系统的报表系统的数量也会增加。
尽管支持ACID的事务很复杂，但还是有一些著名的、公认的策略来实现。它们都是基于锁定资源，并预留出额外副本的资源，然后执行事务，如果一切都没问题，再释放资源。如果事务的任何一部分出错，有争议的资源必须回到它的初始状态。设计上的挑战在于搭建支持这些事务的系统，使得应用可以个更容易地使用事务并且保证数据库的运行速度和响应能力。
ACID系统关注数据的一致性和完整性，且高于其他考量。暂时阻塞报表的机制是为了确保系统返回可靠准确的信息的一种合理的妥协。ACID系统可以说是悲观的，因为它们必须考虑计算环境里所有可能的失效模式。有时ACID系统似乎服从墨菲定律——会出错的事总会出错——并且必须仔细测试保证事务完整性。
ACID系统高度关注数据完整性，NoSQL却是基于BASE准则考虑一系列稍有不同的约束。如果在等待另一个事务完成前阻塞事务对你来说是不可接受的妥协，会怎么样？如果你有一个接受客户订单的网站，有时ACID系统不一定是你想要的。
假如你的网站是运行在遍布世界各地的计算机上，会怎样？芝加哥的计算机负责管理库存，而负责保存产品照片的图像数据库在弗吉尼亚，计算税收的程序在西雅图运行，账户系统在亚特兰大。如果一旦其中一个站点宕机会怎么样？你是否应该告诉客户等你在20分钟内解决问题后再回来？除非你是想将客户拱手相让给竞争对手。使用ACID系统处理到达的每一个订单现实吗？让我们看看另一种选择。
使用“购物车”和“结账台”概念的网站对于事务处理有不同的侧重。在几分钟内报表不一致与无法下订单相比是不那么重要的，因为如果阻塞一个订单，就损失了一个客户。这种情况下，可以使用BASE来替代ACID。下面是BASE的一些概念。
与RDBMS关注一致性不同，BASE系统关注可用性。BASE系统显著的特点是它们的首要目标是要保证在短时间内，即使有不同步的风险，也要允许新数据能够被存储。NoSQL系统放宽了规则并允许即使不是所有数据库都是同步的，也能运行报表。BASE系统不被认为是悲观的，因为它们并不会关心某个过程背后的细节。它们是乐观的，因为它们假设最后所有系统都会同步而变得一致。
BASE系统倾向于更加简单和迅速，因为它们不必编写处理锁定和释放资源的代码。它们的任务是保证流程运转并稍后处理出错的部分。BASE系统非常适合支持网上商店，填满购物车和下订单才是它们的主要优先功能。
在NoSQL运动之前，大多数数据库专家认为ACID系统是唯一能够商用的事务类型。NoSQL系统是高度去中心化的，并且ACID提供的保障有时不是必须的，所以NoSQL采用了BASE和一些更为宽松的方法。图2-8显示了一个准确的、有点幽默的ACID和BASE哲学之间的对比。
图2-8 ACID与BASE——了解其中的利弊。该图比较了应用于严格的金融账户规则的传统RDBMS的ACID事务与NoSQL系统更加宽松的BASE方法。当要求所有报表必须始终保持一致性和可信性，RDBMS ACID系统是理想的选择。当把永远不阻塞写事务作为高优先级任务时，NoSQLBASE系统是合适的选择。业务需求将决定是传统的RDBMS还是NoSQL系统适合你的应用
最后还要提醒读者：ACID和BASE并没有一个严格界限，它们取决与组织和系统决定在哪里和如何架构这个系统的场景。它们可能允许在某些关键领域采取严格的ACID事务，其他领域标准稍微放松一些。一些数据库系统通过改变配置文件或者使用不同的API提供了双重选择。系统管理员和应用开发者可以一起在考虑了业务的需要之后，实现正确的选项。
当你为了处理海量数据而进行扩展并将系统架构从集中式迁移到分布式系统时，事务是重要的。但是有时你管理的数据超过了当前系统能够管理的规模，那就需要采取数据库分片来保证新系统运行并减少宕机时间。
随着一个组织存储的数据量增加，可能在某个时候，业务运行所需的数据量超过了当前环境所能运行的最大值，这时候，一些将数据分成合理的数据块的机制是必要的。组织和系统可以将数据库自动分片（将一个数据库划分为一些块，这些块称作数据库分片，它们遍布在一些分布式服务器上）作为持续存储数据并且最小化宕机时间的手段。在稍早的系统上手动配置数据库并将数据从旧系统复制到新系统时，这个操作可能会耗费系统数小时，然而NoSQL系统会自动进行这个操作。数据库的成长性和自动分区数据的容错性对于NoSQL系统来说很重要。对于大数据系统和容错系统，分片操作已经成为高度自动化的过程。接下来让我们来看看分片如何工作以及它面临的挑战。
假设你创建了一个网站，它允许用户登录和创建自己的私人空间并与朋友们分享。他们会上传文件、发送信息并发表一些他们对喜欢的（或不喜欢的）事物的看法。你搭建起网站，将这些信息保存到运行在单个CPU之上的MySQL数据库中。人们如果喜欢它，就会登录网站，创建主页，邀请朋友，不知不觉间你的磁盘空间已经所剩无几。接下来该怎么办？如果你使用的是典型的RDBMS，那么答案是购买新的系统并将一半用户迁移到新系统中。哎，你以前的系统可能需要宕机一段时间，这样你才能重写应用让它知道从哪个数据库中得到所需的信息。图2-9显示了一个数据分片的典型示例。
图2-9 当单个处理器不能很好地胜任系统的吞吐量需求时，就需要执行分片操作。当发生分片时，你会希望数据被移动到两个系统中，而每个系统负责原来一半的工作。许多NoSQL系统内建了自动分片功能，你只需将一台服务器添加至工作节点资源池里，数据库管理系统会自动将数据移动至新节点。大多数RDBMS不支持自动分片
有多种方式可以完成从单个数据库迁移至多个数据库的过程。
（1）可以将用户名以A～N开头的用户保留在原有的系统中，而将用户名以O～Z开头的用户迁移至新系统。
（2）可以将美国用户保留在原有系统中，而将欧洲用户迁移至新系统。
（3）可以随机将一半用户迁移至新系统中。
每一种方式都有其优势和劣势。例如，第一种方案，如果某个用户修改了用户名，那么是否应该将它自动迁移到新系统？第二种方案，如果某个用户搬家到一个新的国家，那么他的数据是否也该被迁移？如果用户都喜欢与周围的人分享链接，那么将这些用户放在同一系统中是否有性能上优势？如果美国的用户都习惯在晚上同一时间活跃又会怎么样？其中一个数据库会承受巨大压力而另一个空闲吗？如果你的网站规模再次翻倍又会如何？你会每次硬着头皮不断地重写代码来应付吗？你会让你的系统宕机一周等你升级软件吗？
随着服务器数量的增长，你会发现每一台服务器宕机的概率是均等的，所以每当你增加一台服务器，那么某一部分不工作的概率会增加。你或许会认为你将数据库切分到两个系统的过程也可以用来复制数据到备份系统或者镜像系统以防系统故障，但是这会带来新的问题。如果主节点被修改了，那么必须保证备份数据同步更新，这就需要有一个数据复制方案。同步这些数据库耗费时间的同时也会降低系统性能。现在你需要维护更多服务器了！
欢迎来到数据库分片、复制和分布式计算的世界。可以看到当数据库不断成长，你需要考虑和权衡许多问题。NoSQL系统已经有很多方法允许用户在扩大数据库规模的同时不用关闭服务器。当存储节点或网络出现故障时仍维持数据库运行叫作被称为分区容错性——一个在NoSQL社区出现的而传统数据库管理者努力追求的新概念。
理解事务完整性和自动分片对于考虑搭建分布式系统时面临的权衡问题是很重要的。尽管数据库性能、事务完整性以及如何利用内存和自动分片特性很重要，但有些时候，你必须确认并专注于系统最重要的方面，而使其他方面变得灵活。在下一节中，我们将通过一个标准的流程来了解在选择过程中需要做出的权衡，这样有助你专注于对组织最重要的事物。
为了能在系统故障时做出最好的决策，你需要考虑基于不可靠的网络的分布式系统的一致性和可用性属性。
Eric Brewer在2000年首次提出CAP定理。CAP定理表明了任何分布式数据库系统最多只能满足以下3个期望属性中的2个。
记住，CAP定理只适用于集群中出现连接故障的某些情况。网络越可靠，需要考虑CAP定理的可能性就越低。
CAP定理可以帮助你理解一旦将数据进行分区，就必须考虑在网络出现故障的情况下，可用性-一致性所能承受的范围。CAP定理让用户自己决定哪个选项最适合业务需求。图2-10展示了一个CAP定理适用的示例。
图2-10 分区决策。CAP定理可以帮助你在网络故障时，在可用性和一致性相对的优缺点之间做出取舍。在左图中，客户端执行一个正常的写操作，首先将写入主节点，然后再通过网络将数据复制到从节点。如果网络出现故障，客户端API决定了可用性或者一致性的相对度量。在中间的图中，你接受了写操作并承受了可能会从从节点读到不一致数据的风险。在右图中，你选择了保证一致性并阻塞了客户端写操作直到数据中心之间的连接恢复
客户端写入首要的主节点，主节点再向另一个备份的从节点复制数据。CAP迫使用户考虑中节点之间连接出现故障时是否接受一个写操作。如果你接受写操作，那么需要负责确保远程节点稍后会进行更新，并且将承受在连接恢复之前，客户端有可能读到不一致的数据的风险。如果拒绝客户端写入，那么牺牲了可用性，客户端必须稍后重试。
尽管CAP定理在2000年就提出了，但它仍然会引起困惑。CAP定理通过一些罕见的终结案例限制了设计选型，并且CAP定理只适用数据中心之间发生网络故障的情况。大多数情况下，可靠的消息队列能够很快地在故障后恢复数据一致性。
CAP定理适用的规则如图2-11所示。
图2-11 CAP定理说明如果只使用一个处理器，可以兼顾一致性和可用性。如果使用多个处理器，只能基于事务类型、用户、预计的故障时间或者其他因素在一致性和可用性之间做出选择
像CAP定理这样的工具可以帮助指导组织内部数据库选型的讨论并且确定哪些属性（一致性、可用性和扩展性）才是最重要的。如果严格的一致性和更新可用性同时需要，那么更快的单个处理器可能是最好的选择。如果需要分布式系统提供的扩展能力，那么要基于需求为每个事务类型在更新可用性和读一致性之间做出选择。
无论选择哪个选项，CAP定理提供了一个能帮助你权衡每个SQL或者NoSQL系统利弊的标准流程，而最终，你将会做出一个明智的决定。
Sally被委托去帮助一个团队设计一个管理贵宾礼品卡的系统。和银行账户有些类似，持卡人可以为卡充值（存款）、购买（取款）和查看卡的余额。礼品卡的数据会被分区并复制到两个数据中心，一个在美国，一个在欧洲。居住在美国的人们优先分区到美国的数据中心，而欧洲的人们优先分区到欧洲的数据中心。
已知两个数据中心之间的数据传输线路会短时间的中断，大概每年10～20分钟。Sally知道这是一个切分分区的实例，它将考验系统的分区容错性。团队需要决定当数据传输线路故障时全部3个操作（存款、取款和查看余额）是否需要能够继续。
团队决定即使在数据传输线路故障时，存款操作也应该能够继续，这是因为当连接恢复后，存款记录能够更新两个站点的数据。Sally提到如果一个站点不能及时更新另一个站点的余额信息，切分分区可能会造成读取结果不一致。但是团队决定当发生连接故障时，如果请求银行余额，仍然从本地分区返回上次的余额。
对于购买事务，团队决定当发生连接故障时，一旦用户连接到主分区，事务应当继续执行完成。为了限制风险，对于复制分区的取款操作只会限制在一个特定的数额，如100美元。一些报表将会用于查看在网络中断期间，所有分区上的各种取款操作导致了产生错误余额的频率。
本章展示了一些NoSQL运动的关键概念和深刻洞见。下面这个列表包含了我们目前为止讨论过的一些重要概念和架构上的指导原则。接下来的几章将继续讨论这些概念。
贯穿全书，我们都在强调用一个正规流程来评估系统的重要性，它有助于识别出哪些特性对于组织是最重要的，需要做出哪些妥协。
此时此刻，你应该理解了使用NoSQL系统的好处和它们如何帮助你满足业务目标。在下一章中，我们将构建模式列表并回顾RDBMS架构的优劣，然后再聚焦那些相关的NoSQL数据模式。
