本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# Amazon DocumentDB 的最佳實務
了解使用 Amazon DocumentDB （與 MongoDB 相容） 的最佳實務。在新最佳實務確定時，會不斷更新此小節。
**Topics**
+ [基本操作準則](#best_practices-operational)
+ [執行個體大小調整](#best_practices-instance_sizing)
+ [使用索引](#best_practices-indexes)
+ [安全最佳實務](#best_practices-security)
+ [成本最佳化](#best_practices-cost_optimization)
+ [使用指標來識別效能問題](#best_practices-performance)
+ [TTL 和時間序列工作負載](#best_practices-ttl_timeseries)
+ [遷移](#best_practices-migrations)
+ [使用叢集參數群組](#best_practices-cluster_parameter_groups)
+ [彙總管道查詢](#best_practices-aggregation_pipeline_queries)
+ [`batchInsert` 和 `batchUpdate`](#best_practices-batchinsert_batchupdate)
## 基本操作準則
以下是每個人在使用 Amazon DocumentDB 時應遵循的基本操作準則。Amazon DocumentDB 服務水準協議要求您遵循這些準則。
+ 在兩個 AWS 可用區域中部署由兩個或多個 Amazon DocumentDB 執行個體組成的叢集。對於生產工作負載，我們建議在三個可用區域中部署由三個或多個 Amazon DocumentDB 執行個體組成的叢集。
+ 在指定的服務限制內使用服務。如需詳細資訊，請參閱[Amazon DocumentDB 配額和限制](limits.md)。
+ 監控您的記憶體、CPU、連線和儲存體用量。為了協助您維持系統效能和可用性，請設定 Amazon CloudWatch，以便在使用模式變更或接近部署容量時通知您。
+ 當您接近容量限制時擴展您的執行個體。您的執行個體應該佈建足夠的運算資源 (例如 RAM、CPU)，以因應應用程式不可預見的需求增加。
+ 設定備份保留期以符合您的復原點目標。
+ 測試叢集的容錯移轉，以了解您的使用案例執行此程序需時多長。如需詳細資訊，請參閱[Amazon DocumentDB 容錯移轉](failover.md)。
+ 使用叢集端點 （請參閱 [Amazon DocumentDB 端點](how-it-works.md#how-it-works.endpoints)) 和複本集模式 （請參閱 [以複本集的形式連線至 Amazon DocumentDB](connect-to-replica-set.md)) 連線至 Amazon DocumentDB 叢集，將容錯移轉對應用程式的影響降至最低。
+ 選擇驅動程式讀取偏好設定，以發揮最大讀取擴展，同時符合您應用程式的讀取一致性要求。`secondaryPreferred` 讀取偏好設定會啟用複本讀取，並釋出主要執行個體以進行更多工作。如需詳細資訊，請參閱[讀取偏好設定選項](how-it-works.md#durability-consistency-isolation)。
+ 設計您的應用程式，以便在網路和資料庫發生錯誤時，保有故障恢復的應變能力。使用您驅動程式的錯誤機制，區分暫時性錯誤或永久性錯誤。適當時，使用指數退避機制重新嘗試暫時性錯誤。確認您的應用程式在實作重試邏輯時會考慮資料一致性。
+ 為所有生產叢集或任何具有重要資料的叢集啟用叢集刪除保護。刪除 Amazon DocumentDB 叢集之前，請拍攝最終快照。如果您要使用 部署資源 CloudFormation，請啟用終止保護。如需詳細資訊，請參閱[終止保護和刪除保護](quick_start_cfn.md#quick_start_cfn-termination_deletion_protection)。
+ 建立 Amazon DocumentDB 叢集時， `--engine-version`是選用參數，預設為最新的主要引擎版本。目前的預設引擎版本為 5.0.0 （注意：Amazon DocumentDB 8.0 可供使用，但必須明確指定）。發行新的主要引擎版本時， 的預設引擎版本`--engine-version`將會更新，以反映最後一個主要引擎版本。因此，對於生產工作負載，特別是依賴指令碼、自動化或 CloudFormation 範本的工作負載，我們建議您將 明確指定`--engine-version`為預期的主要版本。
## 執行個體大小調整
在 Amazon DocumentDB 中選擇執行個體大小的其中一個最重要方面是快取的 RAM 數量。Amazon DocumentDB 會為自己的服務保留三分之一的 RAM，這表示只有三分之二的執行個體 RAM 可供快取使用。因此，Amazon DocumentDB 最佳實務是選擇具有足夠 RAM 的執行個體類型，以符合記憶體中的工作集 （即資料和索引）。具有適當大小的執行個體將有助於最佳化整體效能，並可能將 I/O 成本降至最低。
若要判斷應用程式的工作集是否適用記憶體，請使用 Amazon CloudWatch 針對叢集中負載下的每個執行個體監控 `BufferCacheHitRatio`。
`BufferCacheHitRatio` CloudWatch 指標會測量從執行個體的記憶體快取 (與儲存磁碟區) 提供的資料和索引百分比。一般來說，`BufferCacheHitRatio` 的數值應該盡可能高，因為從工作集記憶體讀取資料比從儲存磁碟區讀取更快速且更具成本效益。儘管盡可能保持 `BufferCacheHitRatio` 接近 100% 是理想的做法，但是最可能達到的數值將取決於您的應用程式的存取模式和效能需求。為了盡可能保持最高的 `BufferCacheHitRatio`，建議您叢集中的執行個體佈建足夠的 RAM，以便在記憶體中容納索引和工作資料集。
如果您的索引不適用記憶體，您會看到一個較低的 `BufferCacheHitRatio`。從磁碟持續讀取會產生額外的 I/O 成本，而且不優於從記憶體讀取。如果您的 `BufferCacheHitRatio` 比例低於預期，請為您的叢集擴充執行個體大小，以提供更多 RAM 以符合記憶體中的工作集資料。如果擴大執行個體類別會導致 `BufferCacheHitRatio` 大幅增加，則應用程式的工作集不適用記憶體。持續擴展直到擴展操作後 `BufferCacheHitRatio` 不再大幅增加。如需監控執行個體指標的相關資訊，請參閱[Amazon DocumentDB 指標](cloud_watch.md#cloud_watch-metrics_list)。
根據您的工作負載和延遲需求，您的應用程式在穩定狀態使用期間具有較高的 `BufferCacheHitRatio` 值，而在執行個體上執行需要掃描整個集合的分析查詢時，`BufferCacheHitRatio` 時而下降，是可接受的情況。`BufferCacheHitRatio` 中這些定期的下降對後續的查詢可能會顯示為較高的延遲，因為需要將工作集資料從儲存磁碟區重新填入緩衝區快取。**我們建議您先在生產前環境中使用典型的生產工作負載測試工作負載，以便在將工作負載部署至生產環境之前了解效能特性和 `BufferCacheHitRatio`。**
`BufferCacheHitRatio` 是執行個體特定的指標，因此相同叢集中的不同執行個體可能會有不同的 `BufferCacheHitRatio` 值，視讀取作業在主要和複本執行個體之間的分配情況而定。如果您的操作工作負載無法處理在執行分析查詢後重新植入工作集快取時而增加的延遲，您應該嘗試將一般工作負載的緩衝區快取與分析查詢隔離。您可以將操作查詢導向至主要執行個體，而只將分析查詢導向至複本執行個體，以達到完全 `BufferCacheHitRatio` 隔離。您也可以透過將分析查詢導向至特定複本執行個體，在了解某些百分比的一般查詢也會在該複本上執行，且可能受到影響的情況下，達成部分隔離。
適當的 `BufferCacheHitRatio` 值取決於您的使用案例和應用程式需求。此指標沒有最佳或最小值；只有您自己可以決定從成本和效能的角度來看，是否可以接受暫時較低 `BufferCacheHitRatio` 的折衷。
## 使用索引
### 建立索引
將資料匯入 Amazon DocumentDB 時，您應該先建立索引，再匯入大型資料集。您可以使用 [Amazon DocumentDB Index Tool](https://github.com/awslabs/amazon-documentdb-tools) 從執行中的 MongoDB 執行個體或`mongodump`目錄中擷取索引，並在 Amazon DocumentDB 叢集中建立這些索引。如需遷移的詳細指導方針，請參閱[遷移至 Amazon DocumentDB](docdb-migration.md)。
### 索引選擇性
我們建議您限制建立索引的欄位，其中重複值的數目會小於集合中文件總數的 1%。例如，如果您的集合包含 100,000 份文件，則只在相同值出現 1000 次或更少的欄位上建立索引。
選擇具有大量唯一值 (即高基數) 的索引可確保篩選器作業傳回少量文件，從而在索引掃描期間產生良好的效能。高基數索引範例像是唯一索引，它可以保證相等述詞最多只能傳回單一文件。低基數索引的範例像是布林欄位，以及對一週中某天的索引。由於效能不佳，資料庫的查詢最佳化工具不太可能選擇低基數索引。同時，低基數索引會繼續消耗磁碟空間和 I/O 等資源。根據經驗法則，您應該在典型值頻率為總集合大小的 1％ 或更小的字段上鎖定索引。
此外，建議只在通常用作篩選器的欄位上建立索引，並定期尋找未使用的索引。如需詳細資訊，請參閱[如何分析索引用量並識別未使用的索引？](user_diagnostics.md#user-diag-index-usage)。
### 索引對寫入資料的影響
雖然索引可以透過避免掃描集合中的每個文件來改善查詢性能，但此改進方式有所權衡。對於集合上的每個索引，每次插入、更新或刪除文件時，資料庫必須更新集合並將欄位寫入集合的每個索引。例如，如果集合有九個索引，資料庫必須先執行十次寫入，才能確認用戶端的作業。因此，每個額外的索引都會造成額外的寫入延遲、I/O 以及整體使用的儲存量增加。
叢集執行個體的大小必須適當，才能保留所有工作集記憶體。如此可避免從儲存磁碟區持續讀取索引頁面的需求，進而對效能造成負面影響，並產生較高的 I/O 成本。如需詳細資訊，請參閱[執行個體大小調整](#best_practices-instance_sizing)。
為了獲得最佳效能，請盡量減少集合中的索引數目，只新增必要的索引，以改善常見查詢的效能。雖然工作負載有所不同，但好的指導方針是將每個集合的索引數目保持在五個或更少。
### 識別缺少的索引
識別缺少的索引是最佳實務，我們建議定期執行。如需詳細資訊，請參閱 [如何識別缺少的索引？](user_diagnostics.md#user_diagnostics-identify_missing_indexes)。
### 識別未使用的索引
識別和移除未使用的索引是我們建議定期執行的最佳實務。如需詳細資訊，請參閱 [如何分析索引用量並識別未使用的索引？](user_diagnostics.md#user-diag-index-usage)。
## 安全最佳實務
為了安全最佳實務，您必須使用 AWS Identity and Access Management (IAM) 帳戶來控制對 Amazon DocumentDB API 操作的存取，尤其是建立、修改或刪除 Amazon DocumentDB 資源的操作。這類資源包含叢集、安全群組和參數群組。您還必須使用 IAM 來控制執行常見管理動作的動作，例如備份還原叢集。建立 IAM 角色時，請採用最低權限原則。
+ 使用[角色類型存取控制](role_based_access_control.md)強制執行最低權限。
+ 將個別 IAM 帳戶指派給管理 Amazon DocumentDB 資源的每個人。請勿使用 AWS 帳戶 根使用者來管理 Amazon DocumentDB 資源。為每個人 (包含您) 建立 IAM 使用者。
+ 授予每個 IAM 使用者執行其職責所需的最低許可集。
+ 使用 IAM 群組來有效管理多個使用者的許可。如需 IAM 的詳細資訊，請參閱 [IAM 使用者指南](https://docs.aws.amazon.com/IAM/latest/UserGuide/Welcome.html)。如需 IAM 最佳實務的相關資訊，請參閱 [IAM 最佳實務](https://docs.aws.amazon.com/IAM/latest/UserGuide/IAMBestPractices.html)。
+ 定期輪替您的 IAM 登入資料。
+ 設定 AWS Secrets Manager 以自動輪換 Amazon DocumentDB 的秘密。如需詳細資訊，請參閱《[AWS Secrets Manager 使用者指南》中的輪換 Secrets Manager 秘密](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html)和[輪換 Amazon DocumentDB](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets-documentdb.html) 的秘密。 *AWS *
+ 授予每個 Amazon DocumentDB 使用者執行其職責所需的最低許可集。如需詳細資訊，請參閱[使用角色型存取控制進行資料庫存取](role_based_access_control.md)。
+ 使用 Transport Layer Security (TLS) 來加密傳輸中的資料 AWS KMS ，以及加密靜態資料。
## 成本最佳化
下列最佳實務可協助您管理和最小化使用 Amazon DocumentDB 時的成本。如需定價資訊，請參閱 [Amazon DocumentDB （與 MongoDB 相容） 定價](https://aws.amazon.com/documentdb/pricing/)和 [Amazon DocumentDB （與 MongoDB 相容） FAQs](https://aws.amazon.com/documentdb/faqs/)。
+ 建立帳單提醒，閾值為您預期的當月帳單的 50% 和 75%。如需有關建立帳單提醒的詳細資訊，請參閱[建立帳單警示](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/monitor_estimated_charges_with_cloudwatch.html#creating_billing_alarm_with_wizard)。
+ Amazon DocumentDB 的架構會區隔儲存和運算，因此即使是單一執行個體叢集也非常耐用。叢集儲存磁碟區在三個可用區域之間以六個方向複寫資料，無論叢集的執行個體數量為何，都能提供極高的耐用性。典型的生產叢集可以包含三種或多種執行個體，以提供高可用性。不過 , 如果不需要高可用性，則您可以使用單一執行個體開發叢集來使成本達到最佳化。
+ 對於開發和測試案例，請停止不再需要的叢集，並且在恢復開發時啟動叢集。如需詳細資訊，請參閱[停止和啟動 Amazon DocumentDB 叢集](db-cluster-stop-start.md)。
+ TTL 和變更串流在資料寫入、讀取和刪除時都會產生 I/O。如果您已啟用這些功能，但未在應用程式中使用這些功能，停用這些功能有助於降低成本。
## 使用指標來識別效能問題
**Topics**
+ [檢視效能指標](#best_practices-performance_viewing_metrics)
+ [設定 CloudWatch 警示](#best_practices-set_cloudwatch_alarm)
+ [評估效能指標](#best_practices-performance_evaluating_metrics)
+ [使用 CloudWatch 指標評估 Amazon DocumentDB 執行個體用量](#best-practice-evaluating-instance-usage)
+ [調校查詢](#best_practices-performance_tuning_queries)
若要識別資源不足和其他常見瓶頸所造成的效能問題，您可以監控 Amazon DocumentDB 叢集可用的指標。
### 檢視效能指標
定期監控效能指標以查看各種時間範圍的平均值、最大值和最小值。效能降級時您便可以得知。您也可以針對特定指標閾值設定 Amazon CloudWatch 警示，以便在達到它們時收到提醒。
為了對效能問題進行故障診斷，請務必了解系統的基礎效能。您設定新的叢集並執行一般工作負載後，請針對不同間隔 (例如 1 小時、24 小時、1 週、2 週) 的所有效能指標擷取平均、最大值和最低值。這可讓您了解正常運作情況為何。這有助於比較尖峰與離峰時段的操作。之後您可以使用此資訊來得知效能是否下降至標準層級之下。
####
您可以使用 AWS 管理主控台 或 檢視效能指標 AWS CLI。如需詳細資訊，請參閱[檢視 CloudWatch 資料](cloud_watch.md#cloud_watch-view_data)。
### 設定 CloudWatch 警示
若要設定 CloudWatch 警示，請參閱《[Amazon CloudWatch 使用者指南》中的使用 Amazon CloudWatch 警示](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)。 *Amazon CloudWatch *
### 評估效能指標
執行個體含有幾種不同的指標類別。您判定值是否為可接受，取決於指標。
**CPU**
+ **CPU 使用率** — 使用的電腦處理容量百分比。
**記憶體**
+ **可用記憶體** — 執行個體上有多少 RAM 可用。
+ **交換用量** — 執行個體使用多少交換空間，以 MB 為單位。
**輸入/輸出操作**
+ **讀取 IOPS**、**寫入 IOPS** — 每秒磁碟讀取或寫入操作的平均數量。
+ **讀取延遲**、**寫入延遲** — 讀取或寫入操作的平均時間，以毫秒為單位。
+ **讀取輸送量**、**寫入輸送量** — 每秒讀取或寫入磁碟的平均 MB 數。
+ **磁碟佇列深度** — 等待寫入磁碟或從磁碟讀取的 I/O 操作數目。
**網路流量**
+ **網路接收輸送量**、**網路傳輸輸送量** — 往返執行個體的網路流量速率，以每秒 MB 為單位。
**資料庫連線**
+ **資料庫連線** — 連線至執行個體的用戶端工作階段數目。
一般來說，效能指標的可接受值視您的基準為何，以及您的應用程式所做之事而定。調查距離基準的一致或趨勢變異。
以下是關於特定類型指標的建議：
+ **高 CPU 耗**用量 — 高 CPU 耗用量值可能是適當的，前提是這些值符合您應用程式的目標 （例如輸送量或並行），而且是預期的。如果您的 CPU 消耗量持續超過 80%，請考慮擴展您的執行個體。
+ **高 RAM 耗用** — 如果您的`FreeableMemory`指標經常低於執行個體記憶體總量的 10%，請考慮擴展執行個體。如需 DocumentDB 執行個體發生高記憶體壓力時所發生情況的詳細資訊，請參閱 [Amazon DocumentDB 資源控管](how-it-works.md#how-it-works.reliability.resource-governance)。
+ **交換用量** — 此指標應維持在零或接近零。如果您的交換用量相當龐大， 請考慮擴展您的執行個體。
+ **網路流量** — 對於網路流量，請與您的系統管理員討論，以了解網域網路和網際網路連線的預期輸送量。調查網路流量的傳輸量是否如預期一致地降低。
+ **資料庫連線** — 如果您看到大量使用者連線，並降低執行個體效能和回應時間，請考慮限制資料庫連線。執行個體使用者連接的最佳數量，將因執行個體類別和要執行的操作複雜性而不同。如有任何校能指標的問題，您可以執行以改善效能的其中一個動作是調校最常使用與最昂貴的查詢，以了解該調整是否降低對系統資源的壓力。
如果您的查詢經過調校且問題仍然存在，請考慮將您的 Amazon DocumentDB 執行個體類別升級至具有更多資源 (CPU、RAM、磁碟空間、網路頻寬、I/O 容量） 且與您遇到的問題相關的類別。
### 使用 CloudWatch 指標評估 Amazon DocumentDB 執行個體用量
您可以使用 CloudWatch 指標來監看執行個體輸送量，並探索執行個體類別是否為您的應用程式提供足夠的資源。如需執行個體類別限制的相關資訊，請參閱[執行個體限制](limits.md#limits.instance)並尋找執行個體類別的規格，以尋找您的網路效能。
如果您的執行個體用量接近執行個體類別限制，則效能可能會開始變慢。CloudWatch 指標可以確認這種情況，因此您可以規劃手動縱向擴展到更大的執行個體類別。
結合下列 CloudWatch 指標值，以了解您是否接近執行個體類別限制：
+ **NetworkThroughput** - 用戶端為 Amazon DocumentDB 叢集中的每個執行個體接收和傳輸的網路輸送量。此輸送量值不包含叢集中執行個體與叢集儲存磁碟區之間的網路流量。
+ **StorageNetworkThroughput** - Amazon DocumentDB 叢集中每個執行個體接收並傳送至 Amazon DocumentDB 叢集儲存磁碟區的網路輸送量。
將 **NetworkThroughput** 新增至 **StorageNetworkThroughput**，以尋找 Amazon DocumentDB 叢集中每個執行個體從 Amazon DocumentDB 叢集儲存磁碟區接收並傳送至 Amazon DocumentDB 叢集儲存磁碟區的網路輸送量。執行個體的執行個體類別限制應該大於這兩個合併指標之和。
在傳送和接收時，您可以使用下列指標，來檢閱來自用戶端應用程式之網路流量的其他詳細資訊：
+ **NetworkReceiveThroughput** - Amazon DocumentDB 叢集中每個執行個體從用戶端接收的網路輸送量。此輸送量不包含叢集中執行個體與叢集儲存磁碟區之間的網路流量。
+ **NetworkTransmitThroughput** - Amazon DocumentDB 叢集中每個執行個體傳送給用戶端的網路輸送量。此輸送量不包含叢集中執行個體與叢集儲存磁碟區之間的網路流量。
+ **StorageNetworkReceiveThroughput** - 叢集中每個執行個體從 Amazon DocumentDB 叢集儲存磁碟區接收的網路輸送量。
+ **StorageNetworkTransmitThroughput** - 叢集中每個執行個體傳送至 Amazon DocumentDB 叢集儲存磁碟區的網路輸送量。
將所有這些指標加在一起，以評估您的網路用量與執行個體類別限制的比較情形。執行個體類別限制應該大於這些個合併指標之和。
執行個體的網路限制和 CPU 使用率是相互的。當網路輸送量增加時，CPU 使用率也會增加。監控 CPU 和網路用量可提供資源如何和為何耗盡的相關資訊。
若要協助將網路用量降至最低，您可以考慮：
+ 使用更大的執行個體類別。
+ 批次分割寫入要求，以減少整體交易。
+ 將唯讀工作負載導向至唯讀執行個體。
+ 刪除任何未使用的索引。
### 調校查詢
改善叢集執行個體效能的一個最佳方式是調校最常使用與資源最密集的查詢，讓執行成本較不昂貴。
您可以使用 Profiler (請參閱 [分析 Amazon DocumentDB 操作](profiling.md)) 來記錄叢集上執行之操作的執行時間和詳細資訊。Profiler 適用於監控叢集上最慢的操作，以協助您改善個別查詢效能和整體叢集效能。
您也可以使用 `explain` 命令了解如何分析特定查詢的查詢計劃。使用此資訊可修改查詢或基礎集合，藉此改善查詢效能 (例如，新增索引)。
## TTL 和時間序列工作負載
TTL 指數到期後刪除文件是最勞心費神的過程。本公司不保證在任何特定期間內刪除文件。執行個體大小、執行個體資源使用率、文件大小、整體輸送量、索引數目以及索引和工作集是否適用記憶體等因素，都會影響 TTL 處理程序刪除過期文件的時間。
當 TTL 監控器刪除文件時，每個刪除都會產生 IO 成本，使帳單金額增加。如果輸送量和 TTL 刪除率提高，您可預期會因為 I/O 使用量增加而產生較高的費用。不過，如果您不建立 TTL 索引來刪除文件，而是根據時間將文件分割為集合，並在不再需要這些集合時直接捨棄，則不會產生任何 IO 成本。這比使用 TTL 索引更具成本效益。
對於時間序列工作負載，您可以考慮建立滾動集合而非 TTL 索引，因為滾動集合可能是刪除資料和降低 I/O 密集度的更好方法。如果您有大型集合 (特別是超過 1TB 的集合) 或 TTL 刪除 I/O 成本的考量，建議您依時間將文件分割為集合，並在不再需要文件時刪除集合。您可以資料擷取率為根據，每天或每個禮拜建立一個集合。雖然需求將根據您的應用程式而有所不同，但好的經驗法是擁有更小的集合而不是一些大型集合。刪除這些集合不會產生 IO 成本，且成本效益明顯比使用 TTL 索引還高。
## 遷移
根據最佳實務，我們建議您在將資料遷移至 Amazon DocumentDB 時，先在 Amazon DocumentDB 中建立索引，再遷移資料。首先建立索引可以縮短整體時間並提高遷移速度。若要這樣做，您可以使用 Amazon DocumentDB [Index Tool](https://github.com/awslabs/amazon-documentdb-tools)。如需遷移的詳細資訊，請參閱 [Amazon DocumentDB 遷移指南](https://docs.aws.amazon.com/documentdb/latest/developerguide/docdb-migration.html)。
我們也建議您在遷移生產資料庫之前，最佳實務是在 Amazon DocumentDB 上完整測試您的應用程式，並考量功能、效能、操作和成本。
## 使用叢集參數群組
建議您在測試叢集執行個體上嘗試進行叢集參數群組變更，再將參數群組變更套用至生產叢集執行個體。如需備份叢集的詳細資訊，請參閱[在 Amazon DocumentDB 中備份和還原](backup_restore.md)。
## 彙總管道查詢
建立具有多個階段的彙總管道查詢，並僅評估查詢中的一部分資料時，請使用 `$match` 階段做為第一個階段或管道的開頭。使用 `$match` 會先減少彙總管道查詢中需要處理的文件後續階段數量，從而提高查詢的效能。
## `batchInsert` 和 `batchUpdate`
在您的主要執行個體上執行高速並行 `batchInsert` 和/或 `batchUpdate` 操作，並且 `FreeableMemory` (CloudWatch 指標) 的數量降至零時，您可以減少批次插入或更新工作負載的並行性，或者若是無法減少工作負載的並行性，請增加執行個體大小以增加 `FreeableMemory` 的數量。