# Wordnik-MongoDB 和 Scala 上每天有 1000 万个 API 请求 > 原文： [http://highscalability.com/blog/2011/2/15/wordnik-10-million-api-requests-a-day-on-mongodb-and-scala.html](http://highscalability.com/blog/2011/2/15/wordnik-10-million-api-requests-a-day-on-mongodb-and-scala.html)  [Wordnik](http://www.wordnik.com/) is an online dictionary and language resource that has both a website and an API component. Their goal is to *show you as much information as possible, as fast as we can find it, for every word in English, and to give you a place where you can make your own opinions about words known.* As cool as that is, what is really cool is the information they share in their [blog](http://blog.wordnik.com/) about their experiences building a web service. They've written an excellent series of articles and presentations you may find useful: * [最近使用](http://blog.wordnik.com/what-has-technology-done-for-words-lately) ne 的技术是什么？ * **最终一致性**。 使用最终一致的模型，他们可以并行工作，*我们会尽可能地统计尽可能多的单词，并在出现滞后时将它们加起来。 计数总是在球场上，我们永远不必停止* .D * **面向文档的存储**。 字典条目更自然地建模为分层文档，使用该模型可以更快地找到数据，并且更易于开发。 * [与 MongoDB 合作 12 个月](http://blog.wordnik.com/12-months-with-mongodb) * 迁移到 MongoDB 的主要驱动因素是性能。 MySQL 不适用于他们。 * Mongo 平均每小时处理 50 万个请求。 高峰流量是该流量的 4 倍。 * > Mongo 中有 120 亿个文档，每个节点的存储量约为 3TB * 可以轻松维持 8k 文档/秒的插入速度，经常达到 50k /秒 * 一个 Java 客户端可以维持通过后端（千兆位）网络读取到一个 mongod 的 10MB / sec 的速度。 来自同一客户端的四个读取器通过同一管道以每秒 40MB 的速度传输 * 每种类型的检索都比 MySQL 实现快得多： * 示例提取时间从 400ms 减少到 60ms * 字典条目从 20ms 到 1ms * 文档元数据从 30 毫秒到.1 毫秒 * 拼写建议从 10 毫秒到 1.2 毫秒 * Mongo 的内置缓存使他们可以删除 memcached 层并将呼叫速度提高 1-2ms。 * [从 MySQL 到 MongoDB-迁移到实时应用程序](http://www.slideshare.net/fehguy/migrating-from-mysql-to-mongodb-at-wordnik)作者：Tony Tam * 他们从 MySQL 迁移到 MongoDB 的经历的解释。 * Wordnik 存储单词，层次结构数据和用户数据的语料库。 MySQL 设计要复杂得多，并且需要复杂的缓存层才能良好地运行。 使用 MongoDB，系统速度提高了 20 倍。 现在不再需要连接，也不需要缓存层。 整个系统更加简单。 * Wordnik 主要是一个只读系统，并且性能主要受磁盘速度限制。 * 他们使用具有 72GB 内存的双四核 2.4GHz 英特尔 CPU。 它们是物理服务器，处于主从模式，并且在 DAS 上使用 5.3TB LUN。 他们发现虚拟服务器没有所需的 IO 性能。 * [通过 MongoDB 保持亮灯](http://www.slideshare.net/fehguy/mongo-sv-tony-tam)作者：Tony Tam * 关于他们如何使用和管理 MongoDB 的演示。 * [Wordnik API](http://blog.wordnik.com/wordnik-api-has-gone-beta) * 他们已经在 Scala 中重写了 REST API。 Scala 帮助他们删除了很多代码，并在整个 API 中标准化了“特征”。 * [](http://blog.wordnik.com/wordnik-api-has-gone-beta)[MongoDB 管理工具](http://blog.wordnik.com/mongoutils) * Wordnik 已经构建了一些工具来管理 MongoDB 的大型部署并已开源。 * [Wordnik 克服了 Hadoop 的处理瓶颈](http://www.cloudera.com/blog/2011/02/wordnik-bypasses-processing-bottleneck-with-hadoop/) * 每秒增加 8000 个单词。 * Map-reduce 作业在 Hadoop 上运行，以减轻 MongoDB 的负担并防止任何阻塞查询。 数据仅是追加数据，因此没有理由使用 MongoDB。 * 其数据的增量更新存储在平面文件中，该文件定期导入 HDFS。 Overall impressions: * Wordnik 有一个非常具体的问题要解决，并着手寻找可以帮助他们解决该问题的最佳工具。 他们愿意围绕发现的所有错误进行编码，并弄清楚如何使 MongoDB 最适合他们。 性能要求推动了一切。 * 在获得性能之后，文档数据模型的自然性似乎是他们最大的胜利。 轻松地对复杂数据进行分层建模并使其表现良好的能力在整个系统中得到了体现。 * 现在的代码是：更快，更灵活且更小。 * 他们选择了专门的工具来完成这项工作。 MongoDB 负责运行时数据的文档存储。 Hadoop 负责分析，数据处理，报告和基于时间的聚合。 Definitely an experience report worth keeping an eye on. 据我所知，Wordnik 是一个只读的应用程序，不需要太多的一致性。 如文章中所述，“他们有一个特定的问题”。 NoSQL 迷们，请不要简单地使用它来攻击 MySQL。 :-) 高峰使用率为 2M req / hr。 只需 550 req / sec。 真的不是那么多。 我已经看到 MySQL 的吞吐量要比那高得多。 如果他们甚至不能使 MySQL 仅执行 550 req / sec，我敢打赌他们只是设计不好的数据库 @John，我们在 mysql 上遇到的问题是大量读取和写入的结合。 结合 550 req / sec + 8k 插入/ sec，方程式将发生巨大变化。 我已经说过很多次了，很可能有人已经调整了我们的 mysql 部署来支持这一点。 我们使用 mongodb 轻松地自己完成了此操作，并且在此过程中获得了许多巨大的好处，如博客文章所述。 它不是读 500k / s 而不是 500 / s 吗？