大規模運行MongoDB應該知道的10件事

MongoDB的首席解決方案架構師Asya Kamsky 最近發表了一篇文章，歸納了大規模運行MongoDB須要知道的10件事。

1. MongoDB也須要DevOps。MongoDB是一個數據庫。和任何其餘的數據存儲同樣，它也須要容量計劃、調整、監控和維護。不要由於它很容易安裝、入門，同時與關係型數據庫相比可以更加天然地知足開發人員的範例就認爲MongoDB不須要適當的照顧和餵養。開發時它能在小樣本數據集上超快地運行並不意味着你就不須要良好的模式、索引策略以及產品環境所須要的正確的硬件資源了。可是若是你準備的很好，而且理解最佳實踐，那麼運營大型MongoDB集羣就會變得很無聊，而不是使人很是頭痛。

2. 成功的MongoDB用戶會監控全部的事情，同時會作好增加的準備。在任何數據庫系統中跟蹤當前的容量以及容量計劃都是基本的實踐，MongoDB也是如此。你須要知道集羣如今可以支撐多少工做，最高使用率時它會處理哪些需求。若是你沒有注意到服務器上增加的負載，那麼最終會遇到沒有足夠容量的錯誤。監控MongoDB可使用MongoDB管理服務（MMS），經過查看操做計數器（opscounters）圖表可視化本身的操做：

3. 你可能並不但願系統隨着使用量的增加出現性能擴展障礙。 根據大量用戶的部署經驗，性能瓶頸一般是（按順序）：

   事實證實，在真正的大型部署實踐中對性能影響最大的是模式設計與應用程序需求的契合程度。而缺乏索引、索引錯誤或者索引太多則是影響性能的第二大因素。在模式設計很是完美，索引也最優的狀況下，磁盤IO吞吐能力就成了下一個限制因素，尤爲是寫吞吐量。RAM不足會引起不少頁錯誤，同時也會增長磁盤IO的壓力。

• 應用程序訪問模式沒有使用最優的模式設計

• 索引不佳或者缺失索引，抑或有太多沒必要要的索引

• 磁盤較慢/磁盤IOPS不足

• 索引沒有足夠的RAM

4. 不少成功的MongoDB用戶使用單複製集。太早分片多是過早優化，並非每一個MongoDB部署都須要分片。分片處理很是特殊的需求，不能不加思索地認爲它就是解決「數據庫很慢」的最佳方案。若是你的協調模式很是差勁或者有錯誤索引，那麼分片並不能解決問題，相反的你最終會獲得一些差勁的協調和差勁的執行碎片。當單臺機器或者複製集上的某種特殊資源成爲瓶頸，同時基於成本的考慮沒法添加更多這種資源的時候才適合分片。你可能須要更多的磁盤IO吞吐量，或者更多的內存，或者更多的存儲，再或者更多的併發，這種狀況下分片纔是有意義的。

5. 即便沒有將整個數據庫放在內存中，MongoDB依然可以取得很是好的性能。對於MongoDB常見的一個誤解是：爲了得到更好的性能須要將整個數據庫放在內存中。這多是最錯誤的一件事情，由於這依賴於集羣正在處理的負載的類型。有一些標誌和指標可以告訴你：相對於你放到數據庫上的負載類型你所擁有的內存數量是否充足。正如你所看到的，隨着數據庫大小的增加，可以放到內存中的相關部分將會受限於可用物理內存的大小。若是內存的數量不能知足性能需求，那麼你將會看到頁面錯誤，隨着頁面錯誤率的上升，opcounters最終會低於指望值。

6. 必須將數據寫刷新到磁盤。若是磁盤利用率達到了100%，那麼處理更多寫操做的速度比起如今得不到絲毫的提高。能夠經過MMS中的「Background flush average」圖表查看將數據文件中的髒頁刷新到磁盤花費了多長時間。經過這種趨勢你會發現，隨着寫操做的增加，刷新將花費更多的時間。這種問題能夠經過使用更快的磁盤解決，將工做拆分到更多的分片上，或者調整應用程序使之減小寫數據的總量。你應該記住：寫入的全部內容都會被刷新到磁盤兩次——當即刷新到日誌同時週期性地刷新到數據文件。將這兩種操做分離到不一樣的物理設備上將會消除它們對可用磁盤IO帶寬的競爭。 
   

7. 複製 != 備份。全部人都清楚備份的重要性。可是爲何備份這麼重要呢？ 想必是由於當某些影響全部複製集節點的災難性事件發生的時候咱們能夠恢復數據。複製並非備份的緣由是：它並不能讓你避免人爲錯誤——例如某些人忽然刪除了產品數據，或者部署了錯誤版本的應用程序代碼以至於搞亂了部分或者全部數據。必需要有一個可以讓咱們從這種場景中恢復數據的備份。經過文件系統快照、mongodump或者MMS備份練習數據恢復。第一次從備份恢復產品數據的操做不該該發生在真正的「數據緊急事件」發生的時候。

8. 複製集的健康不只僅是複製延遲。「複製延遲」僅僅是複製集健康情況的指標之一。關注複製操做日誌（oplog）窗口和監控複製延遲同樣重要。它表示的是基於如今的寫流量徹底「滾動」oplog所要花費的時間。換句話說，它指的是將一個複製節點拿下來之後依然可以從新加入集合而沒必要對全部數據進行從新同步的時間。隨着時間的推移，複製操做日誌窗口將會隨着寫負載的變化而浮動。流量高峯時窗口會縮短。這在容量計劃中是很是重要的，你須要爲最繁忙的數據吸取時間作好準備。下面是MMS中的一個並行視圖，它展現了整個複製集的複製操做日誌窗口。

9. MongoDB並不清楚數據須要什麼樣的安全級別。和其餘數據庫同樣，你應該遵循最小特權原則。必須本身配置數據庫的安全。不要讓全部人都能訪問你的數據。打開MongoDB本身自己的安全機制是很是重要的，可是這樣也鎖定了從任何地方對集羣的訪問，除非你確實認爲本身的客戶端進程能夠在那裏運行。只修改MongoDB進程的默認端口並不能保證安全。

10. 不必修改引擎裏面的東西。 除非文檔或者MongoDB支持告訴你作一些很是特殊的事情，不然你沒有必要直接修改系統集合、本地、管理或者配置數據庫。你能夠藉助於管理命令和shell執行所需的操做，若是數據庫並不能按照指望運行，或者某些地方發生了錯誤，那麼成功的鑰匙並非試圖經過直接操做內部的「bits」強制它運行。你須要熟悉的惟一一個「特殊的」、由系統產生的集合是分析器集合，按期地分析你的查詢是確保事情按照指望運行的一個很是好的方式。

---

感謝程顯峯對本文的審校。