Damien Katz畅谈CouchDB

个人简介 Damien Katz曾就职于Lotus、MySQL、IBM。他是CouchDB的创造者。并且在未来相当长一段时间内都将投身于此。

   

1. 我们在RubyFringe大会现场采访Damien Katz。您能自我介绍一下吗？

我是CouchDB项目的创始人和主管。我现在在IBM工作，之前曾在MySQL，再之前又是IBM，当时做的是Lotus Notes项目。

   

2. 那么你衣服上印着的这个CouchDB到底是什么东西呢？

什么是CouchDB呢？CouchDB是一个文档数据库；它是一个支持复制的（Replecated）文档数据库，具有REST接口，也就是说可以在 HTTP上，用标准的GET、PUT、POST动词去访问。而且它用JavaScript作为查询语言去建立数据视图（View）。在SQL数据库里，你要定义各种表和表中的数据类型及大小，CouchDB不一样，它是没有Schema的。在CouchDB里，每个文档都是独立的对象，可以是任意的 JSON结构。这是技术上的表述。那么它的优点在哪里呢？它有利于构建很多协作型的应用，很多Web应用都是围绕着文档、上下文、任务、Bug报告，诸如此类的东西。这些就是CouchDB最擅长的方面。

   

3. CouchDB和其它产品有什么区别呢？比如，我觉得Lotus Notes也是基于文档的，还有XML数据库也比较类似。你认为CouchDB处在哪个位置？

它和Lotus Notes最接近，毕竟我从事Lotus Notes那么多年。我对整个Lotus Notes平台把握得相当透彻，知道它的真正优点。Lotus Notes上面堆彻了一大堆形同鸡肋的玩意儿，讨厌它的人比比皆是，但它的成功不是空穴来风。它已经活了很长时间，现在还有上亿用户，所以它一定有什么做得好的地方。我自己感觉知道Lotus Notes的力量源自何处，所以我要做的就是把那个核心剥出来，放进CouchDB。这个核心就是文档模型，所以说CouchDB一定很像Lotus Notes。XML数据库里面放的是单个的体型庞大的XML文档，那个模型有点不一样，我说不好。XML数据库我用得不多，但我认为是不太一样的东西。

   

4. 那么说CouchDB的原理就是往里面插入很多非结构化的文档。那么如何做搜索呢？怎么索引呢？我听说是用JavaScript？

是的。通常每个文档的结构不是随机的，它会有某种预定义的结构，但数据库不会去强制，而是由应用层去强制。以后我们会有数据库的接口让你强制文档在保存的时候遵从特定的格式或者Schema。但总的来说文档不必遵守什么Schema，那个是应用层的事情。所以它给了你很大的灵活性，看你想怎么去表达数据。比如说你有一个讨论组的数据库，你想显示主贴、显示评论、或者显示某位用户的全部文档，用CouchDB做起来都很简单。

   

5. 在CouchDB里怎么做查询?要用到什么？使用什么语言？

用JavaScript，用它创建视图。如果你知道文档的名字——每个文档都有它的ID，ID可以是任意的原始字符串，也可以是随机生成的——如果你知道文档的名字可以直接问数据库要，Get那个文档就行了。如果想建立一个视图包含某种类型的全部文档，那么就创建一个JavaScript函数，视图引擎会把数据库里的每一个文档都送到这个函数面前，让它全部检查一遍。然后你的函数会确定应该把文档里的哪些信息放进视图，然后把相应的键、值放进视图，并且按键排序。所以函数能决定它遍历过的每一个文档里面哪些是它想要的。接下来你对视图做个Get操作，所有结果就会整整齐齐地放在一个JSON响应里面返回给你。

   

6. 每次查询都运行一遍？遍历全部文档？有缓存吗？

遍历全部文档，但它保留一个持久化的索引，所以每次运行的时候已经有现成的索引。当更新文档的时候，比如说更新了5个文档，它就不用重新遍历数据库中的全部文档重新建立索引。相反，它只需要找出那些发生了变化的文档，重新计算相应的结果，剔除旧的结果，调整索引，然后你就可以查询了。这个过程是自动发生的，你只要定义视图和访问视图就好了，CouchDB会处理好，帮你完成这些背后的工作。

   

7. 你选了一种特别的语言去实现CouchDB——Erlang。你是出于哪些主要的理由才做出这种选择呢？

是的。CouchDB最早是用C++实现的，结果有点碰壁。当时我有了存储引擎、有了视图引擎、有了查询语言，都是C++写的，结果我在并发问题上撞了墙，因为老是要按传统方式去处理线程、锁、消息这些事情。后来我在“Lambda the Ultimate”还是哪里看到Erlang是个非常好的并发语言，所以想看看怎么把它融合进我的代码里头。所以我就下载了Erlang，玩了没多久就认定用它写数据库引擎和服务器简直是天作之合，于是我把原来的C和C++代码扔了，全部用Erlang重写。用Erlang写这个效率高得没法说，它特别适合做这些基础设施类型的东西。它原来是为电信业设计的，电信业面对的问题和数据库有很多相似之处，比如输入、输出量都很大、要保证可靠、平滑地处理失败。所以最后发现Erlang是CouchDB最适合的实现语言。

   

8. 你怎么集成 JavaScript的？是Erlang写的JavaScript运行时吗？是在同一个进程里面吗？

我们用的是Mozilla Spider Monkey引擎。我们需要的是一个单独执行的命令行进程，通过它连接Mozilla Spider Monkey引擎。进程通过标准的IO与CouchDB通信。所以实际上CouchDB产生这个进程的很多实例，通过标准输出向它发送JSON，然后从建立的管道中得到响应。这样即使JavaScript进程挂起了，或者由于用了过多内存还是别的什么原因被OS杀掉了，Erlang VM都不会受到影响，可以顺利恢复。

   

9. 你在管道中用的通信协议，就纯粹是JSON消息？

就是来回发JSON。先是命令，像动词一样的命令，它就是一个字符串，参数紧跟在后面，就是后续的数组里面的元素。这些都送进管道，送到管道另一边去解析，然后CouchDB解析清楚你想要什么，就计算出结果送回来。像这样基于行的简单协议有个好处，就是我们可以更换语言后端。比如目前标准引擎是 JavaScript的，但我们已经有了Ruby和Python的语言后端，可能还有别的语言，好像有谁写了个PHP的。就是说你想用什么语言写查询都可以。我知道CouchDB在Python社区里面已经很流行了。

   

10. 你在CouchDB里面利用了Erlang在可靠性方面的优势，而且看上去效果比较令人满意。那么Erlang在可伸缩性方面有没有帮助呢？

并发方面绝对有。有人抢着做了个基准测试，能达到2万个并发连接。很厉害的结果。而我们还没有做过Profiling呢。Erlang在这方面绝对给我们帮了大忙。如果我用传统的线程模型，500个活动连接就算很不错了，所以说Erlang绝对提高了单台机器的可伸缩性。Erlang对多台机器的可伸缩性也会有帮助，只不过我们暂时还没有用到那方面。有很多工具、库等等可以让多台机器的Erlang环境完成自动故障转移、高效率的消息交换等等，我们只不过还没用到那方面而已。

   

11. 你觉得SMP版本的Erlang有什么优势吗？或者有什么差别吗？

我还没做过Profiling，我想那个做Profiling的人也是用了多处理器，所以我想还没有谁在单进程版的Erlang上做过Profiling。

   

12. 有件事你在博客里面写过，就是你不喜欢Erlang的某些地方。那么你现在还是坚持一样的看法吗？有什么新见解吗？

有的，大多数不满的地方还没变，不过每种语言都会有你不喜欢的地方。Erlang里面有些东西有年头了，要是放在今天去设计，绝对会不一样。而且有些东西是它的编程范型息息相关的东西，要调整就不得不打破另外一些Erlang做得很对的地方，所以说有的地方比较泄气。它的字符串处理非常弱，这是我觉得可以改进的。如果你的问题不适合函数式编程范式，应该考虑用别的语言。

   

13. 请举出最不满意的三处：字符串处理、Unicode支持，还是别的什么？

我想字符串处理是挥之不去的问题。现在的字符串处理真是很低效，不但做大量字符串操作的时候非常麻烦——用Ruby或Python之类的语言处理字符串要容易、简洁得多——代码更难写，也更慢。所以说的确是个问题，我们在想办法解决。我们试过Erlang那种特殊风格的字符串，就是把每个字符都作为列表里的一个元素，最终一个字符要用16个字节存储。还有另一种二进制字符串，更接近其他编程语言里的传统字符串，语法当然难看了，不过我想肯定要换成这种字符串，因为会高效得多。

   

14. 我们说回文档数据库。以Lotus Notes为例，文档数据库是什么样子的？它们的长处在哪里？用途是什么？

我爱用一个比方来说明什么样的应用才是合理的文档数据库应用：假设你不是在这个程序里面，假设不是在电脑上，在现实世界里你会怎么做？如果结果是有很多份文件要归档和在不同的人手里传来传去，那就说明用文档数据库是对的。如果结果是要画图或者要画一张spreadsheet，整张表是一个整体的，会计用的那种，叫什么来着？就是在纸上的电子表格，它是不可分割的，全部属于一个文档。那种情况可能意味着需要一个单独的程序（而不是数据库）。但如果这种文档有不少，又要频繁接触，像任务列表、Bug列表、客户投诉，这些东西在现实世界里都是一叠一叠的。如果是这样的情况，你就要考虑可能关系数据库才合适，也可能文档数据库才合适。由于CouchDB的本质特点，你可以离线编辑文档，上线的时候再把修改内容复制回数据库，这件事对于关系数据库是非常困难的。所以当你需要离线访问数据的能力的时候，就是CouchDB这样的文档数据库大放光彩的时候。

   

15. 在大公司里面Lotus也是这样用的。

没错，Lotus仍然在广泛使用，很多时候人们仅仅把Lotus看成一个email平台，但实际上它是一个以文档为中心的应用开发平台。

   

16. Lotus Notes一开始就定位到这个目标，还是开始仅仅以email为目标？

一开始就这样定位，而在平台上建立的第一个应用是作为面向文档的数据库的email。所以email是Lotus Notes的首要应用，但又仅仅是Lotus Notes平台上的其中一种应用。Lotus上还有很多其他应用，可以完成Bug跟踪、客户报告和CRM一类的任务，很多公司都在用它做这些事情。

   

17. 那么是不是可以说这种文档数据库的概念，已经随Lotus Notes而出现了一段时间，而且也被其他产品所采用，现在似乎正随着CouchDB而流行起来。

Exchange一直以来都有这样的想法，比如Exchange服务器，就有类似的概念；比如共享文件夹让人们在上面搭建应用。但这些从来都没有成功过，没有人那样用Exchange。于是就有了其他类似的尝试。到了什么都搬到Web上面的时代，SharePoint就和Lotus Notes很像，只不过它像是单个实例的Lotus Notes Web服务器，而且客户端变成了浏览器。除了这点差别，它们有很多相同的地方，SharePoint是一个很面向文档的环境。这么多产品里面，我还是觉得只有Lotus Notes真正抓住了问题的关键，即使Lotus Notes在很多别的方面都做错了。我一直认为Lotus Notes是个独树一帜的产品，促使我创造CouchDB的动力也在于认为这个模型我们还探索得不够，还没有真正认识到它的价值。

   

18. 你打算把这个文档模型带到开源社区里面。好像与关系数据库竞争的各种数据库范型还不少，比如Google的BigTable。你怎么看？

BigTable——我不太认可它的优点，除了可伸缩性之外。我绝对同意它在可伸缩性方面的优势，但大多数应用都不需要那种程度的可伸缩性。它是个有局限的平台，但我没有真正用过所以不好说，我只是听过一些不满的声音。

   

19. 相对于基于文档的模型，它是另一种不同的模型吗？

我的确认为那是另一种模型，它们的视图模型不一样。CouchDB的真正关键是它的视图模型，让你生成各种视图去索引数据。而BigTable只是一个巨大的键-值存储表，我感觉对于复杂的应用来说可能不够用。