Amazon DocumentDB 的最佳實踐

了解使用 Amazon DocumentDB 的最佳實務 (與 MongoDB 相容性)。在新最佳實務確定時，會不斷更新此小節。

基本操作準則

以下是每個人在使用 Amazon DocumentDB 時都應遵循的基本操作準則。Amazon DocumentDB 服務等級協議要求您遵循下列準則。

• 在兩個 AWS 可用區域中部署由兩個或多個 Amazon DocumentDB 執行個體組成的叢集。對於生產工作負載，我們建議在三個可用區域中部署由三個或更多 Amazon DocumentDB 執行個體組成的叢集。

• 在指定的服務限制內使用服務。如需詳細資訊，請參閱Amazon DocumentDB 配額和限制。

• 監控您的內存CPU，連接和存儲使用情況。為了協助您維持系統效能和可用性，請設 CloudWatch 定 Amazon 以在使用模式變更或接近部署容量時通知您。

• 當您接近容量限制時擴展您的執行個體。您的執行個體應佈建足夠的運算資源 (亦即CPU)RAM，以因應應應用程式無法預期的需求增加。

• 設定備份保留期以符合您的復原點目標。

• 測試叢集的容錯移轉，以了解您的使用案例執行此程序需時多長。如需詳細資訊，請參閱Amazon DocumentDB 的故障。

• 使用叢集端點 (請參閱Amazon DocumentDB 端點) 和複本集模式 (請參閱) Connect 到 Amazon DocumentDB 叢集，將容錯移轉對應用程式的影響降到最低。連接到 Amazon DocumentDB 作為複本集

• 選擇驅動程式讀取偏好設定，以發揮最大讀取擴展，同時符合您應用程式的讀取一致性要求。secondaryPreferred 讀取偏好設定會啟用複本讀取，並釋出主要執行個體以進行更多工作。如需詳細資訊，請參閱讀取偏好選項。

• 設計您的應用程式，以便在網路和資料庫發生錯誤時，保有故障恢復的應變能力。使用您驅動程式的錯誤機制，區分暫時性錯誤或永久性錯誤。適當時，使用指數退避機制重新嘗試暫時性錯誤。確認您的應用程式在實作重試邏輯時會考慮資料一致性。

• 為所有生產叢集或任何具有重要資料的叢集啟用叢集刪除保護。在刪除 Amazon DocumentDB 叢集之前，請先建立最終快照。如果您使用部署資源 AWS CloudFormation，請啟用終止保護。如需詳細資訊，請參閱終止保護和刪除保護。

• 建立 Amazon DocumentDB 叢集時，引擎版本是選用的參數，預設為最新的主要引擎版本。目前的主要引擎版本為 4.0.0。當新的主要引擎版本發行時，--engine 版本的預設引擎版本將會更新，以反映最新的主要引擎版本。因此，對於生產工作負載，尤其是依賴指令碼、自動化或 AWS CloudFormation 範本的工作負載，我們建議您明確指定預期的主要版本的-Engine 版本。

實例大小

在 Amazon DocumentDB 中選擇執行個體大小最關鍵的方面之一就是快RAM取的數量。Amazon DocumentDB 會RAM為自己的服務保留三分之一的伺服器，這表示只有三分之二的執行個體可供快取使RAM用。因此，選擇足RAM以符合記憶體中工作集 (亦即資料和索引) 的執行個體類型是 Amazon DocumentDB 的最佳實務。具有適當大小的執行個體將有助於最佳化整體效能，並可能將 I/O 成本降至最低。您可以使用第三方 Amazon DocumentDB 大小計算器來估算特定工作負載的執行個體大小。

若要判斷應用程式的工作集是否適合記憶體，請 CloudWatch 針對負載下的叢集中每個執行個體監控BufferCacheHitRatio使用 Amazon 的情況。

此指BufferCacheHitRatio CloudWatch 標會測量從執行個體記憶體快取 (相對於儲存體磁碟區) 提供的資料和索引百分比。一般來說，BufferCacheHitRatio 的數值應該盡可能高，因為從工作集記憶體讀取資料比從儲存磁碟區讀取更快速且更具成本效益。儘管盡可能保持 BufferCacheHitRatio 接近 100% 是理想的做法，但是最可能達到的數值將取決於您的應用程式的存取模式和效能需求。為了盡可能保持最高的狀態BufferCacheHitRatio，建議叢集中的執行個體佈建足RAM以容納您的索引和記憶體中的工作資料集。

如果您的索引不適用記憶體，您會看到一個較低的 BufferCacheHitRatio。持續從磁碟讀取會產生額外的 I/O 成本，而且不會比從記憶體讀取更好。如果您的BufferCacheHitRatio比率低於預期，請擴展叢集的執行個體大小，以提供更多資訊RAM以適應記憶體中的工作集資料。如果擴大執行個體類別會導致 BufferCacheHitRatio 大幅增加，則應用程式的工作集不適用記憶體。持續擴展直到擴展操作後 BufferCacheHitRatio 不再大幅增加。如需監控執行個體指標的相關資訊，請參閱Amazon DocumentDB 指標。

根據您的工作負載和延遲需求，您的應用程式在穩定狀態使用期間具有較高的 BufferCacheHitRatio 值，而在執行個體上執行需要掃描整個集合的分析查詢時，BufferCacheHitRatio 時而下降，是可接受的情況。BufferCacheHitRatio 中這些定期的下降對後續的查詢可能會顯示為較高的延遲，因為需要將工作集資料從儲存磁碟區重新填入緩衝區快取。我們建議您先在生產前環境中使用典型的生產工作負載測試工作負載，以便在將工作負載部署至生產環境之前了解效能特性和 BufferCacheHitRatio。

BufferCacheHitRatio 是執行個體特定的指標，因此相同叢集中的不同執行個體可能會有不同的 BufferCacheHitRatio 值，視讀取作業在主要和複本執行個體之間的分配情況而定。如果您的操作工作負載無法處理在執行分析查詢後重新植入工作集快取時而增加的延遲，您應該嘗試將一般工作負載的緩衝區快取與分析查詢隔離。您可以將操作查詢導向至主要執行個體，而只將分析查詢導向至複本執行個體，以達到完全 BufferCacheHitRatio 隔離。您也可以透過將分析查詢導向至特定複本執行個體，在了解某些百分比的一般查詢也會在該複本上執行，且可能受到影響的情況下，達成部分隔離。

適當的 BufferCacheHitRatio 值取決於您的使用案例和應用程式需求。此指標沒有最佳或最小值；只有您自己可以決定從成本和效能的角度來看，是否可以接受暫時較低 BufferCacheHitRatio 的折衷。

使用索引

建立索引

將資料匯入 Amazon DocumentDB 時，您應該先建立索引，然後再匯入大型資料集。您可以使用 Amazon 文件資料庫索引工具從執行中的 MongoDB 執行個體或mongodump目錄擷取索引，並在 Amazon Document DB 叢集中建立這些索引。如需遷移的詳細指導方針，請參閱遷移到 Amazon DocumentDB。

索引選擇性

我們建議您限制建立索引的欄位，其中重複值的數目會小於集合中文件總數的 1%。例如，如果您的集合包含 100,000 份文件，則只在相同值出現 1000 次或更少的欄位上建立索引。

選擇具有大量唯一值 (即高基數) 的索引可確保篩選器作業傳回少量文件，從而在索引掃描期間產生良好的效能。高基數索引範例像是唯一索引，它可以保證相等述詞最多只能傳回單一文件。低基數索引的範例像是布林欄位，以及對一週中某天的索引。由於效能不佳，資料庫的查詢最佳化工具不太可能選擇低基數索引。同時，低基數索引會繼續消耗磁碟空間和 I/O 等資源。根據經驗法則，您應該在典型值頻率為總集合大小的 1％ 或更小的字段上鎖定索引。

此外，建議只在通常用作篩選器的欄位上建立索引，並定期尋找未使用的索引。如需詳細資訊，請參閱如何分析索引使用情況並識別未使用的索引？。

索引對寫入資料的影響

雖然索引可以透過避免掃描集合中的每個文件來改善查詢性能，但此改進方式有所權衡。對於集合上的每個索引，每次插入、更新或刪除文件時，資料庫必須更新集合並將欄位寫入集合的每個索引。例如，如果集合有九個索引，資料庫必須先執行十次寫入，才能確認用戶端的作業。因此，每個額外的索引都會造成額外的寫入延遲、I/O 以及整體使用的儲存量增加。

叢集執行個體的大小必須適當，才能保留所有工作集記憶體。如此可避免從儲存磁碟區持續讀取索引頁面的需求，進而對效能造成負面影響，並產生較高的 I/O 成本。如需詳細資訊，請參閱實例大小。

為了獲得最佳效能，請盡量減少集合中的索引數目，只新增必要的索引，以改善常見查詢的效能。雖然工作負載有所不同，但好的指導方針是將每個集合的索引數目保持在五個或更少。

識別缺少的索引

識別缺少的索引是我們建議定期執行的最佳做法。如需詳細資訊，請參閱 如何識別遺失的索引？。

識別未使用索引

識別和移除未使用的索引是我們建議定期執行的最佳實務。如需詳細資訊，請參閱 如何分析索引使用情況並識別未使用的索引？。

安全最佳實務

為了獲得安全最佳實務，您必須使用 AWS Identity and Access Management (IAM) 帳戶來控制對 Amazon DocumentDB API 操作的存取，尤其是建立、修改或刪除 Amazon DocumentDB 資源的操作。這類資源包含叢集、安全群組和參數群組。您也必須使用IAM來控制執行常見管理動作 (例如備份還原叢集) 的動作。創建IAM角色時，請使用最小權限的原則。

• 使用角色類型存取控制強制執行最低權限。

• 為管理亞馬遜資源的每個人指派個別IAM帳戶。請勿使用 AWS 帳戶 根使用者來管理 Amazon DocumentDB 源。為所有人 (包括您自己) 建立IAM使用者。

• 授與每個IAM使用者執行其職責所需的最低權限集。

• 使用IAM群組有效管理多個使用者的權限。若要取得有關的更多資訊IAM，請參閱IAM使用者指南。如需IAM最佳作法的相關資訊，請參閱IAM最佳做法。

• 定期輪替您的 IAM 登入資料。

• 將 AWS Secrets Manager 設定為自動輪替 Amazon DocumentDB 的密碼。如需詳細資訊，請參閱AWS 秘密管理員使用指南中的旋轉您的秘密 Secrets Manager 和 Amazon DocumentDB 的旋轉機AWS 密。

• 授予每個 Amazon DocumentDB 使用者執行其職責所需的最低許可集。如需詳細資訊，請參閱使用角色型存取控制存取資料庫。

• 使用傳輸層安全性 (TLS) 來加密傳輸中的資料，並 AWS KMS 加密靜態資料。

成本最佳化

下列最佳實務可協助您在使用 Amazon DocumentDB 時管理並將成本降至最低。如需定價資訊，請參閱 Amazon DocumentDB (與 MongoDB 相容性) 定價和 Amazon DocumentDB (與 MongoDB 相容性)。FAQs

• 建立帳單提醒，閾值為您預期的當月帳單的 50% 和 75%。如需有關建立帳單提醒的詳細資訊，請參閱建立帳單警示。

• Amazon DocumentDB 的架構可將儲存和運算區隔開來，因此即使是單一執行個體叢集也非常耐用。叢集儲存磁碟區在三個可用區域之間以六個方向複寫資料，無論叢集的執行個體數量為何，都能提供極高的耐用性。典型的生產叢集可以包含三種或多種執行個體，以提供高可用性。不過 , 如果不需要高可用性，則您可以使用單一執行個體開發叢集來使成本達到最佳化。

• 對於開發和測試案例，請停止不再需要的叢集，並且在恢復開發時啟動叢集。如需詳細資訊，請參閱停止和啟動 Amazon DocumentDB 集群。

• 寫入、讀取TTL和刪除資料時，和變更串流都會產生 I/O。如果您已啟用這些功能，但未在應用程式中使用這些功能，停用這些功能有助於降低成本。

使用指標來識別效能問題

若要識別資源不足和其他常見瓶頸造成的效能問題，您可以監控 Amazon DocumentDB 叢集的可用指標。

檢視效能指標

定期監控效能指標以查看各種時間範圍的平均值、最大值和最小值。效能降級時您便可以得知。您也可以為特定的測量結果閾值設定 Amazon CloudWatch 警示，以便在達到警示時收到警示。

為了對效能問題進行故障診斷，請務必了解系統的基礎效能。您設定新的叢集並執行一般工作負載後，請針對不同間隔 (例如 1 小時、24 小時、1 週、2 週) 的所有效能指標擷取平均、最大值和最低值。這可讓您了解正常運作情況為何。這有助於比較尖峰與離峰時段的操作。之後您可以使用此資訊來得知效能是否下降至標準層級之下。

您可以使用 AWS Management Console 或來檢視效能測量結果 AWS CLI。如需詳細資訊，請參閱檢視 CloudWatch 資料。

設定 CloudWatch 鬧鐘

要設置 CloudWatch 警報，請參閱 Amazon 用 CloudWatch 戶指南中的使用 Amazon CloudWatch 警報。

評估效能指標

執行個體含有幾種不同的指標類別。您判定值是否為可接受，取決於指標。

CPU

• CPU[使用率] — 使用的電腦處理能力百分比。

記憶體

• 可用記憶體 — 執行個體上RAM有多少可用記憶體。

• 交換使用量 — 執行個體使用了多少交換空間，以 MB 為單位。

輸入/輸出操作

• 讀取IOPS、寫入 IOPS — 每秒的平均磁碟讀取或寫入作業數。

• 讀取延遲、寫入延遲 — 讀取或寫入作業的平均時間 (毫秒)。

• 讀取輸送量、寫入輸送量 — 每秒從磁碟讀取或寫入磁碟的平均 MB 數。

• 磁碟佇列深度 — 等待寫入磁碟或從磁碟讀取的 I/O 作業數目。

網路流量

• 網路接收輸送量、網路傳輸輸送量 — 進出執行個體的網路流量速率 (以每秒 MB 為單位)。

資料庫連線

• 資料庫連線 — 連線至執行個體的用戶端工作階段數目。

一般來說，效能指標的可接受值視您的基準為何，以及您的應用程式所做之事而定。調查距離基準的一致或趨勢變異。

以下是關於特定類型指標的建議：

• 高CPU消耗量 — 高CPU消費值可能是合適的，前提是它們符合您應用程式的目標 (例如輸送量或並行)，並且是預期的。如果您的使CPU用量持續超過 80%，請考慮擴展執行個體。

• 高RAM消耗量 — 如果您的FreeableMemory指標經常降到執行個體記憶體總量的 10% 以下，請考慮擴展執行個體。如需 DocumentDB 執行個體遇到高記憶體壓力時會發生什麼情況的詳細資訊，請參閱 Amazon Document DB 資源控管。

• 交換使用量 — 此量度應保持在零或接近零。如果您的交換用量相當龐大， 請考慮擴展您的執行個體。

• 網路流量 — 對於網路流量，請與您的系統管理員洽談，以瞭解您的網域網路和網際網路連線的預期輸送量。調查網路流量的傳輸量是否如預期一致地降低。

• 資料庫連線 — 如果您看到大量的使用者連線，而且執行個體效能和回應時間降低，請考慮限制資料庫連線。執行個體使用者連接的最佳數量，將因執行個體類別和要執行的操作複雜性而不同。如有任何校能指標的問題，您可以執行以改善效能的其中一個動作是調校最常使用與最昂貴的查詢，以了解該調整是否降低對系統資源的壓力。

如果您的查詢經過調整且問題仍然存在，請考慮將 Amazon DocumentDB 執行個體類別升級為具有更多資源 (CPURAM、磁碟空間、網路頻寬、I/O 容量) 的執行個體類別。

調校查詢

改善叢集執行個體效能的一個最佳方式是調校最常使用與資源最密集的查詢，讓執行成本較不昂貴。

您可以使用 Profiler (請參閱 分析 Amazon DocumentDB 操作) 來記錄叢集上執行之操作的執行時間和詳細資訊。Profiler 適用於監控叢集上最慢的操作，以協助您改善個別查詢效能和整體叢集效能。

您也可以使用 explain 命令了解如何分析特定查詢的查詢計劃。使用此資訊可修改查詢或基礎集合，藉此改善查詢效能 (例如，新增索引)。

TTL和時間序列工作負載

因TTL索引到期而導致的文件刪除是最好的工作過程。本公司不保證在任何特定期間內刪除文件。例如執行個體大小、執行個體資源使用率、文件大小、整體輸送量、索引數目，以及索引和工作集是否適合記憶體等因素都會影響TTL程序刪除過期文件的時間。

當TTL監視器刪除您的文檔時，每次刪除都會產生 I/O 成本，從而增加您的帳單。如果輸送量和TTL刪除率增加，您應該會因為 I/O 使用量增加而獲得更高的費用。但是，如果您不建立TTL索引來刪除文件，而是根據時間將文件細分到集合中，並在不再需要時將這些集合刪除，則不會產生任何 IO 成本。這可能比使用TTL索引更具成本效益。

對於時間序列工作負載，您可以考慮建立滾動式集合而非TTL索引，因為滾動式集合可能是刪除資料和較少 I/O 密集的更好方法。如果您有大型集合 (特別是超過 1TB 的集合) 或TTL刪除 I/O 成本是一個問題，我們建議您根據時間將文件分割為集合，並在不再需要文件時刪除集合。您可以資料擷取率為根據，每天或每個禮拜建立一個集合。雖然需求將根據您的應用程式而有所不同，但好的經驗法是擁有更小的集合而不是一些大型集合。卸除這些集合不會產生 I/O 成本，而且比使用TTL索引更快、更具成本效益。

遷移

最佳實務是，我們建議您在將資料遷移到 Amazon DocumentDB 時，先在 Amazon DocumentDB 中建立索引，然後再遷移資料。首先建立索引可以縮短整體時間並提高遷移速度。要做到這一點，你可以使用 Amazon DocumentDB 索引工具。如需有關移轉的詳細資訊，請參閱 Amazon DocumentDB 移轉指南。

我們還建議您在遷移生產資料庫之前，考慮到功能、效能、操作和成本，在 Amazon DocumentDB 上完整測試應用程式是最佳實務。

使用叢集參數群組

建議您在測試叢集執行個體上嘗試進行叢集參數群組變更，再將參數群組變更套用至生產叢集執行個體。如需備份叢集的詳細資訊，請參閱在 Amazon DocumentDB 中進行備份和恢復。

聚合管線查詢

建立具有多個階段的彙總管道查詢，並僅評估查詢中的一部分資料時，請使用 $match 階段做為第一個階段或管道的開頭。使用 $match 會先減少彙總管道查詢中需要處理的文件後續階段數量，從而提高查詢的效能。

batchInsert 和 batchUpdate

執行高速並行和 (batchInsert或) batchUpdate 作業，且主要執行處理上的 FreeableMemory (CloudWatch 指標) 數量變為零時，您可以減少批次插入的並行性，或者如果無法減少並行工作負載，請增加執行個體大小以增加的數量。FreeableMemory