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 +树索引，它就可以得到的快照视图。即便是更新不断发生，客户将不会看到任何的最新变化。这种一致性快照在在线备份以及在线"瘦身"方面是非常有用的。

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

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 查询需要花费较长时间。查询需要等待索引更新完成后才能看到一致的结果。还有一个选择（开发中），立即返回一个陈旧的副本，这对客户来说是可以容忍的。