為首次部署MongoDB做好準備：容量計劃和監控

如果你已經完成了自己新的MongoDB應用程式的開發，並且現在正準備將它部 署進產品中，那麼你和你的運營團隊需要討論一些關鍵的問題：

最佳部署實踐是什嗎？

為了確保應用程式滿足它所必須的服務層次我們需要監控哪些關鍵計量？

如何能夠確定添加分區的時機？

有哪些工具可以對資料庫進行備份和恢複？

怎樣才能安全地訪問所有新的即時大資料？

本文介紹了硬體選擇、擴充、HA和監控。在查看詳細資料之前，首先讓我們處 理一個最常見的問題：

部署MongoDB和部署RDBMS有什麼不同？

你會發現MongoDB作為一個文檔資料庫，它和你已經熟悉的關係型資料庫分享 了很多同樣的概念、操作、策略和過程。監控、索引、調整和備份等內容的流程 和最佳實務可以應用到MongoDB。同時如果你想要開始自己的培訓，那麼可以從 MongoDB大學中擷取到來自於開發人員和DBA的免費線上課程。

系統效能和容量規劃是兩個重要的主題，任何部署都需要處理這兩個問題，無 論是RDBMS還是NoSQL資料庫都是如此。作為規劃的一部分我們應該對資料卷 （volume）、系統負載、效能（輸送量及延遲時間）和容量利用建立基準。這些 基準應該反映你對資料庫在產品環境中執行的工作負載的期望，它們應該隨著用 戶數、應用程式功能、效能SLA或者其他因素的變化定期地調整。

基準將協助你理解系統哪些時候是按照設計啟動並執行，哪些時候可能會影響使用者 體驗品質或者其他決定性系統因素的問題開始浮現。

下面將會討論關鍵的部署要素，包括硬體、擴充和HA，同時還會討論為了維持 最佳的系統效能你應該監控哪些內容。

清楚自己的工作集

在為部署MongoDB最佳化硬體預算的時候，RAM應該是或者接近於列表的第一位。

為了實現低延遲的資料庫操作MongoDB中廣泛使用了RAM。在MongoDB中，所有 的資料都是通過記憶體對應檔讀取和操作的。從記憶體中讀取資料是使用納秒來度 量的，而從磁碟中讀取資料則是使用毫秒度量的，所以從記憶體中讀取資料幾乎比 從磁碟中讀取要快了十萬倍。

在正常操作期間最頻繁訪問的資料和索引的集合稱為工作集，在理想的情況下 它們應該在RAM中。工作集可能是整個資料庫的一小部分，例如最近的事件所關聯 的應用程式資料或者最常訪問的熱門產品。

MongoDB試圖訪問資料時發生的分頁錯誤並不會被載入到RAM中。如果有空閑內 存，那麼作業系統將定位到磁碟上的頁面並將它們直接載入到記憶體中。但是如果 沒有空閑記憶體，那麼作業系統必須將記憶體中的一個頁面寫入磁碟，然後將被請求 的頁面讀取到記憶體中。這個流程比訪問已經存在於記憶體中的資料要慢。

有些操作可能會在不經意間從記憶體中清除大量的工作集，這樣會對效能產生嚴 重影響。例如，對於一個瀏覽資料庫中所有文檔的查詢而言，如果資料庫比服務 器上的RAM大，那麼將會導致文檔被讀入記憶體而工作集被寫出到磁碟。在項目的模 式設計階段為自己的查詢定義合適的索引將會極大地降低這種風險發生的可能性 。MongoDB說明操作能夠為查詢計劃和索引的使用提供資訊。

MongoDB服務狀態命令中包含了一個有用的輸出：工作集文檔，它提供了一個 MongoDB執行個體工作集的估算大小。運營團隊可以按照給定的時間跟蹤執行個體訪問的頁 面數，包括工作集中最舊的文檔到最新的文檔之間的已耗用時間。通過跟蹤這些指 標我們能夠發現什麼時候工作集會接近現在的RAM限制從而積極地採取行動確保系 統是可擴充的。

MongoDB管理服務和mongostat能夠協助使用者監控記憶體的使用方式，下面我們將 會對此進行詳細地討論。

儲存和磁碟I/O

MongoDB不需要共用儲存（例如存放區域網路）。MongoDB能夠使用本地附加的 儲存和固態硬碟（SSD）。

MongoDB中的大部分磁碟訪問模式並沒有順序屬性，這樣做的結果便是客戶可 以通過使用SSD獲得巨大的效能收益。我們已經觀察到使用SATA SSD和PCI獲得的 良好結果和強大的效能。商業SATA旋轉磁碟機可以媲美成本更高的旋轉磁碟機， 這得益於MongoDB的非順序訪問模式：應該更有效地使用預算將其用於更多的RAM 或者SSD上，而不是更多地用於昂貴的旋轉磁碟機上。

在資料檔案受益於SSD的同時，MongoDB的日記檔案由於其自身的高順序的寫屬 性成為了快速常規磁碟的一個很好的候選。

大多數MongoDB部署應該使用RAID-10。RAID-5和RAID-6沒有提供足夠的效能。 RAID-0提供了很好的寫效能，但是讀效能有限，容錯能力也不足。部署的MongoDB 可以通過複本集（下面將會討論）提供很強的資料可用性，同時使用者應該考慮使 用RAID和其他因素滿足想要的SLA可用性。

雖然我們應該設計MongoDB系統讓它的工作集適合於記憶體，但是磁碟I/O依然是 一個關鍵的效能考慮。MongoDB會定期地將寫操作重新整理到磁碟並提交到日記，所以 在寫負載較重的時候基礎的磁碟子系統可能會變得不堪重負。iostat命令可以用 於顯示高磁碟利用率和過多的寫隊列。

CPU選擇——速度還是核心？

MongoDB的效能通常不會綁定到CPU上。因為MongoDB很少會遇需要利用大量內 核的工作負載，比起時脈速度較慢的多核伺服器最好的選擇是有更快的時脈速度 。

無論是什麼系統，測量CPU的利用率都是非常重要的。如果觀察到CPU的利用率 很高但是並沒有出現磁碟飽和或者分頁錯誤這樣的其他問題，那麼系統中可能會 存在不尋常的問題。例如，一個存在無限迴圈的MapReduce工作或者一個沒有建立 良好索引就對工作集中的大量文檔進行排序和過濾的查詢都可能會導致CPU利用率 的飆升，但是它們卻不會引發磁碟系統問題或者分頁錯誤。用於監控CPU利用率的 工具將在下面介紹。

擴充資料庫——何時擴充和如何擴充？

MongoDB通過一種稱為Sharding的技術提供了水平擴充能力。Sharding能夠在 多個物理分區（稱為片）之間分發資料。Sharding可以讓MongoDB的部署解決單個 伺服器的硬體限制而不需要增加應用程式的複雜性，解決的硬體限制包括RAM和磁 盤I/O的瓶頸。