Amazon DynamoDB
开发人员指南 (API 版本 2012-08-10)
AWS 文档中描述的 AWS 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 Amazon AWS 入门

在 DynamoDB 中处理时间序列数据的最佳实践

DynamoDB 中的一般设计准则建议将使用的表的数量保持最小值。对于大多数应用程序,只需单个表即可。但是,对于时间序列数据,或任何单调增加或减少主键值的数据,通常可以通过使用不遵循此准则的设计模式来进行最佳处理。

时间序列数据的设计模式

考虑您想跟踪大量活动的典型时间序列场景。您的写入访问模式即要记录的所有事件都具有今日日期。您的读取访问模式读取今日事件的频率最高,读取昨日事件的频率小很多,而读取更早事件的频率是最低的。

读取访问模式通过将当前日期和时间构建为主键得到了最佳处理。但这肯定会创建一个或多个热分区。最新分区始终是正在写入到的唯一 分区。所有其他分区 (包括之前日期的所有分区) 都会将配置的写入容量从最需要它的位置转移。

以下设计模式通常会高效地处理此类场景:

  • 为每个时间段创建一个表,每个分区键值配置少于 1000 个写入容量单位 (WCU) 的写入容量以及最少必要读取容量。

  • 在每个时间段结束之前,为下一个时间段预构建表。在当前时间段结束时,事件流量将定向至新表。可以为这些表分配名称以指定表已记录的时间段。

  • 只要表不再被写入,就将其配置的写入容量降至 1 WCU 并配置适当的读取容量。当之前的表变旧时减少其配置的读取容量,存档或删除很少需要或根本不需要其内容的表。

这旨在确保配置的写入容量得到充分使用而不是由未写入内容的分区稀释。使用其值 (如时间值) 单调地更改的分区键,这意味着尝试阻止拆分任何物理分区。这是因为,在拆分后,所有后续写入操作将仅对拆分所生成的两个分区之一执行。

针对大量事件流的设计

对于此设计,要记住两个关键数字。首先,物理分区只能支持 1000 个 WCU (每秒写入数,每单位的大小多达 1 KB)。其次,它总共只能包含 10GB 数据。如果超出上述任一限制,将拆分分区。

考虑到这一点,以下是针对大量传入事件流进行设计的方法:

  1. 确定 DynamoDB 中每个事件项目的大小。这实际上应该非常小,如有可能,远不到 1 KB,1 KB 是单个 WCU 能容纳的最大大小。

  2. 估计一个物理分区 (10GB) 可容纳此类事件项目的数量,包括用于管理开销的小空间。

  3. 估计每秒要写入的传入事件的数量。通过此数计算物理分区在超出 10GB 限制之前平均可服务的秒数。选择稍短于此持续时间的方便时段(如 1 小时、6 小时或 12 小时期间、一天或任何时间段)作为每个表的时段。

    如果传入事件流的节奏高于每秒 1000 个事件,该怎么办?

    应用程序可通过对使用的分区键进行写入分片来处理此问题 (请参阅使用写入分片均匀分发工作负载)。例如,如果预计每秒平均事件频率为 5000 个事件以及每秒最高事件频率为 6000 个事件,则应用程序可追加到具有从 _1_6 的分片后缀的分区键。这将创建 6 个物理分区,传入事件在到达后将均匀地分布这些分区中,并且您可为表配置 6000 个 WCU。

  4. 将应用程序设定为为每个时间段预构建一个新表。为此表配置足够的吞吐容量以处理预计的传入事件工作负载。在新表准备就绪后,当此表的时间段开始时,将传入事件数据定向到此表而不是上一个时间段的表。

  5. 现在上一时间段的表不再记录新事件,可将其配置的写入容量降回 1 WCU。您可以将其读取容量更改为所需的任何大小以支持预计的读取工作负载。

  6. 在每个表的时间段过去足够长的时间后,将不会频繁需要它,可将其存档至其他存储选项 (如 Amazon Simple Storage Service (Amazon S3) 或 Amazon Glacier)。或者,如果不再需要较旧的表中的数据,则可删除整个表。这样做的效率明显高于逐一移动或删除项目。

时间序列表示例

下面是时间序列表的示例,时间序列表设计为每秒处理约 600 个事件,每个事件在 DynamoDB 中占用约 180 个字节。

按照此速度,10 GB 将需要约 26 或 27 个小时填满,因此,此设计将在每天的午夜启用新表:

 大量时间序列数据的表架构。