本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 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、连接和存储使用情况。为了帮助您保持系统性能和可用性，请 CloudWatch 将 Amazon 设置为在使用模式发生变化或接近部署容量时通知您。
+ 当接近容量限制时，可以向上扩展您的实例。您应为这些实例预配置足够的计算资源（即 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（注意：亚马逊 DocumentDB 8.0 可用，但必须明确指定）。发布主引擎新版本时，`--engine-version` 的默认引擎版本将更新，以反映最近的主引擎版本。因此，对于生产工作负载，尤其是那些依赖脚本、自动化或 CloudFormation 模板的工作负载，我们建议您明确指定预期的主要版本。`--engine-version`
## 实例大小调整
选择 Amazon DocumentDB 中实例大小的最关键方面之一是缓存的 RAM 量。Amazon DocumentDB 为自身服务保留了三分之一的 RAM，这意味着只有三分之二的实例 RAM 可用于缓存。因此，为了发挥 Amazon DocumentDB 的最佳性能，最好的做法是选择具有足够 RAM 的实例类型，以便有足够的内存来容纳工作集（即数据和索引）。拥有适当大小的实例将有助于优化整体性能，并有可能最大限度地降低 I/O 成本。您可以使用第三方 [Amazon DocumentDB 大小调整计算器](https://aws.improving.com/documentdb/cost-estimator/)估算特定工作负载的实例大小。
要确定您的应用程序的工作集是否适合内存，请监控集群中每个处于负载状态 CloudWatch 的实例的`BufferCacheHitRatio`使用 Amazon 的情况。
该`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 索引工具](https://github.com/awslabs/amazon-documentdb-tools)从正在运行的 MongoDB 实例或 `mongodump` 目录提取索引，然后在 Amazon DocumentDB 集群中创建这些索引。有关迁移的更多指导，请参阅[迁移到 Amazon DocumentDB](docdb-migration.md)。
### 索引选择性
我们建议您将索引创建限制为其中的重复值数量低于集合中总文档数的 1% 的字段。例如，如果您的集合包含 100,000 个文档，则仅在相同值出现 1000 次或更少的字段上创建索引。
选择具有大量唯一值（即高基数）的索引可确保筛选操作返回少量文档，从而在索引扫描期间产生良好的性能。高基数索引的一个例子是一个唯一索引，它保证相等谓词最多返回单个文档。低基数的示例包括布尔字段上的索引和一周中某天的索引。由于性能差，数据库的查询优化程序不太可能选择低基数索引。同时，低基数索引继续消耗资源，例如磁盘空间和。 I/Os作为经验法则，应将索引定位于典型值频率为总集合大小的 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) 账户来控制对亚马逊 DocumentDB API 操作的访问权限，尤其是创建、修改或删除亚马逊 DocumentDB 资源的操作。此类资源包括集群、安全组和参数组。此外，您还必须使用 IAM 来控制执行常见管理任务的操作，例如备份和还原集群。创建 IAM 角色时，请采用最小权限原则。
+ 使用[基于角色的访问控制](role_based_access_control.md)强制执行最低权限。
+ 为每个管理 Amazon DocumentDB 资源的人员分配个人 IAM 账户。请勿使用 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 凭证。
+ 将 S AWS ecrets Manager 配置为自动轮换 Amazon DocumentDB 的密钥。有关更多信息，请参阅 S [AWS ecrets Manager 用户指南中的轮换您的 Sec](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html) *rets Manager [密钥和轮换亚马逊 DocumentDB](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets-documentdb.html) 的AWS 密钥*。
+ 授予每位 Amazon DocumentDB 用户履行其职责所需的最小权限集。有关更多信息，请参阅 [使用基于角色的访问控制进行数据库访问](role_based_access_control.md)。
+ 使用传输层安全 (TLS) 对传输中的数据进行加密 AWS KMS ，并对静态数据进行加密。
## 成本优化
以下最佳实践可帮助您管理和最大程度地降低使用 Amazon DocumentDB 的成本。有关定价信息，请参阅[ Amazon DocumentDB（与 MongoDB 兼容）定价](https://aws.amazon.com/documentdb/pricing/)和 [Amazon DocumentDB（与 MongoDB 兼容）常见问题解答](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)
+ [使用指标评估亚马逊 DocumentDB 实例使用情况 CloudWatch](#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 警报，请参阅[亚马逊* CloudWatch 用户指南中的使用亚马逊 CloudWatch *警报](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)。
### 评估性能指标
一个实例具有多个不同类别的指标。确定可接受的值的方式取决于指标。
**CPU**
+ **CPU 利用率**：使用的计算机处理容量的百分比。
**内存**
+ **可用内存**：实例上可用的 RAM 量。
+ **交换区使用情况**：实例使用的交换空间量（以兆字节为单位）。
**Input/output 操作**
+ **读取 IOPS**，**写入 IOPS**：每秒进行的磁盘读取或写入操作平均数。
+ **读取延迟**，**写入延迟**：读取或写入操作的平均时间（以毫秒为单位）。
+ **读取吞吐量**，**写入吞吐量**：每秒对磁盘读取或写入的平均兆字节数。
+ **磁盘队列深度**-等待写入磁盘或从磁盘读取的 I/O操作数。
**网络流量**
+ **网络接收吞吐量**，**网络传输吞吐量**：每秒出入实例的网络流量速率（以兆字节为单位）。
**数据库连接**
+ **数据库连接**：连接到实例的客户端会话数。
一般而言，性能指标的可接受值取决于您的基准性能以及应用程序执行的操作。应调查相对于基准性能的一致或趋势性变化。
以下是有关特定类型的指标的建议：
+ **高 CPU 消耗**：CPU 消耗值高可能是正常情况，只要它们符合您的应用程序目标（如吞吐量或并发度）并且符合预期。如果 CPU 消耗始终高于 80%，请考虑扩展您的实例。
+ **高 RAM 消耗**：如果 `FreeableMemory` 指标经常下降至总实例内存的 10% 以下，请考虑扩展您的实例。有关您的文档数据库实例正经历高内存压力时发生什么的更多信息，请参阅 [Amazon DocumentDB 资源管理](how-it-works.md#how-it-works.reliability.resource-governance)。
+ **交换区使用情况**：该指标应保持为零或接近零。如果交换区使用情况非常大，请考虑扩展您的实例。
+ **网络流量**：对于网络流量，请与系统管理员讨论，以了解域网络和互联网连接的预期吞吐量。如果吞吐量始终低于预期，则应调查网络流量。
+ **数据库连接**：如果发现用户连接数较高，同时实例性能下降并且响应时间延长，请考虑约束数据库连接。实例的最佳用户连接数因您的实例类所执行操作的复杂性而异。对于与性能指标有关的问题，提高性能的首要手段之一是优化最常使用和成本最高昂的查询，以了解这是否会减少对系统资源的压力。
如果您的查询经过调整但问题仍然存在，请考虑将您的 Amazon DocumentDB 实例类升级为具有更多与您遇到的问题相关的资源（CPU、RAM、磁盘空间、网络带宽、 I/O 容量）的实例类。
### 使用指标评估亚马逊 DocumentDB 实例使用情况 CloudWatch
您可以使用 CloudWatch 指标来观察您的实例吞吐量，并发现您的实例类是否为应用程序提供了足够的资源。有关实例类限制的信息，请访参阅 [实例限制](limits.md#limits.instance) 并找到实例类的规格以了解您的网络性能。
如果您的实例使用情况接近实例类限制，则性能可能会开始变慢。这些 CloudWatch 指标可以证实这种情况，因此您可以计划手动扩展到更大的实例类别。
组合以下 CloudWatch 指标值以了解您是否已接近实例类限制：
+ **NetworkThroughput**— Amazon DocumentDB 集群中每个实例的客户端接收和传输的网络吞吐量。此吞吐量值不包括集群中的实例与集群存储卷之间的网络流量。
+ **StorageNetworkThroughput**— Amazon DocumentDB 集群中每个实例接收并发送到 Amazon DocumentDB 集群存储卷的网络吞吐量。
将添加到，**NetworkThroughput**StorageNetworkThroughput****以查看 Amazon DocumentDB 集群中每个实例从亚马逊文档数据库集群存储卷接收和发送到该集群存储卷的网络吞吐量。您的实例的实例类限制应大于这两个组合指标的总和。
在发送和接收时，您可以使用以下指标来查看来自客户端应用程序的网络流量的更多详细信息：
+ **NetworkReceiveThroughput**— Amazon DocumentDB 集群中每个实例从客户端接收的网络吞吐量。此吞吐量不包括集群中的实例与集群存储卷之间的网络流量。
+ **NetworkTransmitThroughput**— Amazon DocumentDB 集群中每个实例发送给客户端的网络吞吐量。此吞吐量不包括集群中的实例与集群存储卷之间的网络流量。
+ **StorageNetworkReceiveThroughput**— 集群中每个实例从 Amazon DocumentDB 集群存储卷接收的网络吞吐量。
+ **StorageNetworkTransmitThroughput**— 集群中每个实例发送到 Amazon DocumentDB 集群存储卷的网络吞吐量。
将所有这些指标相加，以评估您的网络使用量与实例类限制的对比情况。实例类限制应大于这些组合指标的总和。
网络限制和实例的 CPU 利用率是相互的。当网络吞吐量增加时，CPU 利用率也会增加。监控 CPU 和网络使用情况可提供有关资源耗尽的方式和原因的信息。
为了帮助显著减少网络使用量，您可以考虑：
+ 使用更大的实例类。
+ 批量划分写入请求以减少总体事务量。
+ 将只读工作负载定向到只读实例。
+ 删除任何未使用的索引。
### 优化查询
提高集群性能的最佳方式之一是优化最常使用和占用最多资源的查询，以降低其运行成本。
您可以使用分析器（请参阅 [分析 Amazon DocumentDB 操作](profiling.md)）来记录在您集群上执行的操作的执行时间和详细信息。对于监控集群上速度最慢的操作以帮助您提高单个查询的性能和整体集群性能，分析器非常有用。
您还可以使用 `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 [索引工具](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` and/or`batchUpdate`操作速率并且主实例上的`FreeableMemory`（CloudWatch 指标）量变为零时，您可以减少批量插入或更新工作负载的并发性，或者如果无法降低工作负载的并发性，则可以增加实例大小以增加数量。`FreeableMemory`