夜说mongodb

听老歌

夜说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的设计。

如果有一天21

谢谢分享