CouchDB 让人头痛的十大问题

下面十条内容来自paperplanes的博主Mathias Meyer，他也是一位NoSQL的实践者，CouchDB就是其钟爱的数据库之一。正所谓爱之深恨之切，在使用CouchDB的过程中，他发现很多不顺手的地方，就是本文列举的十大问题。

View是在读时更新的

我们知道CouchDB不支持动态查询，也就是说你的每个查询，都需要事先创建一个对应的View，创建View是很快的，即使你的数据集很大，这 是因为CouchDB并不在创建View的时候就建立View索引，而是在读取的时候来做这个事。当在一个View上执行一次读操作时，CouchDB会 对比当前View中的索引更新时间与最后写操作时间，如果发现在索引更新之后又有写操作，那么会把这段时间的写操作合并到索引中再返回给客户端。

你可以想象到，如果数据集非常大，你创建完View后的第一次读取会是多慢。同样的，如果你两次读操作间隔期间有太多的写操作，那么也会导致读操作 非常慢，有的朋友通过cron任务定时对View进行查询，从而触发定时的索引更新操作，以减少真正读操作需要等待的时间，不得不说这真是蛋疼。这一切， 都是因为CouchDB的View是在读时更新导致的。

而实际上，如果你不愿意等待CouchDB去更新完索引后再返回数据，你也可以通过stale=ok参数指定它返回老数据即可，不用做更新操作。但 我们不能总是访问老数据，作者希望可以通过指定查询先返回老的数据，再进行相应的索引更新操作。而实际上这一功能已经在1.1.0版本中实现了，在 1.1.0版本中，添加了一个stale=update_after的指定，可以实现返回老数据后再在后台更新的功能。

缺乏自动压缩功能

CouchDB采用了append-only的方法进行数据更新，也就是所有数据的写操作，都不会修改原来的数据文件，而是追加上新的版本来实现。 这使得CouchDB能够实现对同一条数据保存多个版本。也使得CouchDB的数据文件永远不会被改花掉。因为它永远在做append操作，即使出现问 题，只要去掉尾巴上一某一段数据就能回到之前某个时间的数据快照。

然而，这些好的特性必然需要付出代价，这代价就是数据大小会只增不减的膨胀。所以，数据压缩工作是迟早都得做的事。但是CouchDB并没有提供数据自动压缩的功能。这让人很郁闷。

不支持局部更新

局部更新的意思就是，不更新整条数据，只更新其它某个属性或字段。这个看似天经地义的功能，在CouchDB里却没有。在CouchDB中，所有的update操作都需要对整条数据进行更新。

缺乏内存的扩展性支持

CouchDB的同步机制是很牛X的，这几乎是它的杀手级功能。你可以随意在集群中添加删除节点， 可以随意指定Master和Slave的角色， 数据都会很好的同步到所有节点上。能达到这样的效果，是由CouchDB本身的机制决定的。然而，我们并不能做跨节点的读写操作。

在这方面，CouchDB-lounge算是一个尝试，但是它把整个架构复杂化了，我感觉不太舒服。

分页实现起来会很奇怪

如果你要对CouchDB中的数据进行分页展示，这会比较麻烦，在《CouchDB权威指南》中有一个对分页的实现，但是这个实现给人感觉非常别扭。如果你要在CouchDB中实现分页的话，最好还是用那个“获取更多”按钮的方式来做。

范围查询使用不太方便

如果你的key是这样的['123', '2010/07/21']，其中前一部分为查询的key，后一部分为时间，用于保证记录的顺序性。这时候你要查询所有’123′开头的记录时，就需要指 定起始条件为 ['123']，并且还必须指定一个终止条件为['123',{}]，这样让人感觉用起得很不方便。

CommonJS无法用于mapreduce函数中

在CouchDB 0.11版本中，CommonJS已经可以用在view函数上，但是一直不能用在mapreduce函数中。这让我总是重复一些写过的代码。

缺乏document之间完备的包含关系

在CouchDB 0.11中，map函数可以通过{_id: doc.other_id}的方式包含另外一个document的引用，在查询时能够获取到对应这个文档的id，但是再进一步，如果我想再获取被包含的这 个文档的属性，那就没办法了。希望能够有办法通过当前集合的查询，获取并返回这个包含的文档的某些属性。

读操作总是会落到磁盘上

CouchDB没有实现自己的缓存。在写操作中，你可以通过delay commit的方式将写操作延迟同步，这样就避免了每次写操作就需要写磁盘。但除此之外，CouchDB没有做任何缓存。对于移动设备上的CouchDB 来说，写磁盘可能会好一些，毕竟移动设备上的flash设备比服务器上的传统磁盘性能要好一些。

没用的错误信息

CouchDB的错误信息经常让人摸不着头脑，根本就看不明白错误出在哪里。比如下面这一段，你能告诉我它说明了什么问题吗。

{<0.84.0>,supervisor_report,
 [{supervisor,{local,couch_secondary_services}},
  {errorContext,start_error},
  {reason,
      {'EXIT',
          {undef,
              [{couch_auth_cache,start_link,[]},
               {supervisor,do_start_child,2},
               {supervisor,start_children,3},
               {supervisor,init_children,2},
               {gen_server,init_it,6},
               {proc_lib,init_p_do_apply,3}]}}},
  {offender,
      [{pid,undefined},
       {name,auth_cache},
       {mfa,{couch_auth_cache,start_link,[]}},
       {restart_type,permanent},
       {shutdown,brutal_kill},
       {child_type,worker}]}]}}

好了，大概就这些吧。虽然上面说了这么多CouchDB让人不爽的地方，但是总的来说，我还是很喜欢CouchDB的，虽然有上面一些让人不爽的地 方，但是它还是能帮我处理很多问题。所以争论一个东西是否要用，并不是看它能不能满足所有需求，而是看它能不能满足你要的核心需求就行了。

来源：www.paperplanes.de
译文：http://blog.nosqlfan.com/html/3667.html

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14130873/viewspace-716187/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/14130873/viewspace-716187/