mongo是基於內存的數據庫，應盡量將工作集中的數據全部加載到內存中，即內存應大於工作集
本文譯自Chad Tindel的英文博客： http://www.mongodb.com/blog/post/capacity-planning-and-hardware-provisioning-mongodb-ten-minutes 。
大部分MongoDB部署都運行於多台服務器的集群中，相對於傳統數據庫，這增加了容量規划及配置方面的復雜性。系統架構師 Chad Tindel 在MongoDB 世界大會上的硬件配置演講 中為實施團隊提供了規划MongoDB部署大小的最佳實踐。
這里有兩個與MongoDB架構相關的重要概念能夠幫助理解該演講：
- 分片。 分片即MongoDB在服務器之間划分數據的一項技術。MongoDB能夠自動在分片之間平衡數據，並且能夠在不需要數據庫離線的情況下增加和刪除分片。
- 復制。 為了保證高可用性，MongoDB維護了許多數據的冗余備份。復制被嵌入於MongoDB，並且在不需要專業網絡的情況下就可以在廣域網內工作。
Chad在演講開始的時候提到了一些需要記住的重要建議，然后提到了一些用戶案例：
- 預先列出你的性能需求。 確定你需要存儲的數據量。通過分析查詢來估計你一次需要讀取的數據量，從而確定工作集的大小。計算生產環境中你希望在每秒時間內發送的請求數目，設置好要求的正常運行時間百分比，確定你可以忍受的延遲時間。
- 計划一個PoC概念驗證測試。
MongoDB的可擴展性允許你在10%-20%的硬件上使用10%-20%的數據運行應用。通過使用這個方法，你可以進行模式、索引設計並且了解查詢模式，然后重新定義你估計的工作集大小。在一台機器上檢測性能，然后在必要的情況下增加復制和分片。將這種配置作為一個沙盒，用於測試該應用的連續修訂版本。
你可以通過在MongoDB中執行下面的命令來估計您的工作集大小
db.runCommand( { serverStatus: 1, workingSet: 1 } )
- 使用真實的工作負載進行測試。 向上拓展概念驗證測試，但是直到使用真實世界的數據以及性能要求進行大量測試之后才開始部署。
- 基於新的需求不斷監測和調整。 用戶數量的增加經常會帶來更多查詢以及一個更大的工作集，新索引也會促使一個更大的工作集。應用可能會隨着時間的變化而改變它的讀寫比例。像MongoDB管理服務（MMS）以及mongoperf之類的工具幫助你監測系統性能參數的改變。需求改變的同時，你可以調整你的硬件配置。請注意：通過使用MongoDB，你可以不必關閉數據庫而增加和刪除分片或復制集。
Chad接着在演講中展示了兩個真實的用戶案例。
案例 #1 ：某西班牙銀行
該銀行希望存儲6個月的日志。每個月的數據需要3TB的空間。那么6個月的數據需要使用6 x 3 = 18 TB的空間。他們知道他們希望分析上個月的日志，因此工作集的大小被設為：1個月的數據（3TB）加上索引（1TB），即一個4TB的工作集。
在概念驗證環境中，他們選擇使用約10%的數據（2TB）。生產需求需要一個4TB大小的工作集，4TB/18TB數據再乘上我們2TB的概念驗證數據，從而得到444GB的概念驗證工作集大小。用戶最多只能提供每台128GB容量的服務器，因此在概念驗證環境中，他們選擇采用4個分片，每個分片有128G存儲。4 x 128GB = 512GB能夠滿足444GB的要求。每個分片上用於讀取可用性及冗余的3個復制集成員為我們提供了4 x 3 = 12台物理機器。兩台應用服務器運行mongos，虛擬機上的三台配置服務器進行概念驗證配置。
為滿足在128GB的服務器中存放4TB部署工作集及18TB數據，他們選擇分割成36個分片，每個分片有128GB的內存（RAM）及512GB的可用存儲。總的看來：一共有36 * 128GB = 4.6TB內存（RAM）， 36* 512GB =18TB的可用存儲。和上面的概念驗證系統一樣，他們用2台應用服務器上運行mongos，在虛擬機上運行3台配置服務器。同上，每個分片有一個三節點的復制集，那么36 分片* 3 復制集節點= 108 台物理機。
注意：MongoDB允許概念驗證及生產配置使用相同的、配置有128GB內存（RAM）及512GB可用存儲的標准硬件結構單元。這樣就允許用戶在將真實的生產節點添加進生產集群之前在概念驗證集群中進行測試。
案例 #2 ：大型在線零售商
該零售商希望將他們的產品目錄從SQL Server中遷移到MongoDB中。MongoDB在存儲目錄信息方面有很大的優勢。不像SQL數據庫，MongoDB的動態模式可以為每個產品存儲不同的屬性，並且不需要在那些不存儲相同信息的其它產品信息中強制放置一個空白的字段占位符。
該零售商希望分別為東、西海岸的顧客建立自己的數據中心，因此他們選擇運行一個主動/主動配置。他們只在晚上最空閑的時間批量寫入新的或者被修改的目錄。在使用的峰值只執行讀取操作。
他們有4,000,000產品庫存單位，每一個都有平均30KB大小的JSON文檔。他們需要為一個特定產品通過_id或者像“桌子”或“硬件驅動”之類的類別提供搜索查詢服務。大多數類別請求將會檢索平均大概72個文檔。一個追蹤該類別樹所有鏈接的搜索引擎爬蟲將會檢索200個文檔。
計算結果顯示：平均每個產品都會出現在2個類別中。該零售商最初想根據類別進行分片，在多個類別中同時出現的產品進行重復存儲。平均屬於兩個類別的4,000,000產品乘上30KB每庫存單位為：8,000,000 乘上 30KB 等於240GB加上30GB索引，一共270GB數據。
MongoDB咨詢工程師建議該零售商使用不分片的復制集，因為該應用需要很高的讀取性能，但是只需要在空閑時間進行單獨的批量寫操作。整個270GB的工作集適合存放於該零售商希望使用的大型思科UCS服務器的384GB可用內存中，不需要在分片之間分割內存工作集，因此簡化了他們的部署架構。
MongoDB工程師推薦 使用一個4節點的復制集橫跨2個數據中心，在一個第三方位置建立一個投票機作為從節點以防主服務器出現故障。這樣就會允許每個數據中心的任一服務器都可以關機維護或者出現故障的情況下，其它服務器還能夠正常運行。Mongos的“最近讀取”查詢調節器將會基於最近延遲選擇最近的服務器。
然而，令人吃驚的是，該零售商決定在他們公司的VMWare雲平台上而不是他們的大型思科服務器上部署該系統。他們的IT部門不會提供任何一個內存（RAM）超過64GB的VMWare節點。為了解決64GB的限制，他們部署了3個分片，每個分片上部署4個節點（兩個東海岸、兩個西海岸加上投票機）：64GB x 3 = 192GB。盡管這樣不能夠維持270GB的工作集，他們仍然決定承擔插拔所帶來的任何后果。他們保留了增加第四個分片以維持內存中更多工作集的可能性。
從這些案例學到的硬件配置教程
- 對於讀密集型應用，規划好服務器大小以保證在內存中能支撐整個工作集並且進行復制以得到更高的可用性。
- 如果你服務器的內存（RAM）不能夠保證在內存中容納工作集，進行分片以從多個復本集群中整合內存（RAM）。
- 使用與部署相同的服務器硬件創建一個概念驗證系統。通過這個方法，你可以在你的概念驗證系統中配置和測試一個服務器。接着，你可以根據需要，在擴展一個復制集或者增加一個分片進行拓展時，直接將其放入部署系統中。