电子书：如何选择 NoSQL 数据库

2 / 15

电子书：如何选择 NoSQL 数据库

NoSQL 最早由谷歌和亚马逊提出，用于解决自己业务模型中遇到的扩展难题。随着大数据时代的到来，

越来越多的组织需要处理大量的网站流量、大数据和社交媒体数据等，人们对 NoSQL 的需求越来越旺盛，

NoSQL 数据库产品也越来越多。其中主流的 NoSQL 数据库包括文档数据库、图形数据库、列式数据库和键值

数据库。很多企业关系自己是否应该从传统数据库转到 NoSQL 数据库，应该选择什么样的数据库？本书详列

了相应的技巧和案例，供您参考。

你的企业离 NoSQL 还有多远？

摘要：传统 SQL 数据库善于处理表中有序布局、联系紧密的数据。但是 SQL 数据库的缺点之一在于难以

维护，如果数据量猛增，维护起来就更难了。

NoSQL 还是 SQL？企业选型需保持冷静头脑

摘要：关于 NoSQL 与关系型数据库之战的话题就从来没有停止过，来自各自阵营的声音让相对平静的数

据管理市场变得暗潮汹涌。

NoSQL 应用的三大陷阱

摘要：像很多新兴技术一样，NoSQL 也经历了一段炒作期，很多企业纷纷部署 NoSQL 数据库，结果往往

是喜忧参半。。

3 / 15

如何利用非关系型数据库技术创造价值？

摘要：非关系型数据库的流行正在转变数据管理现状。现在人们不一定需要将数据结构化，就可以利用

NoSQL 数据库架构解决他们的新数据需求，也可以将这些新技术与传统关系型数据进行整合，从大数据中挖

掘出新价值。

互联网公司的几个 NoSQL 应用场景

摘要：本文来自知乎社区上的一个问题，目前哪些 NoSQL 数据库应用广泛，各有什么特点？来自支付宝

公司的 Leverly总结了四个主要的应用场景。

互联网公司数据架构能为传统行业带来哪些启示

摘要：云和恩墨公司的技术总监张乐奕（Kamus）以及豆瓣公司的数据库团队主管员旭鹏，讨论了传统行

业的数据架构与互联网公司有何不同、豆瓣公司的总体数据架构情况和企业如何选择不同的数据库技术等问题。

分享比价网站的 NoSQL 数据库迁移经验

摘要：由于业务增长速度很快，保险类比价网站 Comparethemarket.com 正在将系统从微软 SQL Server

数据库迁移到 MongoDB。

4 / 15

你的企业离 NoSQL 还有多远？

什么是 NoSQL？所谓 NoSQL（Not Only SQL），即非关系型数据库。在传统数据存储系统中，数据存

储在多个表中，相互关系通过主键和外键来建立，而管理主键和外键关系的正是 SQL。而在 NoSQL 数据库中，

不存在传统的外键关系，所以人们把这种语言称为 NoSQL。NoSQL 最早由谷歌和亚马逊提出，用于解决自己

业务模型中遇到的扩展难题。随着大数据时代的到来，越来越多的组织需要处理大量的网站流量、大数据和社

交媒体数据等，人们对 NoSQL 的需求越来越旺盛，NoSQL 数据库产品也越来越多。其中主流的 NoSQL 数据

库包括文档数据库、图形数据库、列式数据库和键值数据库。

NoSQL 为何与众不同？

传统 SQL 数据库善于处理表中有序布局、联系紧密的数据，用户可以进行详细的查询，以报表的形式提取

数据。但是 SQL 数据库的缺点之一在于难以维护，如果数据量猛增，维护起来就更难了。除此之外，它还面临

一个更大的问题，即在某一点上无法线性扩展。NoSQL 解决方案则没有这样的问题。

Mongo 数据库的产品市场总监 Kelly Stirman 解释了为什么传统数据库难以处理最新的数据：传统数据

库是在表之间传输数据的，一个应用程序的完成可能要经过几千张表。如果你想在数据层更新一个对象，你需

要同时在很多表中协调数据的更新。要确保更新的完整度，你需要十分成熟的交易系统。Stirman 认为如果使

用文档存储，问题就简单的多。“因为两者的数据模型是不同的。与其建立巨大而复杂的映射，不如直接把文

档映射到对象。这样，更新一个对象就像更新一个文档那样简单。”

横向扩展能力，是 NoSQL 能够脱颖而出的一大亮点。Seven Databases in Seven Weeks 作者 Eric

Redmond 说道：“你不需要垂直扩展，也不需要花几百万美元买 Oracle box，你只需要买一组便宜的硬件，

把它们分布到你的数据库就行了。”

从商业角度来看，随着时间的推移，以模块化的方式扩展的能力很有吸引力，因为成本更低，灵活性更好。

除此之外，NoSQL 还有以下优势：

自动保存新的数据结构的历史数据

5 / 15

无模式架构意味着数据不需要定义到最后一个细节就可以存储到数据库中，数据可以随意按需迁移，基

本没有宕机时间

NoSQL 支持 AWS 或 RackSpace 等云服务供应商提供的 IaaS 和 PaaS 部署

非关系型数据库的结构十分适合虚拟机和负载均衡要求的数据有效利用和内存的有效利用

因为 NoSQL 仍然属于新兴技术，组织在应用时难免犯一些错误。最常见的在不需要 NoSQL 的时候采用

NoSQL。NoSQL 可扩展的能力的确很赞，但如果现有数据库能够应对目前的数据增长，组织完全可以继续使

用 SQL 数据库。

开源技术的确可以节省成本，鼓励创新，但需要考虑后续成本。另外，缺乏标准也是一个问题，由于开源

技术可移植性差，组织很可能受制于供应商。

Making Sense of NoSQL一书的联合作者 Dan McCreary 表示，NoSQL 面临的另一个挑战是，很多开发者

对它不熟悉，不知道怎么在 NoSQL 数据库里写代码。“团队长期使用 Java 和 Hibernate，习惯用 UML 建模，

生成 Java，虽然 Java 会自动生成上万个 insert，而用 NoSQL 生成一个就够了，但是团队还是会选择自己熟

悉的工具，他们用旧工具处理新任务，结果既浪费了资源又增加了不必要的复杂性。

那么，组织该如何决定何时使用、以及如何使用 NoSQL 呢？一下是几点建议：

了解业务需求。如果不是能够大量节约成本、显著增强性能，建议仍然使用 SQL 数据库。

如果数据库需要大规模扩展、处理大量临时数据、存储大量对象或需要运行 SQL 上无法运行的查询，

那么可以考虑 NoSQL。

问题类供应商会不遗余力地推销自己的解决方案。但你需要考虑与第三方合作，它可以移植标准，确保

该解决方案与其他系统或解决方案的兼容性

最后，做好应对挑战的准备吧。需要改变的不只是数据库，从部署架构、工具、培训到人员都需要改变。

（来源：TechTarget 中国 作者：Jason Tee）

6 / 15

NoSQL 还是 SQL？企业选型需保持冷静头脑

关于 NoSQL 与关系型数据库之战的话题就从来没有停止过，来自各自阵营的声音让相对平静的数据管理

市场变得暗潮汹涌。

由于企业希望能够应对大数据带来的挑战，数据库两大阵营都声称提供最佳的方法来管理海量数据难题。

选择正确的数据库产品以满足自身需求，看似非常直接的诉求在纷繁嘈杂的背景下已经变得越来越困难，

这也让两大阵营的主要厂商之间的竞争趋于白热化。2014年数据库之争也没用缓和的迹象，迅速成熟的NoSQL

解决方案让关系型数据库阵营感受到了前所未有的压力，后者也需要更多的理由来说服企业 CIO 继续使用传统

的数据库产品来应对大数据挑战。

在我们过去一年对数据库流行度排行榜的报道中可以看出，包括 CouchDB、Cassandra、Redis 以及

MongoDB 这样的 NoSQL 数据库取得了非常快速的进步，而像 PostgreSQL，MariaDB 这样的的传统数据库

也并没有原地踏步。NoSQL 很多都是开源产品，关系型数据库也很擅长借鉴 NoSQL 的长处，比如添加 JSON

的支持，让关系型数据库也能够处理半结构化数据以及 web 文档等数据;还有 HStore 这样的快速数据查询功

能等。许多关系型数据库已经能够提供与 NoSQL 非常类似的核心功能。

而对于满足传统标准化的交易系统需求，NoSQL 数据库就丝毫没有优势可言了。事实上，很多企业也都

摆正了对 NoSQL 的态度，NoSQL 的确非常适合一些类型的大数据应用，但并不能满足全部的负载需求。

那么 NoSQL 真正的所长之处在哪里呢？

NoSQL 的真正优势在于它能够处理海量的数据，而不是来支撑实时的决策。关键是企业能够使用正确的

技术来解决正确的问题。

当一种技术触发思想意识上的分歧时，比如说 NoSQL，人们就总是喜欢划分明确的阵营，然后选择全力

支持某一方。对于企业来说，最重要的是要有开明的眼光，不要被炒作冲昏头脑，这样才能从数据库技术投入

上获得最大的价值产出。

（来源：TechTarget 中国 作者：孙瑞）

7 / 15

NoSQL 应用的三大陷阱

像很多新兴技术一样，NoSQL 也经历了一段炒作期，很多企业纷纷部署 NoSQL 数据库，结果往往是喜忧

参半。NoSQL 技术曾经被炒得沸沸扬扬，技术人员都去接受 NoSQL 的培训，但短暂的繁荣后，NoSQL 复归

平寂。这不能怪任何人。供应商宣称自己的解决方案能解决所有问题，开发者则兴致盎然地讲数据库扩展性有

多重要。

组织自身，以为解决数据库难题的方法终于来到了。而现在，第一代 NoSQL 数据库已经发展到高潮，解

决方案也已经成熟，是时候总结一下过去十年里的教训了。本文总结了企业使用 NoSQL 时常犯的三点错误，

以及如何规避这些错误。

NoSQL，不只是可扩展

Seven Databases in Seven Weeks 一书的作者 Eric Redmond 认为，人们往往错误的认为 NoSQL 就是

web 扩展。要真这样以为可就贻笑大方了。

虽然非关系型数据库产生于谷歌和亚马逊这种希望解决 web 环境中大规模扩展问题的公司，而文档型数据

库 Mongo 的名字也来源于英文单词 humongous（巨大无比的），暗示数据和业务量巨大。但是，如果只从

扩展性角度考量 NoSQL，只能一叶障目。其实，哪怕是很小的公司，它们基本只需要处理宜用图表表现的社

交媒体数据，也能从 NoSQL 解决方案中获益。而有些要处理海量数据的大公司，可能仍然依赖 SQL 成熟的查

询系统。数据库的选择不只是数据扩展性那么简单，更要从应用案例和非功能性需求来考量。

建议：冷静思考，把业务需求和现实条件放在首位。一味复制谷歌的架构不会让你成为下一个谷歌。

开发者合格吗？

Making Sense of NoSQL 的作者 Ann Kelly 和 Dan McCreary 指出了另一个问题。最近，有一项高调宣

传的web工程，由于集成团队能力太差而终告失败。书中记录到，“公司买进了一个耐用、强大又成熟的NoSQL

数据库 MarkLogic，但是他们雇了一个只懂 Java 编程和关系型数据库的集成人员。他们花了三四千万美元进

行编码，但这完全没必要，最终也只能白白丢掉。”文中提到这个网站就是声名狼藉的奥巴马医保。

8 / 15

Dan 认为，这样的 NoSQL 问题的出现已经不是第一次了，也不会是最后一次。只要开发团队没有在非关

系型数据库编写代码的经验，组织就可能重蹈覆辙。对于习惯了旧有流程的开发者来说，使用新技术时重复开

发的现象很常见。在文档存储的流线型环境里已经完全没有必要再用 UML 和 Java 精心设计代码了。

建议：在文档型数据库中，文档直接映射到对象，代码精简、重点突出。如果代码激增，就需要检查工具、

方法和技术团队了，从而找出问题所在。

分布式仍然是难啃的骨头

Eric Redmond 认为，无论是在实施还是后续管理阶段，知识和经验都是无可替代的。“其实当谈到规模

巨大，数据库本身并不是问题，问题在于实际操作过程中，如何进行管理。你可以安装 Couch，在一台机器上

运行一系列查询。但如果你把任务分布到多个机器上，这就变成了一个分布式系统，完全变成另外一个东西了。

这对于系统管理员和操作员的要求都极高。一条查询或许能在本地机器上快速运行，但未必能能在上百台机器

上横向扩展，两者没有实质性的联系。

Redmond 表示，好在一些 NoSQL 数据库的设计帮助开发者避免了这种困境。Couch 就是一个例子，它

假定用户会对很多服务器进行查询，所以自动使用了 MapReduce。很多人指责 Riak 的易用性，Redmond 认

为，Riak 之所以难以使用，主要是因为在分布式环境里写查询很困难。

建议：选择符合最佳实践的 NoSQL 数据库。另外，键值存储是最简单的实现简易扩展的方法之一。

（来源：TechTarget 中国 作者：Jason Tee）

9 / 15

如何利用非关系型数据库技术创造价值？

非关系型数据库（non-relational databases）的流行正在转变数据管理现状。现在人们不一定需要将数

据结构化，就可以利用 NoSQL 数据库架构解决他们的新数据需求，也可以将这些新技术与传统关系型数据进

行整合，从大数据中挖掘出新价值。

直到现在，数据作为深度业务洞察力来源的潜力仍然受其结构的限制。如果没有新出现的数据库技术，我

们只能采用标准的后台设计方法，将数据限定在死板的架构中，而无法体现实际数据结构的多样性。由于内部

不够灵活，这些传统架构将妨碍组织开发结构化与非结构化信息的新用例。

非关系型数据库架构的持续流行使数据管理出现了转折点。最新出现的技术是一些新的横向扩展非结构化

数据库，它们更适合解决一些问题，同时传统的关系型数据库仍然在其他领域保持原来位置。

技术的发展使各种组织不再受限于数据库架构的选择。随着竞争领跑者发现了满足特殊数据需求的数据库

方法，我们在 2012 年看到了下面三种重大变革：

1. 随着数据架构师开始接受架构与设计工具套件的发展——从关系型数据库转变为增加各种

成熟的非关系型技术（NoSQL 数据库系统），数据库领域重新洗牌。

2. 由于革命性技术和方法（如具有超大规模数据高效处理能力的 Apache Hadoop）的推动，混

合数据生态系统越来越流行。

3. 响应速度更快的数据管理生态系统的出现，提供了一种灵活实现规模化低成本的原型化交付

（经过行业验证）的新方法。

从现在起，明智的分析主管将致力于将用例具体化到最佳的平台上。他们不会过度关注于新技术的可用性，

而是去发现一些整合关系型与非关系型数据库“契合点”，从中挖掘出超越原始用途的信息价值。

通过利用新的数据架构方法，越来越多的组织将能够发现和探索数据商业化的突破点。

正如通信运营商从他们处理在大量客户数据中挖掘出宝贵的 B2B 收益来源一样，其他商业公司也将通过更

好地利用现有数据来发现新的业务增长点。

10 / 15

重新考虑数据的存储、处理和细化方式，意味着需要重新评估传统的数据管理方法。直到现在，数据仍然

被视为一种结构化资产和必须维护的成本中心。

新数据库架构的出现，意味着这种看法将彻底改变。服务主导的数据管理将要求 IT 主管考虑一个问题：业

务如何能够最轻松地利用现有数据和之前未能获得的数据？

敏捷数据服务架构

随着越来越多架构方法的出现，数据生命周期会缩短，并且变得越来越敏捷。数据管理方法将不再致力于

“过度控制”数据，而是逐渐减少条条框框。其中一个主要目标是通过鼓励和利用数据共享发掘新的潜能。亚

马逊是这个领域的先锋。通过使用敏捷数据架构建立面向服务的平台，这家公司已经能够为客户提供新型云存

储和数据管理服务——同时使他们自己能够灵活处理一些未知服务的未来需求。

非关系型数据库的空前流行复兴了常规架构和“传统”数据管理方法的作用。从现在开始，分析主管们需

要转而采用混合架构，以最佳方式整合两种技术，去利用现在海量结构化和非结构化信息的全新洞察力。总之，

数据管理专业人员的“黄金时代”已经到来。

（来源：TechTarget 中国 作者：Nick Millman,Pankaj Sodhi）

11 / 15

互联网公司的几个 NoSQL 应用场景

本文来自知乎社区上的一个问题，目前哪些 NoSQL 数据库应用广泛，各有什么特点？来自支付宝公司的

@Leverly 总结了四个主要的应用场景：

1. In-Memory KV Store : Redis

基于内存你的键值存储，同时提供了更加丰富的数据结构和运算的能力，成功用法是替代 memcached，

通过 checkpoint 和 commit log 提供了快速的宕机恢复，同时支持 replication 提供读可扩展和高可用。

2. Disk-Based KV Store: Leveldb

真正基于磁盘的键值存储，模型单一简单，数据量不受限于内存大小，数据落盘高可靠，Google 的几位

大神出品的精品，LSM 模型天然写优化，顺序写盘的方式对于新硬件 ssd 再适合不过了，不足是仅提供了一个

库，需要自己封装 server 端。

3. Document Store: Mongodb

分布式 NoSQL，具备了区别 MySQL 的最大亮点：可扩展性。MongoDB 最新引人的莫过于提供了 SQL

接口，是目前 NoSQL 里最像 MySQL 的，只是没有 ACID 的特性，发展很快，支持了索引等特性，上手容易，

对于数据量远超内存限制的场景来说，还需要慎重。

4. Column Table Store: HBase

这个富二代似乎不用赘述了，最大的优势是开源，对于普通的 scan 和基于行的 get 等基本查询，性能完

全不是问题，只是只提供裸的 api，易用性上是短板，可扩展性方面是最强的，其次坐上了 Hadoop 的快车，

社区发展很快，各种基于其上的开源产品不少，来解决诸如 join、聚集运算等复杂查询。

（来源：TechTarget 中国 作者：Leverly）

12 / 15

互联网公司数据架构能为传统行业带来哪些启示

在中国各行各业的信息化发展进程当中，互联网公司可以说是起步较晚但发展速度最快的。包括 Yahoo!、

Google、Facebook 在内的知名互联网公司引领了 IT 新技术的发展趋势，我们所熟知的 NoSQL、Hadoop 等

技术的起源都来自于互联网阵营。而在数据架构方面，互联网公司也有其独到的方式方法来解决各种问题，对

于传统行业的企业来说，其实有很多值得借鉴的经验。

为此我们在下面的视频采访中，请到了云和恩墨公司的技术总监张乐奕（Kamus）以及豆瓣公司的数据库

团队主管员旭鹏，围绕“互联网公司数据架构能为传统行业带来哪些启示”这一话题，进行了深入探讨。在本

次访谈节目中，您将能够了解到：

传统行业的数据架构与互联网公司有何不同？

豆瓣公司的总体数据架构情况

企业如何选择不同的数据库技术

在 IT 人才培养以及解决问题的方式上，互联网公司能给传统行业提供哪些经验？

（来源：TechTarget 中国 作者：孙瑞）

13 / 15

分享比价网站的 NoSQL 数据库迁移经验

由于业务增长速度很快，保险类比价网站 Comparethemarket.com 正在将系统从微软 SQL Server 数据

库迁移到 MongoDB。公司的解决方案架构师 Matthew Collinge 在接受 TechTarget 记者采访时表示，

Comparethemarket.com 向来重视敏捷开发和开源技术，因此这次从传统数据库迁移到 NoSQL 数据库也是

处于这一战略的考虑。

据了解，公司从去年 4 月就开始了数据库迁移项目，预计将在 18 个月之内完成。

业务发展太快？数据库技术来支撑

Collinge 介绍，Comparethemarket.com 原先的系统是从集团大型机中直接拷贝出来的，导出到 SQL

Server 和.Net 架构之下。这套系统从公司成立之初一共使用了 4 年的时间，当时的业务还相对较小。而在过

去的 18 个月当中，公司的规模扩大了一倍，访问流量也翻了一番。

Comparethemarket.com 每天都会进行 1700 万次价格比对，其中所有产品的价格比对都使用了一套代

码库，Collinge 认为这同样给业务带来了压力。

除此之外，IT 部门的 100 多名员工根据不同的产品被划分为多个小组，每个小组都希望对发布时间能够独

立掌控，而且不受其他小组的影响。出于这个原因，保险公司选择将应用拆分成多个功能单元。

伴随着购买越来越多的服务器进行扩展，性能的瓶颈也显现出来。公司认为，迁移到 NoSQL 数据库能够

缓解这一问题。

从去年 4 月开始，公司先将家庭保险比对业务的系统迁移到了 MongoDB 上，未来所有的业务系统都将运

行在 MongoDB 上。

14 / 15

支持敏捷开发

Collinge 解释说，由于老系统使用的时间比较长，有一大部分的开发时间都被偶发的系统复杂性所占用了。

当业务人员想出一个点子后，他希望在网站上测试这个点子是否可行。而使用之前的系统，要把这个点子投入

生产环境至少需要 3 周的时间，目前只需要短短的 30 分钟。

这其中最基本的出发点是使用事件驱动的架构，它能够实时地洞察运营系统是如何运作的。Collinge 表示：

“这样的话，当有问题发生的时候，我们就能够与保险公司合作伙伴快速地进行沟通。不用再把大量的数据加

载到数据仓库，然后运行好几天才能得出结果了。”

新的架构将帮助公司进行实时的分析和定制化服务，在此之前，如果你想要添加车载音响保险到你的汽车

保险比对当中，他需要线下才能完成。Collinge 表示，MongoDB 在面向开发者友好以及开源社区支持方面做

得都非常好，这是我们迁移到该数据库平台的重要考量之一。同时，公司还和 10gen 签署了技术支持协议，这

对我们帮助很大。

据了解，兄弟公司 Comparethemeerkat.com 也计划将系统迁移到 NoSQL 数据库，但并未透露是不是

MongoDB。

（来源：TechTarget 中国 作者：Brian McKenna）

15 / 15

本期电子书由 TechTarget 中国出品