CouchDB 实现原理

特性

RESTFul API
基于文档存储，无表固定结构，数据之间没有关系范式要求
多版本并发控制模型
用户自定义查询结构(map/reduce)
增量索引更新机制
多master复制模式
用Erlang编写

CouchDB能够适应非常广泛的应用场景，在某些偶尔连接网络的应用中，我们可以用CouchDB暂存数据，随后进行同步。也可以在Cloud环境中，作为大型的分布式的数据存储。 CouchDB提供了基于 HTTP的API的访问方式，这样，保证了所有的常见的语言都可以使用CouchDB。

底层存储结构

CouchDB是一个"面向文档"的数据库，文档的格式是一个JSON字符串（也可包含二进制附件）。底层结构是由一个"存储"(storeage) ，以及多个"视图索引"(view indexs)。 "储存"用来储存文件, "视图索引"用于查询处理。

CouchDB落实到最底层的数据结构就是两类B+Tree 。

第一类 B+Tree，by_id_index （使用document的id为key）。常用来通过document的id来查找document的位置，实际上，他是指向的一个reversion列表集合。

第二类B+Tree， by_seqnum_index （使用序列号来作为key，说得具体点就是记录最新的reversion来作为key）。当document进行更新的时候，就会产生一个新的序列号。（值得注意的是，所有更新操作都是一个串行的方式，因此序列号反映了序列的非同步更新）。同步复制的追踪，数据的显示以及更新与它都密不可分。

一切皆追加

所有的更新操作（包括 document的创建，修改和删除）都是以在couch文件尾部追加的方式（即Append方式）进行。而不是修改现有的文件。在此之后， B+树节点也修改为指向新的文件的位置。修改操作实际上就是在现有的B+树的末尾附加一个新的文件。这反过来又引发修改父节点的B+树节点，造成一个新的副本父节点...直到所有的方式回到根B+树节点。最后修改文件头以指向新的跟节点。

这意味着所有更新将触发1次写入文件（除删除）和logN写入每个B +树节点的页面。因此，复杂度为O （ logN ）。

一切皆追加的操作提供了一个有趣的MVCC （多版本并发控制）模型，因为该文件保存了所有以前的历史文件版本信息。只要客户端持有先前根节点的B +树索引，它就可以得到的快照视图。即便是更新不断发生，客户将不会看到任何的最新变化。这种一致性快照在在线备份以及在线"瘦身"方面是非常有用的。锁机制和MVCC（多版本并发控制）的比较见文章最后补充！

值得注意的是，读操作是并行的，写操作是串行的。换句话说，在任何时候只有一个文件可以进行更新操作（但是，如果是写入附件的话，可以在一个文件中进行并行操作。）

GET document

当客户端向CouchDB的发出的HTTP的REST的GET请求，DBServer将做如下操作...

查找文件头，找到by_id B +树索引的根节点
在B +树中找出该文件的位置
阅读了该文件，并返回到客户端

PUT document（修改操作）

当客户端向CouchDB的发出的HTTP的REST的PUT请求，DBServer将做如下操作...

查找文件头，找到by_id B +树索引的根节点
在B +树中找出该文件的位置
读取该文件。对比reversion，如果他们不匹配就抛出一个错误。
如果它们匹配，生成一个新的reversion。
寻找末尾的一个区域(region)，看看该文件的容量是否可以容纳，如果不能就另外开辟一个region。
写文件(新reversion)到新的区域(region)
修改by_id B +树以指向新的文件位置
修改by_seqnum B +树添加新实体（新seqnum ），并删除旧的条目（旧seqnum ）。

请注意， by_seqnum B +树索引总是指向最新版本，以前的修改会自动被覆盖。

PUT/POST document（创建）

当客户端向CouchDB的发出的HTTP的REST的PUT请求，DBServer将做如下操作...

生成一个新的seqnum及一个新的文件编号和修订
寻找末尾的一个区域(region)，看看该文件的容量是否可以容纳，如果不能就另外开辟一个region。
写文件(新reversion)到新的区域(region)
修改by_id B +树以指向新的文件位置
修改by_seqnum B +树添加新项目（新seqnum ）

删除文件（修改）

当客户端向CouchDB的发出的HTTP的REST的DELETE请求，DBServer将做如下操作...

查找文件头找到根节点的by_id B +树索引
在B +树找出叶节点以及该文件的位置
读取该文件。对比修订，如果他们不匹配就抛出一个错误。
如果它们匹配，找出找到这个reversion。
生成一个新的reqnum
修改by_id B +树的reversion 历史，将这个路径的reversion标记为被删除
修改by_seqnum B +树添加新实体（新seqnum ），并删除旧的条目（旧seqnum ）。

Online Compation(删除旧的Document)

作为一个一切皆追加的存储方式，存储文件会随着时间的推移与日俱增。因此，我们需要对其进行"瘦身"，删除那些旧的Document数据。这个过程称为 Compaction。

打开一个新的存储文件
从by_seqnum B +树索引中找到最新reversion的document
复制document到新的存储文件中（在新的存储文件中自动更新相应的B +树索引）。

在Compation的过程，数据库仍然可用，只是请注意，在Compation的时候，是通过遍历DBName.couch文件，将最新的数据拷贝到一个DBName.compat文件中，因此这个过程可能会耗费很大的存储空间，如果您在系统繁忙（主要是write）的情况下进行Compation，可能会导致你的硬盘空间耗尽。推荐系统在一个写操作不是很繁忙的情况下进行Compation。

View Indexs

CouchDB支持类似数据库的View的概念。所不同的是CouchDB是采用Map/Reduce的方式来表现的。（请注意，reduce语义与谷歌的Map/Reduce模型有着很大的不同）。Map()是一个用户定义的函数，它用来将每个文件处理成中间结果。Reduce()是另外的一种用户定义的函数，它将Map()函数所产生的中间结果进行收集汇总而生成最终结果。

Map()的中间对象和 Reduce()后的结果存储在View Indexs中。随着存储得到更新，以前的结果也会随着更新。

每一个View的定义就是一个 Map函数和一个可选的Reduce函数。View存储在design Document中。

(map函数，必须）
function(doc) {
emit(null, doc);
}
(reduce函数，可选）
function (key, values, rereduce) {return sum(values);
}

请注意这里design Document和View Index是不同的。design Document保存的是view的定义，View Index保存的是针对某个Database进行View操作，产生的结果。

起初，View文件是空的（View尚未创建），当查询执行的时候会触发下面一系列的处理。

1.CouchDB将遍历存储文件的by_seqnum B +树索引。
2.在此基础上， CouchDB获得所有现有文件的最新reversion
3.CouchDB通过seqnum获取document，然后将每份document反馈到View Server 上用于进行Map操作。
4.View Server 调用map(doc)函数，遍历调用emit(key，value)，一个中间实体就是被这么创建出来的。
5.最后，将map(doc)函数所产生和结果集返回给CouchDB 。
6.CouchDb将这些实体加入到B +树索引，Key = emit_key + doc_id 。遍历每一个B +树的叶节点。
7.CouchDB将View Servier所获得的Map()结果集进行"Reduce" 操作。
8.View Server 调用Reduce(key，value)函数。
9.将reduce计算的结果返回给CouchDB
10.CouchDb将更新叶子上的B +树节点，将其指向reduce的值。
11.在此之后， CouchDb移动到父节点的叶子上的B +树节点。遍历每个B +树父节点， CouchDB将相应reduce子节点的数据发送到View Server，再次进行reduce的操作(rereduce)。
12.View Server再次调用 reduce(key, value)函数。
13.最后，再将rereduce计算出的结果返回给CouchDB 。
14.CouchDB将更新父B +树节点，将其指向rereduce的值。

CouchDB继续上升一个等级，并重复计算rereduce结果。最后，直到更新完根节点的rereduce的结果为止。

当处理完成后，View Index 看上去就是下面这种样子

增量视图更新

CouchDB更新view indexes采用懒加载和增量的方式。也即是说，当文件被更新了，CouchDB不会立即刷新view index，直到下一次查询到来的时候才进行更新。

CouchDB刷新index 采用如下的方式:

CouchDB将遍历存储文件的by_seqnum B +树索引。
CouchDB从最后一次视图查询的结果中抽取出的所有改变的文档，然后从新进行map操作，并取得一个Map结果集合。
CouchDb更新Map结果到B +树索引，一些叶子B +树节点将被更新。
对于那些已经更新了的叶子B +树节点， CouchDB重新发送Map生成的所有中间结果到View Server 进行Reduce的操作。然后reduce的结果保存到B +树节点。
所有涉及到这个叶子B +树节点都需要更新， CouchDB需要再次执行Reduce计算，并且更新相应的父节点。直到更新完根节点为止。

由于一致的快照的特性，在进行数据更新操作的过程中，view 查询需要花费较长时间。查询需要等待索引更新完成后才能看到一致的结果。还有一个选择（开发中），立即返回一个陈旧的副本，这对客户来说是可以容忍的。

补充：

悲观锁（即锁机制）和MVCC对比

上面介绍了悲观锁和MVCC的基本原理，但是对于它们分别适用于什么场合，不同的场合下两种机制优劣具体表现在什么地方还不是很清楚。这里我就对一些典型的应用场景进行简单的分析。需要注意的是下面的分析不针对分布式，悲观锁和MVCC两种机制在分布式系统、单数据库系统、甚至到内存变量各个层次都存在。

### 场景1：对读的响应速度要求高

有一类系统更新特别频繁，并且对读的响应速度要求很高，如股票交易系统。在悲观锁机制下，写会阻塞读，那么当有写操作时，读操作的响应速度就会受到影响；而MVCC不存在读写锁，读操作是不受任何阻塞的，所以读的响应速度会更快更稳定。

### 场景2：读远多于写

对于许多系统来讲，读操作的比例往往远大于写操作，特别是某些海量并发读的系统。在悲观锁机制下，当有写操作占用锁，就会有大量的读操作被阻塞，影响并发性能；而MVCC可以保持比较高且稳定的读并发能力。

### 场景3：写操作冲突频繁

如果系统中写操作的比例很高，且冲突频繁，这时就需要仔细评估。假设两个有冲突的业务L1和L2，它们在单独执行是分别耗时t1，t2。在悲观锁机制下，它们的总时间大约等于串行执行的时间：

T = t1 + t2

而在MVCC下，假设L1在L2之前更新，L2需要retry一次，它们的总时间大约等于L2执行两次的时间（这里假设L2的两次执行耗时相等，更好的情况是，如果第1次能缓存下部分有效结果，第二次执行L2耗时是可能减小的）：

T’ = 2 * t2

这时关键是要评估retry的代价，如果retry的代价很低，比如，对某个计数器递增，又或者第二次执行可以比第一次快很多，这时采用MVCC机制就比较适合。反之，如果retry的代价很大，比如，报表统计运算需要算几小时甚至一天那就应该采用锁机制避免retry。

从上面的分析，我们可以简单的得出这样的结论：对读的响应速度和并发性要求比较高的场景适合MVCC；而retry代价越大的场景越适合悲观锁机制。

总结

本文介绍了一种基于多版本并发控制（MVCC）思想的Conditional Update解决分布式系统并发控制问题的方法。和基于悲观锁的方法相比，该方法避免了大粒度和长时间的锁定，能更好地适应对读的响应速度和并发性要求高的场景。