与 DynamoDB 集成的最佳实践 - Amazon DynamoDB
创建快照更改数据捕获与 OpenSearch Service 的零 ETL 集成
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异，请参阅 中国的 Amazon Web Services 服务入门 (PDF)。

与 DynamoDB 集成的最佳实践

将 DynamoDB 与其它服务集成时，应始终遵循使用每项服务的最佳实践。但是，您应该考虑一些特定于集成的最佳实践。

在 DynamoDB 中创建快照

  • 通常，我们建议使用导出到 Amazon S3 来创建用于初始复制的快照。它既具有成本效益，又不会与应用程序的流量争夺吞吐量。您也可以考虑备份并恢复到新表，然后再执行扫描操作。这样可以避免与应用程序争夺吞吐量，但成本效益通常要比导出低得多。

  • 导出时请务必设置 StartTime。这样可以轻松确定从何处开始更改数据捕获（CDC）。

  • 使用导出到 S3 时，请在 S3 存储桶上设置生命周期操作。通常，将到期操作设置为 7 天是安全的，但需要遵循公司可能制定的任何指导准则。即使您在摄取后明确删除项目，此操作也有助于发现问题，从而有助于减少不必要的成本并防止违反政策。

在 DynamoDB 中捕获数据更改

  • 如果您需要近乎实时的 CDC，可以使用 DynamoDB Streams 或 Amazon Kinesis Data Streams（KDS）。在决定使用哪个服务时，通常要考虑哪个最容易与下游服务一起使用。如果您需要在分区键级别按顺序处理事件，或者您的项目非常大，请使用 DynamoDB Streams。

  • 如果您不需要近乎实时的 CDC，则可以使用通过增量导出来导出到 Amazon S3，仅导出两个时间点之间发生的更改。

    如果您使用导出到 S3 来生成快照，这可能特别有用，因为您可以使用类似的代码来处理增量导出。通常，导出到 S3 比以前的流式传输选项稍微便宜一些，但成本通常不是使用哪个选项的主要因素。

  • 通常，一个 DynamoDB 流只能有两个用户同时使用。在规划集成策略时要考虑这一点。

  • 不要使用扫描来检测更改。这可能对小规模有效，但很快就会变得相当不切实际。

DynamoDB 与 OpenSearch Service 的零 ETL 集成

DynamoDB 已实现DynamoDB 与 Amazon OpenSearch Service 的零 ETL 集成。有关更多信息，请参阅适用于 OpenSearch Ingestion 的 DynamoDB 插件和 Amazon OpenSearch Service 的具体最佳实践。

配置

  • 仅对需要执行搜索的数据编制索引。请务必使用映射模板（template_type: index_template 和 template_content）和 include_keys 来实现这一点。

  • 监控日志中是否存在与类型冲突相关的错误。OpenSearch Service 期望给定键的所有值都具有相同的类型。如果不匹配，则会引发异常。如果您遇到其中一个错误，可以添加一个处理器来捕获给定的键始终是相同的值。

  • 通常使用 primary_key 元数据值作为 document_id 值。在 OpenSearch Service 中，文档 ID 等同于 DynamoDB 中的主键。使用主键可以轻松找到您的文档，并确保更新始终如一地复制到该文档而不会发生冲突。

    您可以使用帮助程序函数 getMetadata 来获取您的主键（例如，document_id: "${getMetadata('primary_key')}"）。如果您使用的是复合主键，则帮助程序函数会将它们连接在一起。

  • 通常，使用 opensearch_action 元数据值进行 action 设置。这将确保以这样的方式复制更新，使 OpenSearch Service 中的数据与 DynamoDB 中的最新状态相匹配。

    您可以使用帮助程序函数 getMetadata 来获取您的主键（例如，action: "${getMetadata('opensearch_action')}"）。对于筛选等用例，您也可以通过 dynamodb_event_name 获取流事件类型。但是，通常不应将其用于 action 设置。

可观察性

  • 始终在 OpenSearch 接收器上使用死信队列（DLQ）来处理丢弃的事件。DynamoDB 的结构化通常不如 OpenSearch Service，而且总是有可能发生意想不到的事情。使用死信队列，您可以恢复各个事件，甚至自动执行恢复过程。这将有助于您避免重建整个索引。

  • 请务必设置警报，让您的复制延迟不会超过预期值。通常情况下，假设为一分钟比较安全，警报也不会太吵。这可能会有所不同，具体取决于您的写入流量激增程度以及管道上的 OpenSearch 计算单位（OCU）设置。

    如果您的复制延迟超过 24 小时，则您的流将开始丢弃事件，除非您从头开始完全重建索引，否则您将遇到准确性问题。

扩展

  • 对管道使用自动扩缩来协助纵向或横向扩展 OCU 以很好地满足工作负载需求。

  • 对于没有自动扩缩的预置吞吐量表，我们建议根据写入容量单位（WCU）除以 1000 来设置 OCU。将最小值设置为低于该数量 1 个 OCU（但至少为 1），并将最大值设置为至少比该数量高出 1 个 OCU。

    • 公式：

      OCU_minimum = GREATEST((table_WCU / 1000) - 1, 1)
OCU_maximum = (table_WCU / 1000) + 1

    • 示例：您的表已置 25000 个 WCU。您管道的 OCU 应设置为最少 24（25000/1000 - 1），最大值应设置为至少 26（25000/1000 + 1）。

  • 对于有自动扩缩的预置吞吐量表，我们建议根据最小和最大 WCU 除以 1000 来设置 OCU。将最小值设置为低于 DynamoDB 中最小值 1 个 OCU，并将最大值设置为至少比 DynamoDB 中最大值高 1 个 OCU。

    • 公式：

      OCU_minimum = GREATEST((table_minimum_WCU / 1000) - 1, 1)
OCU_maximum = (table_maximum_WCU / 1000) + 1

    • 示例：您的表具有自动扩缩策略，最小值为 8000，最大值为 14000。您管道的 OCU 应最少设置为 7（8000/1000 - 1），最大值应设置为 15（14000/1000 + 1）。

  • 对于按需吞吐量表，我们建议根据每秒写入请求单位的典型峰值和谷值来设置 OCU。您可能需要取更长时间段的平均值，具体取决于可用的聚合。将最小值设置为低于 DynamoDB 中最小值 1 个 OCU，并将最大值设置为至少比 DynamoDB 中最大值高 1 个 OCU。

    • 公式：

      # Assuming we have writes aggregated at the minute level
OCU_minimum = GREATEST((min(table_writes_1min) / (60 * 1000)) - 1, 1)
OCU_maximum = (max(table_writes_1min) / (60 * 1000)) + 1

    • 示例：您表的平均谷值为每秒 300 个写入请求单位，平均峰值为 4300。您管道的 OCU 应最少设置为 1（300/1000 - 1，但至少为 1），最大值应设置为 5（4300/1000 + 1）。

  • 请遵循扩展目标 OpenSearch Service 索引的最佳实践。如果您的索引规模不足，则会减慢 DynamoDB 的摄取速度，并可能导致延迟。

注意

GREATEST 是一个 SQL 函数，在给定一组参数的情况下，它返回值最大的参数。