随着大数据时代的到来，越来越多的网站、应用系统需要支撑海量数据存储，高并发、高可用、高可扩展性等特性要求。

传统的关系型数据库在应付这些已经显得力不从心，并暴露了许多难以克服的问题。

由此，各种各样的 NoSQL（Not Only SQL）数据库作为传统关系型数据的一个有力补充得到迅猛发展。

本文将分析传统数据库存在的一些问题，以及几大类 NoSQL 如何解决这些问题，希望给大家提供一些在不同业务场景下存储技术选型方面的参考。

传统数据库的缺点

传统的数据库有如下几个缺点：

• 大数据场景下 I/O 较高，因为数据是按行存储，即使只针对其中某一列进行运算，关系型数据库也会将整行数据从存储设备中读入内存，导致 I/O 较高。
• 存储的是行记录，无法存储数据结构。
• 表结构 Schema 扩展不方便，如要修改表结构，需要执行 DDL(data definition language)，语句修改，修改期间会导致锁表，部分服务不可用。
• 全文搜索功能较弱，关系型数据库下只能够进行子字符串的匹配查询，当表的数据逐渐变大的时候，like 查询的匹配会非常慢，即使在有索引的情况下。况且关系型数据库也不应该对文本字段进行索引。
• 存储和处理复杂关系型数据功能较弱，许多应用程序需要了解和导航高度连接数据之间的关系，才能启用社交应用程序、推荐引擎、欺诈检测、知识图谱、生命科学和 IT/网络等用例。

然而传统的关系数据库并不善于处理数据点之间的关系。它们的表格数据模型和严格的模式使它们很难添加新的或不同种类的关联信息。

NoSQL 解决方案

NoSQL，泛指非关系型的数据库，可以理解为 SQL 的一个有力补充。

在 NoSQL 许多方面性能大大优于非关系型数据库的同时，往往也伴随一些特性的缺失，比较常见的是事务库事务功能的缺失。

数据库事务正确执行的四个基本要素 ACID 如下：

下面介绍 5 大类 NoSQL 数据针对传统关系型数据库的缺点和提供的解决方案：

列式数据库

列式数据库是以列相关存储架构进行数据存储的数据库，主要适合于批量数据处理和即时查询。

相对应的是行式数据库，数据以行相关的存储体系架构进行空间分配，主要适合于小批量的数据处理，常用于联机事务型数据处理。

基于列式数据库的列列存储特性，可以解决某些特定场景下关系型数据库 I/O 较高的问题。

基本原理

传统关系型数据库是按照行来存储数据库，称为“行式数据库”，而列式数据库是按照列来存储数据。

将表放入存储系统中有两种方法，而我们绝大部分是采用行存储的。行存储法是将各行放入连续的物理位置，这很像传统的记录和文件系统。

列存储法是将数据按照列存储到数据库中，与行存储类似。下图是两种存储方法的图形化解释：

常见列式数据库

HBase：是一个开源的非关系型分布式数据库（NoSQL），它参考了谷歌的 BigTable 建模，实现的编程语言为 Java。

它是 Apache 软件基金会的 Hadoop 项目的一部分，运行于 HDFS 文件系统之上，为 Hadoop 提供类似于 BigTable 规模的服务。因此，它可以容错地存储海量稀疏的数据。

BigTable：是一种压缩的、高性能的、高可扩展性的，基于 Google 文件系统（Google File System，GFS）的数据存储系统，用于存储大规模结构化数据，适用于云端计算。

相关特性

优点如下：

高效的储存空间利用率：列式数据库由于其针对不同列的数据特征而发明的不同算法使其往往有比行式数据库高的多的压缩率。

普通的行式数据库一般压缩率在 3：1  到 5：1  左右，而列式数据库的压缩率一般在 8：1 到 30：1  左右。

比较常见的，通过字典表压缩数据： 下面中才是那张表本来的样子。经过字典表进行数据压缩后，表中的字符串才都变成数字了。

正因为每个字符串在字典表里只出现一次了，所以达到了压缩的目的(有点像规范化和非规范化 Normalize 和 Denomalize)。

查询效率高：读取多条数据的同一列效率高，因为这些列都是存储在一起的，一次磁盘操作可以把数据的指定列全部读取到内存中。

下图通过一条查询的执行过程说明列式存储(以及数据压缩)的优点。

执行步骤如下：

• 去字典表里找到字符串对应数字(只进行一次字符串比较)。
• 用数字去列表里匹配，匹配上的位置设为 1。 
• 把不同列的匹配结果进行位运算得到符合所有条件的记录下标。
• 使用这个下标组装出最终的结果集。

列式数据库还适合做聚合操作，适合大量的数据而不是小数据。

缺点如下：

• 不适合扫描小量数据。
• 不适合随机的更新。
• 不适合做含有删除和更新的实时操作。
• 单行的数据是 ACID 的，多行的事务时，不支持事务的正常回滚，支持 I(Isolation)隔离性(事务串行提交)，D(Durability)持久性，不能保证 A(Atomicity)原子性， C(Consistency)一致性。

使用场景

以 HBase 为例说明：

• 大数据量（100s TB级数据），且有快速随机访问的需求。
• 写密集型应用，每天写入量巨大，而相对读数量较小的应用，比如 IM 的历史消息，游戏的日志等等。
• 不需要复杂查询条件来查询数据的应用，HBase 只支持基于 rowkey 的查询，对于 HBase 来说，单条记录或者小范围的查询是可以接受的。

大范围的查询由于分布式的原因，可能在性能上有点影响，HBase 不适用于有 join，多级索引，表关系复杂的数据模型。

• 对性能和可靠性要求非常高的应用，由于 HBase 本身没有单点故障，可用性非常高。
• 数据量较大，而且增长量无法预估的应用，需要进行优雅的数据扩展的 HBase 支持在线扩展，即使在一段时间内数据量呈井喷式增长，也可以通过 HBase 横向扩展来满足功能。
• 存储结构化和半结构化的数据。

K-V 数据库

指的是使用键值(key-value)存储的数据库，其数据按照键值对的形式进行组织、索引和存储。

K-V 存储非常适合不涉及过多数据关系业务关系的数据，同时能有效减少读写磁盘的次数，比 SQL 数据库存储拥有更好的读写性能，能够解决关系型数据库无法存储数据结构的问题。

常见 K-V 数据库

Redis：是一个使用 ANSI C 编写的开源、支持网络、基于内存、可选持久性的键值对存储数据库。

从 2015 年 6 月开始，Redis 的开发由 Redis Labs 赞助，而 2013 年 5 月至 2015 年 6 月期间，其开发由 Pivotal 赞助。

在 2013 年 5 月之前，其开发由 VMware 赞助。根据月度排行网站 DB-Engines.com 的数据显示，Redis 是最流行的键值对存储数据库。

Cassandra：Apache Cassandra（社区内一般简称为C*）是一套开源分布式 NoSQL 数据库系统。

它最初由 Facebook 开发，用于储存收件箱等简单格式数据，集 Google BigTable 的数据模型与 Amazon Dynamo 的完全分布式架构于一身。

Facebook 于 2008 将 Cassandra 开源，此后，由于 Cassandra 良好的可扩展性和性能。

它被 Apple，Comcas，Instagram，Spotify，eBay，Rackspace，Netflix 等知名网站所采用，成为了一种流行的分布式结构化数据存储方案。

LevelDB：是一个由 Google 公司所研发的键／值对（Key/Value Pair）嵌入式数据库管理系统编程库， 以开源的 BSD 许可证发布。

相关特性

以 Redis 为例，K-V 数据库优点如下：

• 性能极高：Redis 能支持超过 10W 的 TPS。
• 丰富的数据类型：Redis 支持包括 String，Hash，List，Set，Sorted Set，Bitmap 和 Hyperloglog。
• 丰富的特性：Redis 还支持 publish/subscribe，通知，key 过期等等特性。

缺点如下：

• 针对 ACID，Redis 事务不能支持原子性和持久性(A 和 D)，只支持隔离性和一致性(I 和 C) 。

特别说明一下，这里所说的无法保证原子性，是针对 Redis 的事务操作，因为事务是不支持回滚（roll back），而因为 Redis 的单线程模型，Redis 的普通操作是原子性的。

大部分业务不需要严格遵循 ACID 原则，例如游戏实时排行榜，粉丝关注等场景，即使部分数据持久化失败，其实业务影响也非常小。因此在设计方案时，需要根据业务特征和要求来做选择。

使用场景

适用场景：

• 储存用户信息(比如会话)、配置文件、参数、购物车等等。这些信息一般都和 ID（键）挂钩。

不适用场景：

• 需要通过值来查询，而不是键来查询。Key-Value 数据库中根本没有通过值查询的途径。
• 需要储存数据之间的关系。在 Key-Value 数据库中不能通过两个或以上的键来关联数据。
• 需要事务的支持。在 Key-Value 数据库中故障产生时不可以进行回滚。

文档数据库

文档数据库（也称为文档型数据库）是旨在将半结构化数据存储为文档的一种数据库。文档数据库通常以 JSON 或 XML 格式存储数据。

由于文档数据库的 no-schema 特性，可以存储和读取任意数据。

由于使用的数据格式是 JSON 或者 BSON，因为 JSON 数据是自描述的，无需在使用前定义字段，读取一个 JSON 中不存在的字段也不会导致 SQL 那样的语法错误，可以解决关系型数据库表结构 Schema 扩展不方便的问题。

常见文档数据库

MongoDB：是一种面向文档的数据库管理系统，由 C++ 撰写而成，以此来解决应用程序开发社区中的大量现实问题。2007 年 10 月，MongoDB 由 10gen 团队所发展。2009 年 2 月首度推出。

CouchDB：Apache CouchDB 是一个开源数据库，专注于易用性和成为"完全拥抱 Web 的数据库"。

它是一个使用 JSON 作为存储格式，JavaScript 作为查询语言，MapReduce 和 HTTP 作为 API 的 NoSQL 数据库。

其中一个显著的功能就是多主复制。CouchDB 的第一个版本发布在 2005 年，在 2008 年成为了 Apache 的项目。

相关特性

以 MongoDB 为例进行说明，文档数据库优点如下：

• 新增字段简单，无需像关系型数据库一样先执行 DDL 语句修改表结构，程序代码直接读写即可。
• 容易兼容历史数据，对于历史数据，即使没有新增的字段，也不会导致错误，只会返回空值，此时代码兼容处理即可。
• 容易存储复杂数据，JSON 是一种强大的描述语言，能够描述复杂的数据结构。

相比传统关系型数据库，文档数据库的缺点主要是对多条数据记录的事务支持较弱，具体体现如下：

• Atomicity(原子性)，仅支持单行/文档级原子性，不支持多行、多文档、多语句原子性。
• Solation(隔离性)，隔离级别仅支持已提交读（Read committed）级别，可能导致不可重复读，幻读的问题。
• 不支持复杂查询，例如 join 查询，如果需要 join 查询，需要多次操作数据库。

MongonDB 还支持多文档事务的 Consistency(一致性)和 Durability(持久性)，虽然官方宣布 MongoDB 将在 4.0 版本中正式推出多文档 ACID 事务支持，最后落地情况还有待见证。

使用场景

适用场景：

• 数据量很大或者未来会变得很大。
• 表结构不明确，且字段在不断增加，例如内容管理系统，信息管理系统。

不适用场景：

• 在不同的文档上需要添加事务。Document-Oriented 数据库并不支持文档间的事务。
• 多个文档之间需要复杂查询，例如 join。

全文搜索引擎

传统关系型数据库主要通过索引来达到快速查询的目的，在全文搜索的业务下，索引也无能为力，主要体现在：

• 全文搜索的条件可以随意排列组合，如果通过索引来满足，则索引的数量非常多。
• 全文搜索的模糊匹配方式，索引无法满足，只能用 like 查询，而 like 查询是整表扫描，效率非常低。

而全文搜索引擎的出现，正是解决关系型数据库全文搜索功能较弱的问题。

基本原理

全文搜索引擎的技术原理称为“倒排索引”（inverted index），是一种索引方法，其基本原理是建立单词到文档的索引。与之相对的是“正排索引”，其基本原理是建立文档到单词的索引。

现在有如下文档集合：

正排索引得到索引如下：

由上可见，正排索引适用于根据文档名称查询文档内容。简单的倒排索引如下：

带有单词频率信息的倒排索引如下：

由上可见，倒排索引适用于根据关键词来查询文档内容。

常见全文搜索引擎

Elasticsearch：是一个基于 Lucene 的搜索引擎。它提供了一个分布式，多租户，能够全文搜索与发动机 HTTP Web 界面和无架构 JSON 文件。

Elasticsearch 是用 Java 开发的，并根据 Apache License 的条款作为开源发布。

根据 DB-Engines 排名，Elasticsearch 是最受欢迎的企业搜索引擎，后面是基于 Lucene 的 Apache Solr。

Solr：是 Apache Lucene 项目的开源企业搜索平台。其主要功能包括全文检索、命中标示、分面搜索、动态聚类、数据库集成，以及富文本（如 Word、PDF）的处理。Solr 是高度可扩展的，并提供了分布式搜索和索引复制。

相关特性

以 Elasticsearch 为例，全文搜索引擎优点如下：

• 查询效率高，对海量数据进行近实时的处理。
• 可扩展性，基于集群环境可以方便横向扩展，可以承载 PB 级数据。
• 高可用，Elasticsearch 集群弹性，他们将发现新的或失败的节点，重组和重新平衡数据，确保数据是安全的和可访问的。

缺点如下：

• ACID 支持不足，单一文档的数据是 ACID 的，包含多个文档的事务时不支持事务的正常回滚，支持 I(Isolation)隔离性（基于乐观锁机制的），D(Durability)持久性，不支持 A(Atomicity)原子性，C(Consistency)一致性。
• 对类似数据库中通过外键的复杂的多表关联操作支持较弱。
• 读写有一定延时，写入的数据，最快 1s 中能被检索到。
• 更新性能较低，底层实现是先删数据，再插入新数据。
• 内存占用大，因为 Lucene 将索引部分加载到内存中。

使用场景

适用场景如下：

• 分布式的搜索引擎和数据分析引擎。
• 全文检索，结构化检索，数据分析。
• 对海量数据进行近实时的处理，可以将海量数据分散到多台服务器上去存储和检索。

不适用场景如下：

• 数据需要频繁更新。
• 需要复杂关联查询。

图形数据库

图形数据库应用图形理论存储实体之间的关系信息。最常见例子就是社会网络中人与人之间的关系。

关系型数据库用于存储“关系型”数据的效果并不好，其查询复杂、缓慢、超出预期。

而图形数据库的独特设计恰恰弥补了这个缺陷，解决关系型数据库存储和处理复杂关系型数据功能较弱的问题。

常见图形数据库

Neo4j：是由 Neo4j，Inc. 开发的图形数据库管理系统。由其开发人员描述为具有原生图存储和处理的符合 ACID 的事务数据库，根据 DB-Engines 排名，Neo4j 是最流行的图形数据库。

ArangoDB：是由 triAGENS GmbH 开发的原生多模型数据库系统。数据库系统支持三个重要的数据模型（键/值，文档，图形），其中包含一个数据库核心和统一查询语言 AQL（ArangoDB 查询语言）。

查询语言是声明性的，允许在单个查询中组合不同的数据访问模式。ArangoDB 是一个 NoSQL 数据库系统，但 AQL 在很多方面与 SQL 类似。

Titan：是一个可扩展的图形数据库，针对存储和查询包含分布在多机群集中的数百亿个顶点和边缘的图形进行了优化。

Titan 是一个事务性数据库，可以支持数千个并发用户实时执行复杂的图形遍历。

相关特性

以 Neo4j 为例，Neo4j 使用数据结构中图（graph）的概念来进行建模。Neo4j 中两个最基本的概念是节点和边。

节点表示实体，边则表示实体之间的关系。节点和边都可以有自己的属性。不同实体通过各种不同的关系关联起来，形成复杂的对象图。

针对关系数据，两种数据库的存储结构不同：

Neo4j 中，存储节点时使用了“index-free adjacency”，即每个节点都有指向其邻居节点的指针，可以让我们在 O(1) 的时间内找到邻居节点。

另外，按照官方的说法，在 Neo4j 中边是最重要的，即“first-class entities”，所以单独存储，这有利于在图遍历的时候提高速度，也可以很方便地以任何方向进行遍历。

优点如下：

• 高性能表现，图的遍历是图数据结构所具有的独特算法，即从一个节点开始，根据其连接的关系，可以快速和方便地找出它的邻近节点。

这种查找数据的方法并不受数据量的大小所影响，因为邻近查询始终查找的是有限的局部数据，不会对整个数据库进行搜索。

• 设计的灵活性，数据结构的自然伸展特性及其非结构化的数据格式，让图数据库设计可以具有很大的伸缩性和灵活性。

因为随着需求的变化而增加的节点、关系及其属性并不会影响到原来数据的正常使用。

• 开发的敏捷性，直观明了的数据模型，从需求的讨论开始，到程序开发和实现，以及最终保存在数据库中的样子，它的模样似乎没有什么变化，甚至可以说本来就是一模一样的。
• 完全支持 ACID，不像别的 NoSQL 数据库，Neo4j 还具有完全事务管理特性，完全支持 ACID 事务管理。

缺点如下：

• 具有支持节点，关系和属性的数量的限制。
• 不支持拆分。

使用场景

适用场景如下：

• 在一些关系性强的数据中，例如社交网络。
• 推荐引擎。如果我们将数据以图的形式表现，那么将会非常有益于推荐的制定。

不适用场景如下：

• 记录大量基于事件的数据（例如日志条目或传感器数据）。
• 对大规模分布式数据进行处理，类似于 Hadoop。
• 适合于保存在关系型数据库中的结构化数据。
• 二进制数据存储。

总结

关系型数据库和 NoSQL 数据库的选型，往往需要考虑几个指标：

• 数据量
• 并发量
• 实时性
• 一致性要求
• 读写分布和类型
• 安全性
• 运维成本

常见软件系统数据库选型参考如下：

• 内部使用的管理型系统，如运营系统，数据量少，并发量小，首选考虑关系型。
• 大流量系统，如电商单品页，后台考虑选关系型，前台考虑选内存型。
• 日志型系统，原始数据考虑选列式，日志搜索考虑选倒排索引。
• 搜索型系统，例如站内搜索，非通用搜索，如商品搜索，后台考虑选关系型，前台考虑选倒排索引。
• 事务型系统，如库存，交易，记账，考虑选关系型+缓存+一致性型协议。
• 离线计算，如大量数据分析，考虑选列式或者关系型也可以。
• 实时计算，如实时监控，可以考虑选内存型或者列式数据库。

在设计实践中，我们要基于需求、业务驱动架构，无论选用 RDB/NoSQL/DRDB，一定是以需求为导向，最终数据存储方案必然是各种权衡的综合性设计。

参考资料：

• 从0开始学架构 —— Alibaba 李运华
• NoSQL漫谈
• 图形数据库 Neo4j 开发实战
• 大数据时代的 9 大Key-Value存储数据库
• 事务—— Redis官方文档
• MongoDB是如何实现事务的ACID？
• MySQL脏读、虚读、幻读
• 全面梳理关系型数据库和 NoSQL 的使用情景
• 浅析列式数据库的特点
• 一分钟搞懂列式与行式数据库
• HBase 基本概念
• NoSQL Databases, why we should use, and which one we should choose
• 传统关系数据库与分布式数据库知识点

==============================

1NoSQL的诞生原因

 

随着互联网快速发展，各种类型的应用层出不穷，所以导致在这个云计算的时代，对技术提出了更多的需求，主要体现在下面这四个方面：

1. 低延迟的读写速度：应用快速地反应能极大地提升用户的满意度;

   原因：当数据量达到一定规模时，由于关系型数据库的系统逻辑非常复杂，使得其非常容易发生死锁等的并发问题，所以导致其读写速度下滑非常严重;

2. 支撑海量的数据和流量：对于搜索这样大型应用而言，需要利用PB级别的数据和能应对百万级的流量;

   原因：有限的支撑容量：现有关系型解决方案还无法支撑Google这样海量的数据存储

3. 大规模集群的管理：系统管理员希望分布式应用能更简单的部署和管理;

   原因：由于存在类似Join这样多表查询机制，使得数据库在扩展方面很艰难;

4. 庞大运营成本的考量：IT经理们希望在硬件成本、软件成本和人力成本能够有大幅度地降低;

   原因：企业级数据库的License价格很惊人，并且随着系统的规模，而不断上升;

业界为了解决上面提到的几个需求，推出了多款新类型的数据库，并且由于它们在设计上和传统的NoSQL数据库相比有很大的不同，所以被统称为 “NoSQL”系列数据库。总的来说，在设计上，它们非常关注对数据高并发地读写和对海量数据的存储等，与关系型数据库相比，它们在架构和数据模型方量面 做了“减法”，而在扩展和并发等方面做了“加法”。现在主流的NoSQL数据库有BigTable、HBase、Cassandra、SimpleDB、 CouchDB、MongoDB和Redis等

 

 

2为何要使用NoSQL数据库？

 

1. NoSQL具有灵活的数据模型，可以处理非结构化/半结构化的大数据

   现在，我们可以通过Facebook、D&B等第三方轻松获得与访问数据，如个人用户信息、地理位置数据、社交图谱、用户产生的内容、机器日志数 据以及传感器生成的数据等。对这些数据的使用正在快速改变着通信、购物、广告、娱乐以及关系管理的特质。没有使用这些数据的应用很快就会被用户所遗忘。开 发者希望使用非常灵活的数据库，能够轻松容纳新的数据类型，并且不会被第三方数据提供商内容结构的变化所累。很多新数据都是非结构化或是半结构化的，因此开发者还需要能够高效存储这种数据的数据库。但遗憾的是，关系型数据库所使用的定义严格、基于模式的方式是无法快速容纳新的数据类型的，对于非结构化或是 半结构化的数据更是无能为力。NoSQL提供的数据模型则能很好地满足这种需求。很多应用都会从这种非结构化数据模型中获益，比如说CRM、ERP、 BPM等等，他们可以通过这种灵活性存储数据而无需修改表或是创建更多的列。这些数据库也非常适合于创建原型或是快速应用，因为这种灵活性使得新特性的开 发变得非常容易。

2. NoSQL很容易实现可伸缩性（向上扩展与水平扩展）

   如果有很多用户在频繁且并发地使用你的应用，那么你就需要考虑可伸缩的数据库技术而非传统的RDBMS了。对于关系型技术来说，很多应用开发者会发现动态 的可伸缩性是难以实现的，这时就应该考虑切换到NoSQL数据库上。对于云应用来说，关系型数据库一开始是普遍的选择。然而，在使用过程中却遇到了越来越 多的问题，原因就在于他们是中心化的，向上扩展而非水平扩展的。这使得他们不适合于那些需要简单且动态可伸缩性的应用。NoSQL数据库从一开始就是分布 式、水平扩展的，因此非常适合于互联网应用分布式的特性。

   在三层互联网架构的Web/应用层上，多年来向上扩展已经成为默认的扩展方式了。随着应用使用人数的激增，我们需要添加更多的服务器，性能则是通过负载均 衡来实现的，这时的代价与用户数量成线性比例关系。在NoSQL数据库之前，数据库层的默认扩展方式就是向上扩展。为了支持更多的并发用户以及存储更多的 数据，你需要越来越好的服务器，更好的CPU、更多的内存、更大的磁盘来维护所有表。然而，好的服务器意味着更加复杂、私有、并且也更加昂贵。这与 Web/应用层所使用的便宜的硬件形成了鲜明的对比。

3. 动态模式

   关系型数据库需要在添加数据前先定义好模式。比如说，你需要存储客户的电话号码、姓名、地址、城市与州等信息，SQL数据库需要提前知晓你要存的是什么。 这对于敏捷开发模式来说是场灾难，因为每次完成新特性时，数据库的模式通常都需要改变。因此，如果在开发过程中想将客户喜欢的条目加到数据库中，那就得向 表中添加这一列才行，然后要做的就是将整个数据库迁移到新的模式上。

4. 自动分片

   由于是结构化的，关系型数据库通常会垂直扩展，单台服务器要持有整个数据库来确保可靠性与数据的持续可用性。这样做的代价就是非常昂贵、扩展受到限制，并 且数据库基础设施会成为失败点。这个问题的解决方案就是水平扩展，添加服务器而不是为单台服务器增加更多的能力。NoSQL数据库通常都支持自动分片，这 意味着他们本质上就会自动在多台服务器上分发数据，应用甚至都不知道这些事情。数据与查询负载会自动在多台服务器上做到平衡，当某台服务器当机时，它能快 速且透明地被替换掉。

5. 复制

   大多数NoSQL数据库也支持自动复制，这意味着你可以获得高可用性与灾备恢复功能。从开发者的角度来看，存储环境本质上是虚拟化的。

 

 

 

3NoSQL优缺点

 

在优势方面，主要体现在下面这三点： 

1. 简单的扩展：典型例子是Cassandra，由于其架构是类似于经典的P2P，所以能通过轻松地添加新的节点来扩展这个集群; 

2. 快速的读写：主要例子有Redis，由于其逻辑简单，而且纯内存操作，使得其性能非常出色，单节点每秒可以处理超过10万次读写操作; 

3. 低廉的成本：这是大多数分布式数据库共有的特点，因为主要都是开源软件，没有昂贵的License成本; 

 

但瑕不掩瑜，NoSQL数据库还存在着很多的不足，常见主要有下面这几个： 

1. 不提供对SQL的支持：如果不支持SQL这样的工业标准，将会对用户产生一定的学习和应用迁移成本; 

2. 支持的特性不够丰富：现有产品所提供的功能都比较有限，大多数NoSQL数据库都不支持事务，也不像MS SQL Server和Oracle那样能提供各种附加功能，比如BI和报表等; 

3. 现有产品的不够成熟：大多数产品都还处于初创期，和关系型数据库几十年的完善不可同日而语; 

    

上面NoSQL产品的优缺点都是些比较共通的，在实际情况下，每个产品都会根据自己所遵从的数据模型和CAP理念而有所不同。

 

 

4适合场景

 

NoSQL数据库正在成为数据库领域的重要力量。如果使用恰当，那么它会带来很多好处。然而，企业应该非常小心并注意到这些数据库的限制与问题。

NoSQL这两年越来越热，尤其是大型互联网公司非常热衷这门技术。根据笔者的经验，并不是任何场景，NoSQL都要优于关系型数据库。下面我们来具体聊聊，什么时候使用NoSQL比较给力：

1) 数据库表schema经常变化 

比如在线商城，维护产品的属性经常要增加字段，这就意味着ORMapping层的代码和配置要改，如果该表的数据量过百万，新增字段会带来额外开销（重建索引等）。NoSQL应用在这种场景，可以极大提升DB的可伸缩性，开发人员可以将更多的精力放在业务层。

2)数据库表字段是复杂数据类型

对于复杂数据类型，比如SQL Sever提供了可扩展性的支持，像xml类型的字段。很多用过的同学应该知道，该字段不管是查询还是更改，效率非常一般。主要原因是是DB层对xml字 段很难建高效索引，应用层又要做从字符流到dom的解析转换。NoSQL以json方式存储，提供了原生态的支持，在效率方便远远高于传统关系型数据库。

3)高并发数据库请求

此类应用常见于web2.0的网站，很多应用对于数据一致性要求很低，而关系型数据库的事务以及大表join反而成了”性能杀手”。在高并发情况 下，sql与no-sql的性能对比由于环境和角度不同一直是存在争议的，并不是说在任何场景，no-sql总是会比sql快。有篇article和大家 分享下，http://artur.ejsmont.org/blog/content/insert-performance-comparison-of-nosql-vs-sql-servers

4)海量数据的分布式存储

海量数据的存储如果选用大型商用数据，如Oracle，那么整个解决方案的成本是非常高的，要花很多钱在软硬件上。NoSQL分布式存储，可以部署在廉价的硬件上，是一个性价比非常高的解决方案。Mongo的auto-sharding已经运用到了生产环境。http://www.mongodb.org/display/DOCS/Sharding

并不是说NoSQL可以解决一切问题，像ERP系统、BI系统，在大部分情况还是推荐使用传统关系型数据库。主要的原因是此类系统的业务模型复杂，使用NoSQL将导致系统的维护成本增加。

 

5选择SQL还是NoSQL

 

上面说明了为什么要使用NoSQL。接下来我们看下如何把NoSQL引入到我们的项目中，我们到底要不要把NoSQL引入到项目中。

在过去，我们只需要学习和使用一种数据库技术，就能做几乎所有的数据库应用开发。因为成熟稳定的关系数据库产品并不是很多，而供你选择的免费版本就 更加少了，所以互联网领域基本上都选择了免费的MySQL数据库。在高速发展的WEB2.0时代，我们发现关系数据库在性能、扩展性、数据的快速备份和恢 复、满足需求的易用性上并不总是能很好的满足我们的需要，我们越来越趋向于根据业务场景选择合适的数据库，以及进行多种数据库的融合运用。几年前的一篇文 章《One Size Fits All - An Idea Whose Time Has Come and Gone》就已经阐述了这个观点。

当我们在讨论是否要使用NoSQL的时候，你还需要理解NoSQL也是分很多种类的，在NoSQL百花齐放的今天，NoSQL的正确选择比选择关系数据库还具有挑战性。虽然NoSQL的使用很简单，但是选择却是个麻烦事，这也正是很多人在观望的一个原因。

6NoSQL的分类

 

NoSQL仅仅是一个概念，NoSQL数据库根据数据的存储模型和特点分为很多种类。 

以上NoSQL数据库类型的划分并不是绝对，只是从存储模型上来进行的大体划分。它们之间没有绝对的分界，也有交差的情况，比如Tokyo Cabinet / Tyrant的Table类型存储，就可以理解为是文档型存储，Berkeley DB XML数据库是基于Berkeley DB之上开发的。

 

7选择和使用建议

虽然09年出现了比较激进的文章《关系数据库已死》，但是我们心里都清楚，关系数据库其实还活得好好的，你还不能不用关系数据库。但是也说明了一个事实，关系数据库在处理WEB2.0数据的时候，的确已经出现了瓶颈。

那么我们到底是用NoSQL还是关系数据库呢？我想我们没有必要来进行一个绝对的回答。我们需要根据我们的应用场景来决定我们到底用什么。

如果关系数据库在你的应用场景中，完全能够很好的工作，而你又是非常善于使用和维护关系数据库的，那么我觉得你完全没有必要迁移到NoSQL上面， 除非你是个喜欢折腾的人。如果你是在金融，电信等以数据为王的关键领域，目前使用的是Oracle数据库来提供高可靠性的，除非遇到特别大的瓶颈，不然也 别贸然尝试NoSQL。

然而，在WEB2.0的网站中，关系数据库大部分都出现了瓶颈。在磁盘IO、数据库可扩展上都花费了开发人员相当多的精力来优化，比如做分表分库 （database sharding）、主从复制、异构复制等等，然而，这些工作需要的技术能力越来越高，也越来越具有挑战性。如果你正在经历这些场合，那么我觉得你应该尝 试一下NoSQL了。

一、选择合适的NoSQL 

如此多类型的NoSQL，而每种类型的NoSQL又有很多，到底选择什么类型的NoSQL来作为我们的存储呢？这并不是一个很好回答的问题，影响我们选择 的因素有很多，而选择也可能有多种，随着业务场景，需求的变更可能选择又会变化。我们常常需要根据如下情况考虑：

1.数据结构特点。包括结构化、半结构化、字段是否可能变更、是否有大文本字段、数据字段是否可能变化。

2.写入特点。包括insert比例、update比例、是否经常更新数据的某一个小字段、原子更新需求。

3.查询特点。包括查询的条件、查询热点的范围。比如用户信息的查询，可能就是随机的，而新闻的查询就是按照时间，越新的越频繁。

二、NoSQL和关系数据库结合 

其实NoSQL数据库仅仅是关系数据库在某些方面（性能，扩展）的一个弥补，单从功能上讲，NoSQL的几乎所有的功能，在关系数据库上都能够满足，所以选择NoSQL的原因并不在功能上。

所以，我们一般会把NoSQL和关系数据库进行结合使用，各取所长，需要使用关系特性的时候我们使用关系数据库，需要使用NoSQL特性的时候我们使用NoSQL数据库，各得其所。

举个简单的例子吧，比如用户评论的存储，评论大概有主键id、评论的对象aid、评论内容content、用户uid等字段。我们能确定的是评论内 容content肯定不会在数据库中用where content=’’查询，评论内容也是一个大文本字段。那么我们可以把 主键id、评论对象aid、用户id存储在数据库，评论内容存储在NoSQL，这样数据库就节省了存储content占用的磁盘空间，从而节省大量IO， 对content也更容易做Cache。

//从MySQL中查询出评论主键id列表 commentIds=DB.query(“SELECT id FROM comments where aid=’评论对象id’ LIMIT 0,20”); //根据主键id列表，从NoSQL取回评论实体数据 CommentsList=NoSQL.get(commentIds);NoSQL代替MySQL 

在某些应用场合，比如一些配置的关系键值映射存储、用户名和密码的存储、Session会话存储等等，用NoSQL完全可以替代MySQL存储。不但具有更高的性能，而且开发也更加方便。

三、NoSQL作为缓存服务器 

MySQL+Memcached的架构中，我们处处都要精心设计我们的缓存，包括过期时间的设计、缓存的实时性设计、缓存内存大小评估、缓存命中率等等。

NoSQL数据库一般都具有非常高的性能，在大多数场景下面，你不必再考虑在代码层为NoSQL构建一层Memcached缓存。NoSQL数据本身在Cache上已经做了相当多的优化工作。

Memcached这类内存缓存服务器缓存的数据大小受限于内存大小，如果用NoSQL来代替Memcached来缓存数据库的话，就可以不再受限于内存大小。虽然可能有少量的磁盘IO读写，可能比Memcached慢一点，但是完全可以用来缓存数据库的查询操作。