NoSQL 数据库杂谈—理论篇

Tony Denghttp://twitter.com/wolfdeng

http://friendfeed.com/tonydenghttp://delicious.com/wolf.denghttp://wolfchina.blogbus.com

• NoSQL 概念介绍

• NoSQL 的理论基础

• 为什么要用 NoSQL 数据库

• NoSQL 数据库分类

NoSQL 概念介绍

什么是 NoSQL

• 一般的解释– Not only SQL, 不限于 SQL ，是一类范围非常广泛的数据持久化解决方案，它们

不遵循关系数据库模型，也不使用 SQL 作为查询语言。

• 更加正确的解释– NoREL -- http://en.wikipedia.org/wiki/Nosql– NoSQL 的重点是 non-relational ，而传统的数据库是 relational

• 1998 年开始的一个由 Carlo Strozzi 发起的一项运动，这项运动的主旨就是“要找到存储和检索数据的其他高效的途径，而不是盲目地在任何情况下都把关系数据库当作万金油”

• 非关系型数据库我们基本上都认为它是 NoSQL 数据库。

• http://nosql-database.org/

为什么要用 NoSQL 数据库

传统关系型数据库的缺陷

• 最大的缺陷就是扩展性– 虽然各个数据库厂商都有 cluster 的解决方案，但是不管 share

storage 或 share nothing 的解决方案，扩展性都是很有限的。• 目前解决数据库扩展性的思路主要有两个

– 水平分区（数据分片 sharing ）或垂直分区（功能业务分区）• 这样虽然可以很好解决数据库的扩展性问题，但是在实际使用中，一旦采用

了数据分片或者功能分区，必然导致牺牲“关系型”数据库的最大优势 -join ，对业务的局限性会很大，而且数据库也退化成为一个简单的存储系统。

– Master-Slave 复制方式• 通过读写分离在某种程度上解决扩展性的问题，但是这种方案中，由于每个

数据库节点必须保存所有的数据，这样每个存储的 IO 必然会成为扩展的瓶颈，并且 master 也是一个瓶颈

• 总的来说，传统的关系型数据库的扩展能力都是十分有限的。

NoSQL 是否会取代关系型数据库

• 应用场景– 其实， NoSQL 的数据库使用场景比较特殊– NoSQL 无法做到通用– NoSQL 对于很多人来说是此之蜜糖，彼之砒霜

• 使用习惯– 更多的技术人员更习惯使用关系型数据库– 关系型数据库也能够伪装成非关系型数据库

NoSQL 理论基础

一切的源头

• CAP ， BASE 和最终一致性是 NoSQL 数据库存在的三大基石。

• 而五分钟法则是内存数据存储了理论依据。这个是一切的源头。

CAP

C: Consistency  一致性：任何一个读操作总是能够读取之前完成的写操作

A: Availability  可用性 ( 指的是快速获取数据 )每一次操作总是能够在确定的时间返回

P: Tolerance of network Partition  分区容忍性 ( 分布式 ) 在出现网络分区的情况下，仍然能够满足一致性和可用性。

取舍• 10年前，Eric Brewer教授指出了著名的CAP理论，后来Seth Gilbert 和 Nancy lynch两人证明了CAP理论的

正确性。

• CAP理论告诉我们:一个分布式系统不可能满足一致性，可用性和分区容错性这三个需求，最多只能同时满足两个。

• 熊掌与鱼不可兼得也。关注的是一致性，那么您就需要处理因为系统不可用而导致的写操作失败的情况，而如果您关注的是可用性，那么您应该知道系统的read操 作可能不能精确的读取到write操作写入的最新值。

• 因此系统的关注点不同，相应的采用的策略也是不一样的，只有真正的理解了系统的需求，才有可能利用好 CAP理论。 – CA：传统关系数据库 – AP：key-value数据库

• 而对大型网站，可用性与分区容忍性优先级要高于数据一致性，一般会尽量朝着 A、P 的方向设计，然后通过其它手段保证对于一致性的商务需求。架构设计师不要精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍。

• 不同数据对于一致性的要求是不同的。举例来讲，用户评论对不一致是不敏感的，可以容忍相对较长时间的不一致，这种不一致并不会影响交易和用户体验。而产品价格数据则是非常敏感的，通常不能容忍超过10秒的价格不一致。

• CAP理论的证明：Brewer‘s CAP Theorem

一致性

• 强一致性– ACID– 在单机环境中，强一致性可以由数据库的事务来保证。– 在多机环境中，强一致性很难做到。

• 分布式事务：性能太差，在互联网的应用中不适合

• 弱一致性（包括最终一致性）– 通过提交处理的半同步、半异步或全异步，取得最终一致性效果。– 最终一致性使得数据的提交具有延时性，而在一定范围的延时性范围内（比如一秒），应用的可用性是 OK 的

• 一言以蔽之：过程松，结果紧，最终结果必须保证一致性

• http://www.allthingsdistributed.com/2008/12/eventually_consistent.html

一致性的场景描述

• 为了更好的描述客户端一致性，我们通过以下的场景来进行，这个场景包括三个组成部分：– 存储系统

• 存储系统可以理解为一个黑盒子，它为我们提供了可用性和持久性的保证

– ProcessA• ProcessA 主要实现从存储系统 write 和 read 操作

– ProcessB 和 ProcessC• ProcessB 和 C 是独立于 A ，并且 B 和 C 也相互独立，它们同时也实现对存储系统的 write 和 read 操作

不同程度的一致性处理方式• 强一致性

– 强一致性（即时一致性）假如A先写入一个值到存储系统，存储系统保证后续的 A,B,C 的读操作都返回最新值

• 弱一致性– 假如A先写入了一个值到存储系统，存储系统不能保证后续A,B,C 的读取操作能够读到最新值。– 这种情况下有一个“不一致性窗口”的概念，它特指从A 写入值，到后续操作 A,B,C 读取到最新值这一段时间。

• 最终一致性– 最终一致性是弱一致性的一种特例– 假如A首先write 了一个值到存储系统，存储系统保证如果在 A,B,C后续读取之前没有其他写操作

更新同样的值的话，最终所有的读取操作都会读取到 A 写入的最新的值。– 这种情况下，如果没有失败发生的话，“不一致性窗口”的大小依赖以下的几个因素：

• 交互延迟• 系统的负载• 复制架构中 replica 的个数（可以理解为master/slave 模式中，slave 的个数）

• 在最终一致性方面最出名的应该是DNS系统– 但更新一个域名的 IP 以后，根据配置策略以及缓存控制策略的不同，最终所有的客户都可以看到

最新的域名和 IP 的映射

其他一致性变体的处理方式

• Causal consistency(因果一致性 )– 如果Process A 通知Process B 它已经更新了数据，那么 Process B 的后续读

取操作则读取 A 写入的最新值，而与A没有因果关系的 C 则可以最终一致性。 • Read-your-writes consistency( 过程一致性 )

– 如果Process A 写入了最新的值，那么 Process A 的后续操作都会读取到最新值。但是其它用户可能要过一会才可以看到。

• Session consistency( 会话一致性 )– 此种一致性要求客户端和存储系统交互的整个会话阶段保证Read-your-writes

consistency– Hibernate 的 session提供的一致性保证就属于此种一致性。

• Monotonic read consistency( 简单读一致性 )– 此种一致性要求如果Process A已经读取了对象的某个值，那么后续操作将不

会读取到更早的值。 • Monotonic write consistency( 简单写一致性 )

– 此种一致性保证系统会序列化执行一个 Process 中的所有写操作。

服务器一致性• 概念

– N ：节点的个数– W ：更新的时候需要确认已经被更新的节点个数– R ：读数据的时候读取数据的节点个数

• 如果W+R>N ，那么分布式系统就会提供强一致性的保证，因为读取数据节点和被写入的节点是有重叠的。

• 在一个 RDBMS 的复制模型中 (Master/Slave) ，假如N=2 ，那么 W=2 ， R=1 ，此时是一种强一致性，但是这样造成的问题就是可用性的减低，因为要想写操作成功，必须要等2 个节点都完成以后才可以。

• 在分布式系统中，一般都要有容错性，因此一般 N 都大于 3 的，此时根据 CAP理论，一致性，可用性和分区容错性最多只能满足两个，那么我们就需要在一致性和分区容错性之间做一个平衡。– 如果要高的一致性，那么就配置为 N=W ， R=1 ，这个时候可用性就会大大降低– 如果想要高的可用性，那么此时就需要放松一致性的要求，此时可以配置W=1 ，这样使得写

操作延迟最低，同时通过异步的机制剩余的 N-W 个节点

服务器一致性

• 当存储系统保证最终一致性时，存储系统的配置一般是W+R<=N ，此时读取和写入操作是不重叠的。

• 不一致窗口就依赖存储系统的异步实现方式，不一致窗口大小也就等于从更新开始到所有节点都异步更新完成之间的时间

• N,R,W 的例子– (N,R,W) 的值典型设置为 (3, 2 ,2),兼顾性能与可用性– W = 1, R = N, 对写操作要求高性能高可用。– R = 1, W = N , 对读操作要求高性能高可用，比如类似 cache 之

类业务。– W = Q, R = Q where Q = N / 2 + 1 一般应用适用，读写性能之

间取得平衡。如N=3,W=2,R=2

BASE

• BASE （ Basically Available,Soft state,Eventually consistent ）是对 CAP 中的 AP 的衍生– 在单机环境中， ACID 是数据的属性– 而在分布式环境中， BASE 就是数据的属性

• BASE 模型完全不同于 ACID 模型，它通过牺牲高一致性，获得可用性和可靠性（容错性）

• BASE 思想主要实现有– 按功能划分数据库– Sharing

• BASE 思想主要强调基本的可用性，如果你需要高可用性，也就是纯粹的高性能，那么就要以一致性或容错性为牺牲， BASE 思想的方案在性能上还是有潜力可挖的。

五分钟法则

• http://queue.acm.org/detail.cfm?id=1413264• http://developers.solidot.org/article.pl?sid=09/07/06/052210• 1987 年发表的这个“五分钟法则”

– 评估了在内存中保留数据和在硬盘上储存数据之间的利益权衡：如果数据被频繁访问，那么它应该放在内存里；否则就储存在硬盘内，其临界点便是五分钟——在内存中保持 1KB 的数据成本相当于硬盘中存储同样大小数据 400秒的开销

• 随着闪存时代的来临，五分钟法则一分为二：是把 SSD 当成较慢的内存（ extended buffer pool ）使用还是当成较快的硬盘（ extended disk ）使用。小内存页在内存和闪存之间的移动对比大内存页在闪存和磁盘之间的移动。在这个法则首次提出的 20 年之后，在闪存时代， 5 分钟法则依然有效，只不过适合更大的内存页(适合 64KB 的页，这个页大小的变化恰恰体现了计算机硬件工艺的发展，以及带宽、延时 ) 。

一致性哈希 Consistent Hash我们把每台 server 分成 v 个虚拟节点，再把所有虚拟节点 (n*v)随机分配到一致性哈希的圆环上，这样所有的用户从自己圆环上的位置顺时针往下取到第一个 vnode就是自己所属节点。当此节点存在故障时，再顺时针取下一个作为替代节点。

优点：发生单点故障时负载会均衡分散到其他所有节点，程序实现也比较优雅。

NoSQL 数据库分类

NoSQL 数据库分类• 一般来说，基本上分为以下几种：

– Key/Value Stores （键 /值存储库）• Amazon SimpleDB

– http://aws.amazon.com/simpledb/• Berkeley DB

– http://www.oracle.com/database/berkeley-db/db/index.html• MemcacheDB

– http://memcachedb.org/• Redis

– http://code.google.com/p/redis/

– Document Stores （文档库）• CouchDB

– http://couchdb.apache.org/• MongoDB

– http://www.mongodb.org/

– Graph Database （图形数据库）• Neo4j

– http://www.neo4j.org/

– Wide Column Stores （列存储库）• Hadoop

– http://hadoop.apache.org/• Cassandra

– http://incubator.apache.org/cassandra/

NoSQL 的整体架构

接口层（ Interfaces ）

• 这层的主要作用是为上层应用提供合适和方便的数据调用接口，而且提供的选择远多于传统的关系型数据库，主要有六大类接口：– 其一是常见的 REST （ Representational State Transfer ），采用

REST 的产品有 HBase 和 CouchDB等。– 其二是源自 Facebook 的 RPC协议 Thrift ，支持 Thrift 的产品 有

HBase 和 Cassandra等。– 其三是用于大规模数据处理的 Map Reduce ，其相关产品有 HBase ，

CouchDB 和 MongoDB等。– 其四是类似于 Memcached 的 Get/Put 方式，采用 Get/Put 的 产品有

Voldemort等。– 其五是提供语言特定（ Language Specific ）的 API ，比如 Java ，在

这方面做的不错是 MongoDB 。– 最后一个是提供SQL 的子集，虽然“ Join” 在 NoSQL属于禁忌，但 是提供一个 SQL 的基本子集来方便用户也是一个不错的想法。

数据逻辑模型层（ Logical Data Model ）

• 这层的主要作用是描述数据的逻辑表现形式，而且与关系型数据库相比 NoSQL 在逻辑表现形式方面相当灵活，主要有四种形式：– 最普通的 Key- Value形式，这种形式在表现形式是比较单一，但是在

扩展方面很有优势，采用 Key-Value形式产品的有 Voldemort等。– 列式 （ Column Family ），这种形式与Key-Value相比其能支持更

复杂的数据，但是在扩展方面稍逊一筹，其相关产品有BigTable ， HBase 和 Cassnadra等。

– 文档（ Doucument ）形式，文档形式源自于著名协作软件 Lotus Notes ，并且本质上与Key-Value形式非常相似，主要区别在于是那个Value只能存储文档形式的数据，同时文档形式在对复杂数据的支持和扩展 这两方面表现都还可以，采用文档形式的产品有 Couch DB 和MongoDB等。

– 图（ Graph ）式，图式的使用场景不是很广，主要是为基于图数据结构的数据“度身定做”的，比如SNS 应用中的关系等，其最知名的产品就是 Neo4j 。

数据分布层（ Data Distribution Model ）

• 这层的主要作用是定义了数据是如何分布的，和关系型数据库不同的是 NoSQL 数据库可选择的机制比较多，主要有三种：– 其一是用于水平扩展的 CAP机制，支 持 CAP 的产品

有 HBase ， MongoDB 和 Cassandra等。– 其二是对多数据中心的支持，通过这个机制能够保证横跨多数据中心的 NoSQL 数据库 能非常平稳地运行，相关的产品有 Cassandra等。

– 其三是支持动态部署，也就是能在一个生产集群中能动态并且平滑地添加或者删去一个节点

数据持久层（ Data Persistence ）

• 这层主要作用是定义了数据的存储形式，主要有四种形式：– 基于内存形式，这种形式速度最快，但是存在丢失数据的可

能性，采 用内存的有 Redis等。– 基于硬盘形式，这种形式，在数据耐久性方面表现不错，但

是在速度方面远不如基于内存的，其相关产品有 MongoDB等。

– 基于 内存和硬盘的形式，因为这种形式主要结合前面两者的优点，所以其在速度上表现不错，同时数据也不会丢失，而且常被认为是最合适的方案，采用这种形式的产品 有 HBase和 Cassandra等。

– 定制可插拔（ Custom Pluggable ）形式，这种形式以灵活著称

注意

• 虽然分四层，但并不意味着每个产品只能在每一层选择一个特性，而是可以选择多个特性。– 比如，在接口层 HBase支持 REST ， Thrift 和 Map

Reduce 这三种接口，而在数据分布层， Cassandra即支持 CAP ，又对多数据中心有所支撑。

谢谢