MongoDB - 架構最佳作法

部署策略

當您計劃部署 MongoDB 時，您需要考慮幾個關鍵領域。 最重要的是現行及預期的資料集大小。 這兩個區域是您選擇的個別實體節點資源需求的主要動機，並引導進行 Shard 處理方案。 您也需要考量資料重要性，以及您對遺失或落後資料的容忍程度（特別是抄寫的情境）。

記憶體大小

MongoDB (就像許多以資料為導向的應用程式一樣），當資料集停留在記憶體中時，效果最佳。 沒有比不需要磁碟 I/O 的 MongoDB 實例更好的效能。 可能的話，請選取具有比工作資料集大小更多可用 RAM 的平台。 如果您的資料集超過單一節點的可用 RAM，則請考慮利用 Shard 處理。 Shard 處理可增加叢集中的可用 RAM 數量，以容納較大的資料集。 因此，您可以最大化整體部署效能。 分頁錯誤可能表示您可能超出部署中的可用 RAM。 您需要考量增加可用 RAM。

磁碟類型

如果速度不是重點，或您的資料集大於可用記憶體策略可支援的大小，則部署的適當磁碟類型十分重要。 IOPS 是選取磁碟類型的關鍵。 IOPS 越高，MongoDB 的效能就越好。 因為網路儲存空間可能導致部署的高延遲及效能不佳，所以如果可能的話，需要使用本端磁碟。 建議您將 RAID 10 用於磁碟陣列。

CPU

如果您要使用 map-reduce，則需要考量時鐘速度及可用處理器數目。 不過，當您使用記憶體中的大部分資料執行 MongoDB 實例時，時鐘速度可能會影響效能。 如果您的系統在這些情況下執行，而且您希望每秒的作業次數達到最高，請考慮採用包含高時鐘匯流排速度 CPU 的部署策略。

抄寫

如果叢集中的節點失敗，則抄寫可提供資料的高可用性。 若要取得最佳結果，請在任何 MongoDB 部署中至少抄寫三個節點。 含三個節點的抄寫的最常見配置是 2x1 部署，即單一資料中心內有兩個主要節點，而次要資料中心內有一部備用伺服器。

Shard 處理

[:#dbt-sharding]

如果您預期是大型資料集，則建議部署已 Shard 處理的 MongoDB 部署。 您可以使用分區來跨多個節點分割資料集。MongoDB 可以自動將資料配送至叢集中的節點。 或者，您可以定義 Shard 索引鍵，並建立該索引鍵的範圍型 Shard 處理。 Shard 處理有助於寫入效能，因此您可以進行 Shard 處理，即使資料集很小但需要大量更新或插入。 當您部署已 Shard 處理的集合時，MongoDB 只需要三個配置伺服器實例，即特殊化 Mongo 運行環境以追蹤現行 Shard 配置。 損失其中一個節點會導致群集進入配置的唯讀模式，並要求在進行任何配置變更之前，所有節點都必須恢復連線。

寫入安全模式

您有多個選項可撰寫安全模式，以控管 MongoDB 如何將資料持續保存至磁碟。 請務必考量哪一種策略最符合您的資料完整性及效能需求。 您有下列寫入安全模式可用：

• None- 提供非阻塞的延遲寫入策略，有助於提高效能。 不過，節點故障和資料流失可能是很小的可能性。 寫入群集中一個節點的資料也有可能無法立即在該群集的所有節點上達到讀取一致性。 「無」模式未提供網路失敗的任何資料保護。 此模式高度不可靠，而且只有在效能是優先考量而資料完整性不重要時才能使用。
• 標準 – 是 MongoDB 的預設值。 正常模式也是一種非阻塞遞延寫入策略。
• Safe- 阻塞直到 MongoDB 確認收到寫入要求，但會阻塞直到寫入完成。 安全模式提供叢集內的較佳資料完整性及讀取一致性層次。
• 日誌登載安全 – 提供 MongoDB 的回復選項。 Journal Safe（日誌安全）模式可確保資料已被確認，且日誌更新完成後才會返回。
• Fsync – 提供最高的資料完整性層次，並封鎖直到實體寫入資料為止。 使用 Fsync 附帶效能退化，而且只有在資料完整性是應用程式的主要重點時才能使用它。

測試部署

10gen 有數個工具可協助您負載測試部署。 一個控制台工具，benchRun,可以從一個內部運行操作JavaScript測試線束。benchRun傳回每個操作的操作資訊和延遲數。 如果需要 MongoDB 實例的其他詳細資訊，請考慮在測試期間執行 mongostat 指令或 MMS 來監視部署。

安裝

當您安裝 MongoDB 時，有幾個考量可協助您建立穩定且效能導向的解決方案。10gen 建議您儘可能使用 CentOS (64 位元)。 請避免部署於 32 位元作業系統及 Windows 作業系統。 這些系統提供的部署平台不佳。32 位元作業系統的檔案大小限制會造成問題，如果作業系統使用虛擬記憶體來彌補部署中 RAM 的不足，Windows 可能會造成效能問題。 依預設，IBM Cloud 提供 CentOS 64 位元作業系統進行所有工程伺服器部署。

此外，請確定您對基礎 OS 安裝進行下列變更，以最大化效能：

• 將 SSD 先讀預設值設為 16 個區塊 – SSD 磁碟機有絕佳的探查時間，容許將「先讀」收縮為 16 個區塊。 旋轉磁碟可能需要少量緩衝，因此這些磁碟設為 32 個區塊。
• noatime – Noatime 讓系統不需要寫入至要讀取之檔案的檔案系統。 這意味著您將體驗到更快的檔案存取速度和更少的磁碟損耗。
• 在 BIOS 中關閉 NUMA Linux, NUMA 和 MongoDB 通常無法一起運作。 如果您是在 NUMA 硬體上執行 MongoDB，則建議將它關閉（使用交錯記憶體原則執行）。 如果不是，則可能會出現明顯變慢或高系統 CPU 時間這類問題。
• 設定 ulimit – 已開啟檔案的 ulimit 設為 64000，而使用者處理程序的 ulimit 則設為 32000。 這些 ulimit 可防止因遺失可用檔案控點或使用者處理程序所造成的失敗。
• 使用 ext4 – 在配置檔案（或移除它們）時，ext3 太慢。 此外，使用 ext3 執行大型檔案內的存取不佳。

預設情況下，這些變更會設定在所有 IBM Cloud 伺服器上。

同時建議使用「日誌登載」及「資料」磁區作為特殊實體磁區。 如果「日誌登載」及「資料」目錄位在單一實體磁區上，則清除至「日誌登載」會岔斷資料存取，並提供 MongoDB 部署內的高延遲驟增。

Operations

在 MongoDB 部署升級至正式作業之後，請考量下列建議以進行監視及效能最佳化。

• 請確定 MMS 代理程式正在 MongoDB的所有實例上執行，這有助於監視部署的性能及效能。 MMS 代理程式會在支援互動期間將有用的除錯資料提供給 10gen。
• mongostat 指令也提供有關 MongoDB 節點效能的運行環境資訊。

如果任一個工具發現效能問題，則 Shard 處理或編製索引有助於更正這些效能問題。

• 如果監控工具顯示基於欄位的查詢運作不佳，請為 MongoDB 部署建立索引。 為了協助改善效能，請一律在您查詢基於特殊欄位的資料時使用索引。
• 當結點的整體效能因大量作業資料集而受到影響時，請使用分片。 在您無法再進行之前，請務必進行 Shard 處理。 只有在插入或更新時，系統才會分割片段以進行 Shard 處理。 如果您在進行 Shard 處理時等待太長的時間，則可能分佈不平均。