夜说mongodb
前两天本站刚刚分享了wordnik使用MongoDB经验的文章:《Wordnik 的 MongoDB 使用经历》,今天又看到一位朋友对这方面做的总结,分享在这里,供大家参考。
赋闲以后很长没有更新博客了,说忙完全是借口,多半因为没有兴致所致。今天凌晨比赛多多,趁着比赛的前奏和间隙,遂浏览些技术文章。发现了 highscalability.com整理出了wordnik使用mongodb和scala的使用经验:http://goo.gl/N3wlU。这个wordnik也算是mongodb的先驱应用者之一,并贡献了一些管理工具给社区,去年的mongoSF大会也有它的参与:http://goo.gl/GhiuY。
说起mongodb,从初识到现在已经有些时间,却也没有大场面使用和深入研究。nosql风吹了两年多势头愈发趋于冷静,能真正被大家认可使用的也就那 么几个,但又都离如mysql般成熟有些距离。而说起wordnik,它最初使用的就是mysql,后来主要因为性能问题转投mongodb,效果似乎还不 错。不过,单看wordnik的数据规模和访问情况,精心的使用mysql完全可以胜任,只是mongodb可能能更简单的胜任他们的应用场景。 wordnik给出的一些mongodb使用经验值得分享一下。
mongodb is so fast!!!就像“flash”一样!!!这是很多mongodb使用者对它的响应速度的赞叹。在一些场景下,它确实可能如此。mongodb不像其他 db自己管理内存,而是使用操作系统的内存映射文件(memory-mapped file),这使得mongodb省去了复杂的内存管理,也能取得良好的文件cache效果。当内存够大(比如wordnik为mongodb配备了 72GB的内存,是不是可以根据请求数据的分布来度量出多大内存能满足cache的命中率呢?),读请求的数据相对集中,那么mongodb的读速度要卓越的多。如果mongodb恰好能满足你对速度的要求,那么你可以放弃那一层 cache胶水代码了。
wordnik在更新数据时使用了一个trick,它不是直接更新,而是先把要更新的数据读出来(到了内存),然后再更新。就单条数据来说,这种并没有提 高更新速度。不过,因为mongodb的更新使用的是全局锁,这种方式可以减少实际更新时的锁时间。而且,wordnik的更新是异步的,它会控制更新频 率以避免阻塞读请求,而mongodb在读写锁的效率上应该还可以提高。另一方面,如果更新的文档数据超过原来的大小,mongodb会标记删除旧数据追 加新数据,而在无效碎片利用上,mongodb做得似乎不是很好。之前我在使用时,发现经过几次全数据的批量更新后,文件大小会翻番,而大量的碎片又会影响到 cache效果使得读写速度都有下降。因为mongodb的每个colleciton文件都有一些空间留作padding,如果colleciton很 多,相应的总文件大小也会变大。
mongodb的文档模型很给力,编程接口很简洁。所以从关系数据库迁移到文档数据库,相比什么列型数据库,要容易得多。而从编程的对象模型到存储模型的 映射来说,文档模型也要比关系模型更友好。在我使用mongodb过程中,非常喜欢它的文档嵌套性和value的数组类型,一些一对多关系就省去了关系数 据库中新建一个表存储的需要,简化schema的设计。
原文链接:http://www.kafka0102.com/2011/02/430.html