MongoDB的容量規劃及硬體設定

標籤：style   http   tle   兩台   瞭解   離線   參數   方法   大量   

 

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的工作集，他們仍然決定承擔插拔所帶來的任何後果。他們保留了增加第四個分區以維持記憶體中更多工作集的可能性。

從這些案例學到的硬體設定教程

1. 對於讀密集型應用，規劃好伺服器大小以保證在記憶體中能支撐整個工作集並且進行複製以得到更高的可用性。
2. 如果你伺服器的記憶體（RAM）不能夠保證在記憶體中容納工作集，進行分區以從多個複本叢集中整合記憶體（RAM）。
3. 使用與部署相同的伺服器硬體建立一個概念驗證系統。通過這個方法，你可以在你的概念驗證系統中配置和測試一個伺服器。接著，你可以根據需要，在擴充一個複製集或者增加一個分區進行拓展時，直接將其放入部署系統中。

 

MongoDB的容量規劃及硬體設定