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

设计分区键以均匀分发工作负载

表的主键的分区键部分确定存储表数据的逻辑分区。这反过来会影响底层物理分区。将在这些物理分区间平均分配表的预置 I/O 容量。因此,不均匀分发 I/O 请求的分区键设计会创建“热”分区,从而导致限制出现并不能有效地使用预置 I/O 容量。

表的预置吞吐量的最佳使用不仅取决于各个项目的工作负载模式,还取决于分区键设计。这并不意味着您必须访问所有分区键值才能实现有效的吞吐量级别,甚至也不意味着已访问分区键值的百分比必须非常高。这确实意味着,您的工作负载访问的不同分区键值越确切,跨已分区空间分发的请求越多。一般来说,随着被访问过的分区键值的数量与分区键值总数的比率不断增大,您将更高效地使用预置吞吐量。

下面比较了一些常见分区键架构的预置吞吐量效率:

分区键值 均一

用户 ID,应用程序中有许多用户。

状态代码,只有几个可用的状态代码。
项目创建日期,四舍五入至最近的时间段 (例如,天、小时或分钟)。
设备 ID,每个设备以相对类似的间隔访问数据.
设备 ID,被跟踪的设备有很多,但到现在为止,其中某个设备比其他所有设备更加常用。

如果单个表只有少量的分区键值,请考虑在更多的非重复分区键值之间分布写入操作。也就是说,设计主键元素的结构,避免出现“热点” (请求频率非常高的) 分区键值而导致整体性能降低。

例如,最好设计具有复合主键的表。分区键代表项目创建日期,四舍五入至最近的一天。排序键表示项目标识符。在指定的某天,假设为 2014-07-09所有新项目都将写入到单个分区键值 (和对应的物理分区)。

如果表可以完全放入单个分区中 (考虑数据会随时间增加),并且应用程序读取和写入吞吐量要求未超过单个分区的读取和写入容量,则应用程序不会由于分区而遇到任何意外的限制。

但是,如果预计表会扩展到单个分区之外,则应该设计应用程序架构,使应用程序能够更好地利用表的全部预置吞吐量。