在 DynamoDB 中使用 Kinesis Data Streams 配置分片并监控更改数据捕获 - Amazon DynamoDB
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

在 DynamoDB 中使用 Kinesis Data Streams 配置分片并监控更改数据捕获

Kinesis Data Streams 的分片管理注意事项

Kinesis 数据流以分片形式计算其吞吐量。在 Amazon Kinesis Data Streams 中,您可以为数据流选择按需模式和预置模式。

如果您的 DynamoDB 写入工作负载变化很大且不可预测,我们建议您对 Kinesis Data Streams 使用按需模式。若采用按需模式,则无需容量规划,因为 Kinesis Data Streams 会自动管理分片来提供必要的吞吐量。

对于可预测的工作负载,您可以为 Kinesis Data Streams 使用预置模式。若采用预置模式,您必须为数据流指定分片数,以容纳 DynamoDB 的更改数据捕获记录。要确定 Kinesis 数据流支持 DynamoDB 表所需的分片数量,您需要以下输入值:

  • DynamoDB 表记录的平均大小,以字节为单位 (average_record_size_in_bytes)。

  • 每秒对 DynamoDB 表执行的最大写入操作数。这包括由您的应用程序执行的创建、删除和更新操作以及自动生成的操作,例如“生存时间”生成的删除操作(write_throughput)。

  • 您对表执行的更新和覆盖操作与创建或删除操作相比的百分比 (percentage_of_updates)。请注意,更新和覆盖操作会将已修改项目的旧镜像和新镜像复制到流中。这会生成两倍 DynamoDB 项目大小。

可使用以下公式中的输入值来计算 Kinesis 数据流所需的分片数量(number_of_shards)。

number_of_shards = ceiling( max( ((write_throughput * (4+percentage_of_updates) * average_record_size_in_bytes) / 1024 / 1024), (write_throughput/1000)), 1)

例如,您的最大吞吐量为 1040 个写入操作/秒(write_throughput),平均记录大小为 800 字节(average_record_size_in_bytes))。如果这些写入操作中有 25% 是更新操作(percentage_of_updates),则将需要两个分片(number_of_shards)来容纳您的 DynamoDB 流式传输吞吐量:

ceiling( max( ((1040 * (4+25/100) * 800)/ 1024 / 1024), (1040/1000)), 1).

在使用公式计算 Kinesis 数据流在预置模式下所需的分片数之前,请考虑以下几点:

  • 此公式有助于估算容纳 DynamoDB 更改数据记录所需的分片数量。它不代表 Kinesis 数据流中所需的分片总数,例如支持额外 Kinesis 数据流使用者所需的分片数量。

  • 如果您未将数据流配置为处理峰值吞吐量,则在预置模式下仍可能遇到读写吞吐量异常的问题。在这种情况下,您必须手动扩展数据流以适应数据流量。

  • 此公式考虑了 DynamoDB 在将更改日志数据记录流式传输到 Kinesis 数据流之前产生的额外膨胀。

要了解有关 Kinesis 数据流容量模式的更多信息,请参阅选择数据流容量模式。要详细了解不同容量模式之间的定价差异,请参阅 Amazon Kinesis Data Streams 定价

使用 Kinesis Data Streams 监控更改数据捕获

DynamoDB 提供多个 Amazon CloudWatch 指标,帮助您监控将更改数据捕获到 Kinesis 的复制。有关 CloudWatch 指标的完整列表,请参阅DynamoDB 指标与维度

我们建议您在流启用期间和生产中监视以下项目,以确定流是否有足够的容量:

  • ThrottledPutRecordCount:由于 Kinesis Data Streams 容量不足而受到 Kinesis 数据流限制的记录数量。异常使用高峰期间可能会遇到一些限制,但 ThrottledPutRecordCount 应保持尽可能低。DynamoDB 重试将受限制的记录发送到 Kinesis 数据流,这可能会导致更高的复制延迟。

    如果遇到过多和定期的限制,则可能需要按照观察到的表写入吞吐量成比例增加 Kinesis 流分片数量。要了解有关如何确定 Kinesis 数据流的大小的详细信息,请参阅确定 Kinesis Data Streams 的初始大小

  • AgeOfOldestUnreplicatedRecord:从等待复制的最早的项目级别更改,到 Kinesis 数据流出现在 DynamoDB 表中经过的时间。在正常运行情况下,AgeOfOldestUnreplicatedRecord 应该以毫秒为单位。如果失败的尝试由客户控制的配置选项造成,失败的复制尝试次数会增加。

    如果 AgeOfOldestUnreplicatedRecord 指标超过 168 小时,则将自动禁用从 DynamoDB 表到 Kinesis 数据流的项目级别更改的复制。

    例如,可能导致复制尝试失败的客户控制配置包括:预置不足的 Kinesis 数据流容量导致过度限制,或者手动更新 Kinesis 数据流的访问策略阻止 DynamoDB 向数据流添加数据。您可能需要确保预置合适的 Kinesis 数据流容量,并确保未更改 DynamoDB 的权限,才能将该指标保持在尽可能低的水平。

  • FailedToReplicateRecordCount:DynamoDB 无法复制到 Kinesis 数据流的记录数。某些大于 34KB 的项目可能会扩增,以更改大于 Kinesis Data Streams 1MB 项目大小限制的数据记录。当大于 34KB 的项目包含大量布尔值或空属性值时,就会出现此扩增现象。布尔值和空属性值在 DynamoDB 中存储为 1 个字节,但在使用标准 JSON 进行 Kinesis Data Streams 复制时,最多可扩展到 5 个字节。DynamoDB 无法将此类更改记录复制到 Kinesis 数据流中。DynamoDB 跳过这些更改数据记录,并自动继续复制后续记录。

您可以创建 Amazon CloudWatch 警报,以便在上述任何指标超过特定阈值时发送 Amazon Simple Notification Service (Amazon SNS) 消息,以便发送通知。有关更多信息,请参阅 创建 CloudWatch 警报以监控 DynamoDB