大規模運行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”強制它運行。你需要熟 悉的唯一一個“特殊的”、由系統產生的集合是分析器集合，定期地分析你的查詢是確保事情按照期望運行的一個非常好的方式。
        感謝程顯峰對本文的審校。

                    <span id="shareA4" class="fl">                          </span> 

</div>