(特价书)NoSQL精粹（英文版）

    书籍
    计算机书籍
持续增长的海量数据，催生了一种名为NoSQL的非关系型数据库。其倡导者宣称，该技术可构建出更高效、更易扩展且更易编码的系统。

本书言简意赅地介绍了这项新技术。书中解释了NoSQL数据库的工作原理，以及NoSQL可能优于传统关系型数据库之处。作者讲解了有关概念，以指导读者评估NoSQL数据库是否有利于解决当前项目需求，并介绍了采用NoSQL数据库后还需深入研究的其他技术。

本书第一部分专注于讲解无模式数据模型、聚合、新的分布式模型、CAP定理、映射—化简等核心概念，第二部分研究实现NoSQL时的架构与设计问题。作者以实际用例演示了如何在工作中运用NoSQL数据库，并以Riak、MongoDB、Cassandra和Neo4j为例，着重讲解了每一种NoSQL数据库的典型用法。

此外，本书利用Pramod Sadalage先生的开拓性研究成果，展示了怎样在模式迁移问题上实现演进式设计：这是运用NoSQL数据库时必备的技巧。本书结尾描绘了NoSQL如何引领即将到来的混合持久化新时代，那将是多种数据库并存的世界，架构师可针对每种数据访问类型选择最优技术。



本书内容包括

·评估企业级应用程序是否应使用NoSQL技术

·理解部署NoSQL时的架构权衡

·用NoSQL简化开发工作，避免因为在内存数据结构与关系型数据库数据结构之间映射而引发的问题

·对比时下几项领先的NoSQL数据库产品

作者：（印度）普拉莫德 J.塞得拉吉（Pramod J.Sadalage） （美国）马丁·福勒（Martin Fowler）

前言
第一部分　概念
第1章　为什么使用NoSQL3
1.1　关系型数据库的价值3
1.1.1　获取持久化数据3
1.1.2　并发4
1.1.3　集成4
1.1.4　近乎标准的模型4
1.2　阻抗失谐5
1.3　“应用程序数据库”与“集成数据库”6
1.4　蜂拥而来的集群8
1.5　NoSQL登场9
1.6　要点12
第2章　聚合数据模型13
2.1　聚合14
2.1.1　关系模型与聚合模型示例14
2.1.2　面向聚合的影响19
2.2　键值数据模型与文档数据模型20
2.3　列族存储21
2.4　面向聚合数据库总结23

　　我们已经在企业级计算领域研究了20余年，编程语言、架构、平台、软件开发流程等技术都在改变，然而这期间有一件事却一直没变，那就是：大家依然使用关系型数据库来存储数据。虽说也出现了一些挑战关系型数据库的产品，而且有的还在某些领域成功了，但是总体来说，留给架构师的数据存储问题仍然是选择使用哪款关系型数据库的问题。
　　稳定性在此领域颇受重视。企业的数据比程序存储的时间要长很多（至少大家都是这么说的。当然啦，我们也见过许多非常老的程序）。拥有一个既稳定，又容易理解，而且还能让许多应用程序编程平台访问的数据库，是非常有价值的。
　　不过，关系型数据库现在碰上新对手了，它的名字叫NoSQL。由于我们需要处理的数据量越来越大，必须以商用服务器集群来构建大型硬件平台，因此NoSQL就应运而生了。这也使大家要再次考虑那个存在已久的难题，即代码如何才能同关系型数据库良好地结合起来。
　　“NoSQL”这个词的定义是非常不明确的。它泛指那些最近诞生的非关系型数据库，诸如Cassandra、MongoDB、Neo4J和Riak等。它们主张使用无模式（schemaless）的数据，可以运行在集群环境中，并且能够牺牲传统数据库所具备的一致性，以换取另外一些有用的特性。NoSQL的倡导者声称，使用它们可以构建出性能更高、扩展度更好且更易编程的系统。
　　这会不会敲响了关系型数据库即将灭亡的第一声警钟呢？还是说NoSQL要抢走数据库领域的头把交椅？我们的回答是：“这两种情况都不会出现。”关系型数据库是一个非常强大的工具，我们希望能长时间使用下去；然而大家也要看到一场深远的变革，那就是：关系型数据库不再是唯一的选择了。我们认为，数据库领域正进入混合持久化（Polyglot Persistence）时代，由企业乃至个人研发的应用程序，可以使用多种技术来管理数据。因此架构师需要熟悉这些技术，并且能根据不同的需求做出适当的选择。若非如此，笔者怎会花那么多时间和精力来写这本书呢？
　　本书给诸位读者提供足够多的信息，协助大家在以后的研发过程中思考：项目是否真的值得使用NoSQL数据库。每个项目都是不同的，我们不可能写出一个简单的决策树，用它来选出合适的数据存储方式。与之相反，本书力求讲解大量的背景知识，以便大家了解NoSQL的工作原理，这样的话，你不用在互联网上四处寻找，就能够做出适合自己项目的决定了。笔者刻意将本书写得很短，以便读者能够快速阅览它。虽说本书不会回答各种具体问题，但是，它可以帮你缩小考虑的范围，让你明白自己当前应该提出哪些问题。
　　NoSQL数据库为何引人关注
　　我们来看一下大家选用NoSQL数据库的两个主要原因。
　　应用程序的开发效率。在很多应用程序的开发过程中，大量精力和时间都放在了内存（in-memory）数据结构和关系型数据库之间的映射上面。NoSQL数据库可以提供一种更加符合应用程序需求的数据模型，从而简化了数据交互，减少了所需编写、调试并修改的代码量。
　　大规模的数据。企业所重视的是，数据库要能够快速获取并处理数据。他们发现，即便关系型数据库能达成这一目标，其成本也很高。主要原因在于，关系型数据库是为独立运行的计算机而设计的，但是现在大家通常使用由更小、更廉价的计算机所组成的集群来计算数据，这样更实惠些。许多NoSQL数据库正是为集群环境而设计，因此它们更适合大数据量的应用场景。
　　本书内容
　　本书分为两个部分。第一部分主要讲述核心概念，让读者能够判断出NoSQL数据库是否适合自己，并且了解各种NoSQL数据库之间的差别。第二部分更加专注于实现NoSQL数据库系统。
　　第1章解释了NoSQL发展如此迅速的原因：由于需要处理的数据量越来越多，所以大型系统的扩展方式，由原来在单一计算机上的纵向扩展，转变为在计算机集群上的横向扩展。这也印证了许多NoSQL数据库的数据模型所具备的一个重要特性，那就是：可以把内容密切相关的数据组织成一种丰富的结构，并将其显式存储起来，以便作为一个单元（unit）来访问。本书中，我们将这种类型的结构称为聚合（aggregate）。
　　第2章描述了在NoSQL领域的三种主要数据模型中，如何体现“聚合”这一概念。这三种数据库模型是：“键值模型”（key-value，参见2.2节），“文档模型”（document，参见2.2节）和“列族模型”（column family，参见2.3节）。聚合为许多种应用提供了一个自然的交互单元，既改善了集群的运行状况，又使编写程序来访问数据库变得更为容易。第3章转到聚合的缺点上面：难以处理位于不同聚合的实体之间的关系（参见3.1节）。这自然就引出了图数据库（参见3.2节），它是一个不属于面向聚合（aggregated-oriented）阵营的NoSQL数据模型。我们也会讲到NoSQL数据库的共同特性：它们都是以“无模式”的形式来操作的（参见3.3节）。模式的这种特性确实提供了更大的灵活性，但是它并不像大家想象的那么万能。
　　在讲完NoSQL数据模型方面的内容之后，我们接下来要讲分布模型。第4章描述了数据库如何在集群中分布数据。这个问题又细分为“分片”（sharding，参见4.2节）和“复制”（replication），复制方式可以是“主从复制”（master-slave replication，参见4.3节）或者“对等复制”（peer-to-peer replication，参见4.4节）。了解完分布模型的概念后，接下来要讲“一致性”（consistency）问题。与关系型数据库相比，NoSQL数据库在一致性方面提供了更多选择，这么做是因为NoSQL要更好地支持集群。于是，第5章谈到了更新与读取操作对一致性的影响（分别参见5.1节和5.2节），如何在一致性与持久性之间进行仲裁（参见5.5节），以及如何放宽对持久性的约束以提升其他特性（参见5.4节）。如果之前听过NoSQL，那么就应该听过“CAP定理”（The CAP Theorem）。5.3节中介绍了CAP定理的相关知识，告诉大家如何根据该理论来权衡一致性与其他特性。
　　前面这些章节主要侧重于如何分布数据并保持其一致性，接下来的两章讨论了要完成这项工作所需的一些重要工具。第6章讲述了版本戳（version stamp），它用来记录数据库的内容变更，并且可以检测数据是否一致。第7章概述了“映射-化简”（Map-Reduce）操作，这种计算方式很适合在集群中组织并行计算，因而也适用于NoSQL系统。
　　讲完这些概念后，我们针对以下4种数据库各举一些例子，来演示如何实现上述概念。第8章使用Riak来演示“键值数据库”，第9章使用MongoDB作为“文档数据库”的示例，第10章选用Cassandra来探讨“列族数据库”，第11章选择了Neo4J作为“图数据库”的示例。此处必须强调：要想全面学习数据库，只依靠这些章节是不够的。因为除此之外还有很多内容，没办法写在这本书中，而且还有更多东西必须尝试之后才能学会。本书选择这些示例，并不是建议大家在工作中使用它们，其目的是让读者知道数据的各种存储方式，明白不同的数据库技术如何使用前面提到的概念。读者会看到这些数据库系统都需要何种程序代码，并且简单了解使用它们时所应遵循的开发思路。
　　有些人经常会觉得：因为NoSQL数据库没有模式，所以在应用程序的生命期中，可以毫无困难地改变其数据结构。本书不同意此观点，因为无模式的数据库其实隐含了一种模式，在实现数据结构变更时，也必须修改其规则。所以，第12章解释了数据如何在强模式与无模式系统之间迁移。
　　所有这一切都清楚地表明：NoSQL不是独立存在的，也不会取代关系型数据库。第13章着眼于混合持久化领域的发展趋势：多种数据存储方式将共存，有时甚至会存在于同一个应用中。第14章将大家的视野扩展至本书之外，在混合持久化领域中，考虑一些前面没有涉及的技术。
　　掌握了前面所讲的全部内容之后，读者就应该明白如何选择合适的数据存储技术了。所以最后一章（第15章）提供了一些选择数据库时可以参考的建议。笔者认为，有两个关键因素：找到一种高效的编程模型，其数据存储模型要非常符合待开发的应用程序，并且确保其获取数据的效率与弹性均符合开发者的需求。从NoSQL诞生之初，我们就担心没有一套定义明确的流程可以遵循，现在，你仍然需要结合自己的需求，来验证自己所选择的数据库技术是否合适。

　　The term UNoSQL" caught on like wildfire， but it's never been a term that's had much in the way of a strong definition.The original call （NoSQL Meetup） for the meetup asked for "open—source， distributed， nonrelational databases." The talks there （NoSQL Debrief） were from Voldemort， Cassandra， Dynomite， Base， Hypertable， CouchDB， and MongoDB—but the term has never been confined to that original septet.There's no generally accepted definition， nor an authority to provide one， so all we can do is discuss some common characteristics of the databases that tend to be called "NoSQL."
　　To begin with， there is the obvious point that NoSQL databases don't use SQL.Some of them do have query languages， and it makes sense for them to be similar to SQL in order to make them easier to learn.Cassandra's CQL is like this—"exactly like SQL （except where it's not）" （CQL）.But so far none have implemented anything that would fit even the rather flexible notion of standard SQL.It will be interesting to see what happens if an established NoSQL database decides to implement a reasonably standard SQL； the only predictable outcome for such an eventuality is plenty of argument.