开发者Hasen谈为什么选择CouchDB

Hasen是一名熟知分布式技术、Go语言的开发者,他最近在自己的博客上发布了一篇文章,谈到为什么要选择CouchDB作为自己的数据库。

我一直痛恨SQL,所以我总是对NoSQL运动充满兴趣。

我知道2个基于JSON的NoSQL数据库:MongoDB和CouchDB。

我曾试着学习MongoDB,当时我也在学习NodeJS——巨大的错误,浪费我很多时间。不管怎么说,MongoDB的API不错,但是我不喜欢 它的查询语言, 跟SQL差不多,拖沓、冗长、僵化难懂。最后我实在没法用MongoDB做出什么像样的东西,因为我试着用它跟Node一起,可我在NodeJS上门的体 验实在不怎么样。究其原因,是因为NodeJS的设计,因此我没用起来MongoDB不是MongoDB的问题,而是NodeJS的问题。

学习CouchDB,也是因为Hasen的一个舍友跟他提起的,他从看CouchDB的官方手册开始:http://guide.couchdb.org/

打动Hasen的,是CouchDB的如下特性:

首先,它是纯JSON文档存储。也就是说所有的文档都是JSON,而且可以有任意数量的字段,你也可以随意向现有文档中加入新字段。没有schema,因此不需要管理迁移问题。

其次,它的“视图”系统。CouchDB中的视图可以创建第二索引,而且是执行查询的惟一方式(不是通过文档的 _id来加载它)。视图基本上是map函数的缓存结果。

举个例子,比如你在一个所有者和一堆物品之间有多对一的关系,每件物品都会在一个字段中保存所有者id。该如何按照所有者查询物品列表?你可以创建 一个视图,匹配owner_id和item_id,使用owner_id查询该试图。这也就是说,对于任何查询,都要先创建一个视图。不能像SQL数据库 或是MongoDB那样随意查询。这可能有好有坏,要看你的心情。我个人认为挺好的,因为这让索引变得简单。

我在传统SQL数据库中见到不少如下问题:有时候,一个极其庞杂的查询成为瓶颈,对性能产生极坏影响。有时候你需要抽丝剥茧,看看问题到底在哪里;有时候,你会发现是查询写得太烂了;有时候,你只要往某个表中加个索引即可。

这种悲剧我可不想碰见。

因此,视图系统的好处在于:强迫你把查询变简单,而且易于分析。

第三,CouchDB的架构在某种意义上是“分布式”的,与git的分布方式很类似。当然,总要从一个数据库示例开始,但是如果要加入其他数据库节点,CouchDB的设计让自己很容易做到分布式。

像Git,是因为所有节点都是“master”节点,没有“slave”节点;跟Git一样,没有哪个repo比其他ripo更重要。

同步是由一个节点向其他节点推送变化完成的,这很类似于Git的repo推送、拉取变更的过程。在CouchDB中,这种推送叫“复制 (replication)”。它会把所有的“新”文档和现有文档的“新版本”推送出去。CouchDB中有修订版本概念。改变一个文档,CouchDB 会在内部增加一个新的修订版本保存起来,不删除或覆盖已有修订版本。不过,CouchDB不保证任何旧文档会一直保存,它们被看成“垃圾”并会在以后回 收。

不过,这种分布式特性有其代价:数据在不同节点间不一定总是一致的,可能有些节点数据过期,但如果经常复制,可以确保数据节点的最终一致性。

从整体上看,我不认为这是个大问题,而是一个特性,任何基于web服务的底层架构设计都应该以其为基础。

Hasen指出:web服务和应用都面临扩展性方面的问题,而且即使是一些简单的交互多媒体页面,也会让服务器承受很大压力。他接下来对比了单机视频游戏和Web服务在这方面的不同:

首先,web开发人员多使用动态解释语言,比如Python和Ruby,这些语言的设计目的不是为了运行高性能服务。

其次,视频游戏一次只需要处理一个大型复杂任务。而在web服务中,需要把一个相对简单的任务同时做几十万遍,而且是在一个机器上。当然,这么做很 愚蠢,要加入更多机器节点,把负载分到这些节点上,各个节点之间不需要通信,每个节点可以处理分配给自己的任务。做不到这几点,就不是分布系统了。

不过,目前的数据库都不是我们应该需要的数据库:只有一个master,这就是瓶颈。即使只需要向一个master数据库写入,可以从其他节点读,仍然有瓶颈。

Hasen认为这不是正确的分布式做法,要想解决每秒处理几十万个简单的页面请求,架构上必须做到水平扩展:应该可以加入更多节点,而且每个节点都可以自行决策。

如果你只有一个master节点,你的分布式就做得有问题。

即使你必须保证user-id的全局唯一性,也可以以分布式方式实现。

Hasen对Riak也很欣赏,认为Riak的分布式实现很简单,也容易掌握。不过他还是选择了CouchDB:

对我来说,Riak的问题是它没有CouchDB那样的“视图”。Riak中可以做map-reduce类似操作,但是太影响性能了,在CouchDB中,视图是预先计算好的map-reduce查询,而且效率很高。

Riak超出CouchDB的,是Riak内置集群支持。在CouchDB中,没有。……虽然这可能是Riak相对CouchDB的短处,但是我还是认为视图的好处超过这一点。

而且,还有BigCouch项目,它的分布式实现非常出色。

因此,如果要扩展到几十万用户,我可以选用BigCouch。也许将来BigCouch会合并到CouchDB中。我也可以自己实现集群和分布式。

Hasen的文章最初发表后,有人留言指出MongoDB也支持水平扩展,是以自动分片(automatic sharding)方式。

对此,Hasen的回复是:

使用CouchDB,你也可以分片或是分区。实际上,使用CouchDB更简单,因为用了一致性哈希。在Couch中做分区的问题是:如果查询一个视图,必须查询所有的分区。考虑到我上面说的“每个节点必须在本地自己完成计算”,这听起来不怎么样。

不过,要记住复制功能。你可以在北美有一个分布集群,在欧洲、亚洲各有一个分区集群。这些集群可以在任何时候保证互相复制。因此,视图查询在每个集群内部的本地化的,这正是分布式精神之所在。

在我目前看来,MongoDB还做不到这一点。

InfoQ的读者们,你们是否有MongoDB和CouchDB的使用经验?对于Hasen的观点,你们同意吗?

郑柯 InfoQ中文站总编。做过开发,当过PM,干过销售,搞过市场,最终还是回到媒体。实用的理想主义者,相信:每天改变一点点,这个世界会更好。

This entry was posted in DB. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s