Wordnik的MongoDB使用經驗

 相關地址:

 

  http://www.infoq.com/cn/news/2010/11/wordnik-mongodb

 

http://www.10gen.com/

 

http://www.mongodb.org/

 

 

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提供商業支持

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章