CouchDB 实现原理

红薯 发布于 2009/03/19 23:25
阅读 2K+
收藏 4

特性

  1. RESTFul API
  2. 基于文档存储,无表固定结构,数据之间没有关系范式要求
  3. 多版本并发控制模型
  4. 用户自定义查询结构(map/reduce)
  5. 增量索引更新机制
  6. 多master复制模式
  7. 用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将做如下操作...

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

PUT document(修改操作)

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

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

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

PUT/POST document(创建)

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

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

删除文件(修改)

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

  1. 查找文件头找到根节点的by_id B +树索引
  2. 在B +树找出叶节点以及该文件的位置
  3. 读取该文件。 对比修订,如果他们不匹配就抛出一个错误。
  4. 如果它们匹配,找出找到这个reversion。
  5. 生成一个新的reqnum
  6. 修改by_id B +树的reversion 历史,将这个路径的reversion标记为被删除
  7. 修改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 采用如下的方式:

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

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

加载中
0
l
lingshulei

您好,最近在做一个平台开发,用的Restlet Hadoop MuleEsb 数据库用的是Couchdb ,目前遇到的问题就是在数据库的安全方面不知道怎么去,下面我把遇到的问题简单的描述下

如果没有创建任何管理员(amdin 权限的账号),然后通过restlet api 向数据服务器发送 put delete post get的request请求 对database 和document 都可以做任何的操作。

问题1:我一旦创建了一个管理员账号 再执行上述的request  则对database是不可以进行操作 ,返回的是unauthorized ,那么即使是友好的请求也会被unauthorized

问题2:还是创建管理员 执行上述的request   对document的操作没有任何影响,依然可以进行增删改查

希望您能百忙之中看到我的问题 然后帮忙解决一下

0
沫117
沫117
您好!我想知道您提到的客户端,一般指的是什么呢?需要什么软件和语言才可以执行以上的操作啊?
返回顶部
顶部