文/赵劼
Wordnik是一项在线字典及百科全书服务，在大约一年前，它们逐渐开始从MySQL迁移至文档型数据库MongoDB，后者是著名的NoSQL产品之一。最近Wordnik的技术团队通过官方博客分享了这12个月来使用MongoDB经验及现状。
据Wordnik技术团队描述，它们起初决定使用MongoDB，是看中了它的弱一致性（最终一致）及文档结构的存储方式。
在传统的关系型数据库中，一个COUNT类型的操作会锁定数据集，这样可以保证得到“当前”情况下的精确值。这在某些情况下，例如通过ATM查看账户信息的时候很重要，但对于Wordnik来说，数据是不断更新和增长的，这种“精确”的保证几乎没有任何意义，反而会产生很大的延迟。他们需要的是一个“大约”的数字已经更快的处理速度。
此外，Worknik的数据结构是“层级”式的，如果要将这样的数据使用扁平式的，表状的结构来保存数据，这无论是在查询还是获取数据时都十分困难：
就拿一个“字典项”来说，虽然并不十分复杂，但还是会关系到“定义”、“词性”、“发音”或是“引用”等内容。大部分工程师会将这种模型使用关系型数据库中的主键和外键表现出来，但把它看作一个“文档”而不是“一系列有关系的表”岂不更好？使用“dictionary.definition.partOfSpeech='noun'”来查询也比表之间一系列复杂（往往代价也很高）的连接查询方便且快速。
经过了一年的使用，Worknik描述了他们从MySQL全面迁移至MongoDB后的感受。
首先是性能上的提高，这也是使用MongoDB的主要原因。MongoDB解决了Worknik在使用MySQL的时候，在存储和数据查询时都遇到的一些问题。下面是一些统计数据：
Worknik表示，在压力较高的情况下，MongoDB的内置缓存机制，让系统对memcached层的每次调用节省了1-2ms，同时还剩下了许多GB的内存。此外，所有的数据不可能都在内存中，因此获取示例的60ms还包括磁盘访问时间。
其次，使用MongoDB还带来了许多灵活性，除了之前提到的文档型存储让查询变得十分迅速之外，MongoDB还带来了其他一些好处。例如以前Worknik使用集群文件系统保存音频文件，如今这些文件保存在MongoDB的GridFS中。这给IT维护带来了许多方便，例如可以使用相同的方式来维护数据和文件内容，数据库和文件也是保持同步的。
Worknik对MongoDB的可靠性也很满意，从四月起，MongoDB只重启了两次，一次是从1.4.2版升级到1.4.4版，还有一次是由于数据中心断电。
唯一可能的抱怨是对于维护性上的。MongoDB没有如MySQL那样成熟的维护工具，这对于开发和IT运营都是个值得注意的地方。不过幸运的是，MongoDB提供了许多“接入点”，因此Worknit创建了一些辅助工具，并打算开源，他们表示将在十二月份的MongoSV上提供更多信息。
在运营过程中，数据中心断电造成了很大的问题。由于断电发生在写密集的情况下，因此对主从节点都造成了损害。当时主节点正忙于将数据写回磁盘，而从节点正在通过日志获取数据。在电力回复之后，他们花费了超过24小时了来修复主节点上的数据，在这段时间内，他们将从节点提升为主节点使系统得以正常工作。
最后，Worknik还分享了一些经验：
数据尺寸：在四月份的MongoSF会议上，我们曾抱怨MongoDB耗费了4倍的数据空间。之后10gen指出了MongoDB的集合填充机制，以及Worknik某些使用场景上造成的浪费。我们将一些对象作为子文档存储，并去除一些索引之后，则大约使用了MySQL的1.5至2倍的存储空间。
锁：某些情况下MongoDB会锁住数据库。如果此时正有数百个请求，则它们会堆积起来，造成许多问题。我们使用了下面的优化方式来避免锁定：
- 每次更新前，我们会先查询记录。查询操作会将对象放入内存，于是更新则会尽可能的迅速。在主/从部署方案中，从节点可以使用“-pretouch”参数运行，这也可以得到相同的效果。
- 使用多个mongod进程。我们根据访问模式将数据库拆分成多个进程。
相关文章
