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

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

1、MongoDB也需要DevOps。

MongoDB是一個資料庫。和任何其他的資料儲存一樣，它也需要容量計劃、調整、監控和維護。不要因為它很容易安裝、入門，同時與關係型資料庫相比能夠更加自然地滿足開發人員的範例就認為MongoDB不需要適當的照顧和餵養。開發時它能在小樣本資料集上超快地執行並不意味著你就不需要良好的模式、索引策略以及產品環境所需要的正確的硬體資源了。但是如果你準備的很好，並且理解最佳實踐，那麼運營大型MongoDB叢集就會變得很無聊，而不是令人非常頭痛。

2、成功的MongoDB使用者會監控所有的事情，同時會做好增長的準備。

在任何資料庫系統中跟蹤當前的容量以及容量計劃都是基本的實踐，MongoDB也是如此。你需要知道叢集現在能夠支撐多少工作，最高使用率時它會處理哪些需求。如果你沒有注意到伺服器上增長的負載，那麼最終會遇到沒有足夠容量的錯誤。監控MongoDB可以使用MongoDB管理服務（MMS），通過檢視操作計數器（opscounters）圖表視覺化自己的操作：

3、你可能並不希望系統隨著使用量的增長出現效能擴充套件障礙。

根據大量使用者的部署經驗，效能瓶頸通常是（按順序）：

• 應用程式訪問模式沒有使用最優的模式設計
• 索引不佳或者缺失索引，抑或有太多不必要的索引
• 磁碟較慢/磁碟IOPS不足
• 索引沒有足夠的RAM

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

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”強制它執行。你需要熟悉的唯一一個“特殊的”、由系統產生的集合是分析器集合，定期地分析你的查詢是確保事情按照期望執行的一個非常好的方式。

來自：infoq