CouchDB让人头痛的十大问题

日期: 2012-02-14 作者:Mathias Meyer翻译:nosqlfan 来源:TechTarget中国 英文

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

  1、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的指定,可以实现返回老数据后再在后台更新的功能。

  2、缺乏自动压缩功能

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

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

  3、不支持局部更新

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

  4、缺乏内存的扩展性支持

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

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

  5、分页实现起来会很奇怪

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

  6、范围查询使用不太方便

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

  7、CommonJS无法用于mapreduce函数中

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

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

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

  9、读操作总是会落到磁盘上

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

  10、没用的错误信息

  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的,虽然有上面一些让人不爽的地方,但是它还是能帮我处理很多问题。所以争论一个东西是否要用,并不是看它能不能满足所有需求,而是看它能不能满足你要的核心需求就行了。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

电子邮件地址不会被公开。 必填项已用*标注

敬请读者发表评论,本站保留删除与本文无关和不雅评论的权力。

翻译

nosqlfan
nosqlfan

相关推荐