# 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 嗎？