為 Mongo DB 確定 EC2 實例類型和卷 IOPS
我們的 Mongo(v2.6.3) 中有500GB數據，包括索引。
我們目前在 AWS m3.large (8GB RAM) 實例上執行它。是的，單機。
我們的 MongoDB Cloud Manager 顯示以下統計資訊：
Opcounters - 1.5k
背景刷新平均值 - 5s
非映射虛擬記憶體 - 2GB
鎖定百分比 - 15%
BTree - 6k
連接 - 2k
隊列 - 100
記錄統計 - 200
頁面錯誤 - 1k
由於數據以每月 40GB的速度快速增長，我們的 Mongo 在過去幾個月變得越來越慢。
我們確信現在是擴大規模的時候了。我們很難決定是水平還是垂直縮放它。我們當時的決定是現在讓我們垂直擴展。六個月後，由於我們將在人員方面擁有更多頻寬（目前我們是一個非常小的團隊），我們將橫向擴展它。我們很想听聽您對這個決定的看法。
此外，我們最大的困惑是在選擇硬體方面。我們有以下選擇：
AWS Ec2 r3.large - 2 CPU Cores - 15GB RAM AWS Ec2 r3.xlarge - 4 CPU Cores - 30GB RAM我們將使用1.5TB卷，但仍然對我們需要保留的 IOPS 數量感到困惑。
希望得到您的意見和寶貴的建議。
您應該能夠在 AWS 的監控頁面上查看您目前的 IOPS - 至少對於 RDS 實例可以。
如果這是 EC2 而不是 RDS（RDS 由 EC2 實例支持），您可能需要為這些實例啟用增強監控。
在 AWS 上，您可以非常輕鬆地更改實例的類型。因此，為了安全起見，您可以從更強大的類型開始，如果您發現它確實沒有使用任何資源，則將其降級。
在 AWS 上，選擇實例時，您可以在監控選項卡上找到磁碟讀/寫操作。
在某個時刻需要水平縮放。建議首先使用 2 個分片，每個分片在不同的可用區中都有一個主實例和一個輔助實例。要完成對您的副本的投票，請為每個副本集創建一個帶有仲裁器的小型實例。
- shardA_repl1
- shardA_repl2
- shardB_repl1
- shardB_repl2
- 仲裁者A_仲裁者B
在這樣的設置中，資源也將被分配。因此，無論您計算什麼，它都會分佈在不同的伺服器上。
寫入初選，閱讀：secondary_prefered。
可以進行許多優化，例如將日誌文件和日誌放在不同的磁碟上，並進行一些 linux 微調。請參閱：https ://docs.mongodb.org/ecosystem/platforms/amazon-ec2/
而且，請查看您的數據、索引和查詢量。是否需要所有數據？是否正確創建了索引？可以優化一些查詢嗎？
當然，花點時間測試您的設置。創建正確的分片鍵，因為您以後無法更改。嘗試關閉其中一個實例，一切都應該繼續執行。閱讀所有優化選項以使用盡可能小的實例。
實用資訊的重要來源： https ://university.mongodb.com/courses/M202/about