CouchDB了解(-) 特性及实现

概述

CouchDB，大家或多或少都听说过。它到底有什么特性，适合哪些应用场景，和我们常用的关系型数据库有什么区别？ 这些问题，可能我们心里都不是非常清楚。在以前的Blog中(PS,不是在javaeye哦），我提及了几次CouchDB,但是仅仅 限于编译，安装这些浮在水面上的工作。今天抽出时间把最近关于CouchDB的一些了解整理一下。

CouchDB是什么

CouchDB一种半结构化面向文档的分布式，高容错的数据库系统，其提供RESTFul HTTP/JSON接口。其拥有MVCC特性，用户可以通过自定义Map/Reduce函数生成对应的View。

在CouchDB中，数据是以JSON字符的方式存储在文件中。

特性

• RESTFul API：HTTP GET/PUT/POST/DELETE + JSON
• 基于文档存储，数据之间没有关系范式要求
• 每个数据库对应单个个文件(以JSON保存),Hot backup
• MVCC（Multi-Version-Concurrency-Control），读写均不锁定数据库
• 用户自定义View
• 内建备份机制
• 支持附件
• 使用Erlang开发（更多的特性）

应用场景 在我们的生活中，有很多document，比如信件，账单，笔记等，他们只是简单的信息，没有关系的需求，我们可能仅仅需要存储这些数据。 这样的情况下，CouchDB应该是很好的选择。当然其他使用关系型数据库的环境，也可以使用CouchDB来解决。

 

根据CouchDB的特性，在某些偶 尔连接网络的应用中，我们可以用CouchDB暂存数据，随后进行同步。也可以在Cloud环境中，作为分布式的数据存储。CouchDB提供给予 HTTP的API，这样所有的常见语言都可以使用CouchDB。

 

使用CouchDB，意味着我们不需要在像使用RMDBS一样，在设计应用前首先设计负责数据Table。我们的开发更加快速，灵活。

实现

在CouchDB中，Database表示一个数据库，每个Database对应一个"Storage"（后缀为.couch）以及多个View Index(用来存储View结果支持query）。

 

Database Storage中可以存储任意的Document，用户可以在Database中自定义View，方便对数据进行查询, View 默认使用JavaScript进行定义，定义好的相关函数保存在 design document中，而View对应的具体数据是保存在View Index文件中。我们可以通过HTTP API请求Database，Document，View，可以进行简单的Query，以及其他各种系统相关的信息。

Storage File结构

数据库文件的后缀为.couch，由Header和Body组成。

Header

包含两个完全相同的Header信息，每个Header的Size为2048

Header中前4字节为magic code:$g, $m, $k, 0

随后为header的payload，通过term_to_binary(db_header_record)产生

接下来是填充padding

最后是16字节的摘要信息(md5(payload+padding)产生)

Header总长度为：单个Header * 2 = 2048

Body

由两个B+Tree组成，其中一个B+Tree根据Document id进行组织，另一个B+Tree以 seqnum（CouchDB内部使用的序号，用来指示最新Revision的文档）为key。

• fulldocinfo_by_id_btree

  使用Document id作为key，常用来根据id来查找对应的document，full_doc_info中包含对应document的所有的Revision信息，通过这些信息，我们可以获取指定Revision的document

• docinfo_by_seq_btree

  使用seq作为key，当document被更新时，对应的seq会增加。 具体的document数据（json格式），以及B+Tree混合存储与这个.couch文件之中。通过B+Tree，我们可以快速的定位到指定的document。

 

所有的更新操作（包括document的创建，修改和删除）都是以在couch文件尾部追加的方式（即Append方式）进行。我们进行更新时，首 先拷贝原有的数据信息（仅仅针对修改，如果是Create那么就没有copy可言了），随后将其追加到文件的结尾，这个时候就激发B+Tree从leaf 到root的更新过程，更新的Node信息也是采用Append的方式写入到文件的结尾，到达根节点时，我们将根节点信息写入到Header中。这样一次 更新操作涉及1次数据写入，以及LogN次节点更新，所以其复杂度为O(logN)

 

因此采用追加的方式，所以在数据库运行一段时间后，我们需要对其进行“瘦身”，情理那些旧的Document数据。这个过程成为 Compaction。在Compation的过程，数据库仍然可用，只是请注意，在Compation的时候，是通过遍历DBName.couch文 件，将最新的数据拷贝到一个DBName.compat文件中，因此这个过程可能会耗费很大的存储空间，如果您在系统繁忙（主要是write）的情况下进 行Compation，可能会导致你的硬盘空间耗尽，一定注意哦！

ACID

CouchDB支持ACID特性。Document的更新（add，edit，delete）是顺序进行的，但是Database的read为并发 执行，其不必等待任何其他的read，write的完成。这样的特性与CouchDB存储文件的Append增加方式关系密切。

当CouchDB的文档更新时，为了保证数据的一致性，Commit分为以下两步：

1. Document数据和index数据首先写入到disk数据库文件
2. 生成两个连续的头信息（4kb),随后写入数据库文件

在上面两个过程中，如果在过程1，发生异常（系统崩溃或断电），那么couch文件的头信息没有发生变化，那么所有Append的数据都会被忽略； 如果在过程2发生异常，此时Header可能会发生损坏，我们验证第一个Header和第二个Header，如果任意一个Header可用，那么数据库文 件可用。如果两个Header都不可用，则对应数据库文件损坏，抛出异常。

 

一些数据库系统，为了实现 Atomic Commit ，提交数据前，将内容写入到一个rollback log文件，等提交完成后，删除log文件。

View Server

除了存储数据，我们还需要依据我们的要求展现数据，乃至一些统计，因此CouchDB中引入了View的概念。View的引入让CouchDB从一个有趣的文件存储系统，步入了数据库的殿堂。也使CouchDB能够融入到真正的应用环境中。

 

CouchDB中所有的Document都可以具有自己不同的结构，数据，这和关系型数据库中，严格的表结构，严格的关联完全不同。这样的特点对于数据的备份同步却非常有好处！

View Model

通过用户自定义View，我们可以汇集，统计数据，采用一个类似Map/Reduce的过程。这里的Map将原始的Document进行映射处理，Reduce将Map的中间结果进行重新归并统计，总而生成最终结果。这里和并行计算中的Map/Reduce有些不同。

 

CouchDB的View针对每个Database，但是其与Database关联性不是很大，View是一些用户自定义函数，处理从数据库的 Document输入，产生中间数据（如果没有reduce过程则为最终数据），然后再通过Reduce处理中间输出，产生最终结果。同样的View可以 使用在不同的Database上。

 

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

JavaScript View Function

CouchDB内部默认使用JavaScript作为View的编写语言，之所以采用Javascript，是和CouchDB面向Web开发相关 的。CouchDB使用Mozilla的spidermonkey作为JavaScript的解析运行平台，为了和Erlang进行交互，其使用c书写了 一个Port程序couchjs，/server/main.js作为View Server服务器。

在启动CouchDB时，通过Command：couchjs main.js即可启动基于JavaScript的View Server。

View中包含两个函数:

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

doc ,为我们数据库对应的Document，因为我们采用JSON格式存储数据，所以Document在 JavaScript中转化为Object。`emit(null, doc)`用来生成map的中间结果，其中第一个参数null表示结果的key，第二个参数为结果的value，上面的例子中我们的结果为:

null, value1
...
null, valueN

function (key, values, rereduce)中，根据rereduce变量不同这里有两种情况:

1. rereduce为false

• key为array，element为：[key,id]，key为map function产生的key，id为Document对应id
• values为array，elements为map function产生的结果
• 比如 reduce([ [key1,id1], [key2,id2], [key3,id3] ], [value1,value2,value3], false)

1. rereduce为true

• key为null
• values为array，element为前一次reduce返回的结果
• 比如reduce(null, [intermediate1,intermediate2,intermediate3], true)

很多时候，我们一次调用reduce就可以生成最终结果，我们会忽略rereduce参数。

 

参考

1. couchdb
2. horicky
3. ayende

评论

10 楼 yubingxing 2009-06-02  

couchdb和文档数据库能用于那些应用场景呢？举例说明。

9 楼 yefeng 2009-02-26  

能不能分析一下，couchDB和Berkeley DB，优缺点，和使用场景

8 楼 iso1600 2009-02-02  

我原来也非常想将couchdb用于生产环境，优点：分布式及REST简洁的风格。

但是看了这个文章后我想法又发生了变化。http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-stores/ 我个人对于文档数据库的需求并不高，我需求多的其实是key-value store. 因此除了couchdb之外，其实还有很多更好的选择。

而且couchdb用于生产环境，目前还有以下顾虑：
安全及身份控制
数据访问，比如将来如果有需求转向另外一种方案比如mysql，那数据导出问题多多，也许是不可能的任务。

Tim

7 楼 lazy 2009-02-02  

Lotus就是文档型数据库，处理oa够用了，但是大量的数据计算和复杂业务关系不行。

6 楼 whaosoft 2009-02-01  

晕 我还真没听过这个

5 楼 ozzzzzz 2009-02-01  

superdandy 写道

如果没有什么关系的话，是否可以尝试文档型数据库呢？ 感觉单纯存储文档比这样的要好

貌似这个东西声称自己就是文档型数据库。
我欣赏作者的探索精神，但是感觉他的思维方式有问题。因为这个东西应用方向和使用的场景都同关系型数据库不同，其插入和删除等性能参数方面有差距几乎是一定的。如果要讨论，我倒是希望去探讨一下zodb。

4 楼 superdandy 2009-02-01  

如果没有什么关系的话，是否可以尝试文档型数据库呢？ 感觉单纯存储文档比这样的要好

3 楼 lzy.je 2009-01-31  

很好，谢谢。

最近也在研究couchDB，同时也想通过src能更理解erlang，引入实践。

2 楼 litaocheng 2009-01-22  

ShiningRay 写道

很好很强大能否对比一下mnesia和couchdb的差异？

引用CouchDB FAQ中关于为什么不使用Mensia的回答：

* Mnesia每个数据文件有2GB大小限制
* 如果系统发生故障，重新启动时，Mnesia需要一个验证及修复的循过程，如果你的数据库文件很大，那么这个过程相当漫长
* Mensia的备份基于互相连接的分布式节点，而CouchDB可以在离线状态下工作，随后进行数据同步，备份。同样Mensia的很多优秀的特性Couch并不需要。
* Mnesia不是一个通用的数据库系统，其可能更多的应用在配置信息的分布式发布，更新等情景。比如network routers，http proxies， LDAP directories等。这些数据都不会非常大。
   
综合以上原因，其开发了CouchDB，其更加灵活，通用。

1 楼 ShiningRay 2009-01-22  

很好很强大

能否对比一下mnesia和couchdb的差异？