Wordnik 的 MongoDB 使用经验

Wordnik 是一项在线字典及百科全书服务，在大约一年前，它们逐渐开始从 MySQL 迁移至文档型数据库 MongoDB，后者是著名的 NoSQL 产品之一。最近 Wordnik 的技术团队通过官方博客分享了这 12 个月来使用 MongoDB 经验及现状。

据 Wordnik 技术团队描述，它们起初决定使用 MongoDB ，是看中了它的弱一致性（最终一致）及文档结构的存储方式。

在传统的关系型数据库中，一个 COUNT 类型的操作会锁定数据集，这样可以保证得到“当前”情况下的精确值。这在某些情况下，例如通过 ATM 查看账户信息的时候很重要，但对于 Wordnik 来说，数据是不断更新和增长的，这种“精确”的保证几乎没有任何意义，反而会产生很大的延迟。他们需要的是一个“大约”的数字以及更快的处理速度。

此外，Worknik 的数据结构是“层级”式的，如果要将这样的数据使用扁平式的，表状的结构来保存数据，这无论是在查询还是获取数据时都十分困难：

就拿一个“字典项”来说，虽然并不十分复杂，但还是会关系到“定义”、“词性”、“发音”或是“引用”等内容。大部分工程师会将这种模型使用关系型数据库中的主键和外键表现出来，但把它看作一个“文档”而不是“一系列有关系的表”岂不更好？使用“dictionary.definition.partOfSpeech=‘noun’”来查询也比表之间一系列复杂（往往代价也很高）的连接查询方便且快速。

经过了一年的使用，Worknik 描述了他们从 MySQL 全面迁移至 MongoDB 后的感受。

首先是性能上的提高，这也是使用 MongoDB 的主要原因。MongoDB 解决了 Worknik 在使用 MySQL 的时候，在存储和数据查询时都遇到的一些问题。下面是一些统计数据：

• MongoDB 承受了平均 50 万每小时的请求（包括周末和夜间），高峰期大约是 4 倍的量。
• MongoDB 中有超过 120 亿个文档。
• 每个节点大约 3TB 数据。
• 一般情况下文档插入速度为每秒 8 千条，峰值为每秒 5 万条。
• 单个 Java 客户端在千兆带宽下，对单个 MongoDB 节点的可持续的传输速度为每秒 10MB。同一个客户端的四个读取器可以保持每秒 40MB 的读取速度。
• 各种形式的查询都比 MySQL 的实现要快许多：
  • 示例的获取速度，从 400ms 减少为 60ms。
  • 字典项获取速度，从 20ms 减少为 1ms。
  • 文档元数据的获取速度，从 30ms 减少为 0.1ms。
  • 拼写提示的获取速度，从 10ms 减少为 1.2ms。

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 进程。我们根据访问模式将数据库拆分成多个进程。

MongoDB 是一个可扩展、高性能的下一代数据库。最新版本为 1.6.3，并由 10gen 提供商业支持。