设计分区键来分配工作负载 - Amazon DynamoDB
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

设计分区键来分配工作负载

表主键的分区键部分确定存储表数据的逻辑分区,反过来会影响底层物理分区。不能有效分配 I/O 请求的分区键设计会产生“热”分区,从而导致节流且不能有效地使用预置 I/O 容量。

要最佳使用表的预置吞吐量,不仅取决于各个项目的工作负载模式,还取决于分区键设计。这并不意味着必须访问所有分区键值以实现高效吞吐量,或者已访问分区键值的百分比必须非常高,而是工作负载访问的分区键值越不同,请求在已分配空间分配越多。通常随着访问分区键值数量与分区键值总数的比值增加,使用预置吞吐量的效率将提高。

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

分区键值 均匀性

用户 ID,应用程序有多个用户。

状态代码,只有少数几个可能的状态代码。
项目创建日期,四舍五入至最近的时间(例如,天、小时或分钟)。
设备 ID,每个设备以相对类似间隔访问数据。
设备 ID,即使跟踪多个设备,但其中一个设备远比所有其他设备热门。

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

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

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

要使用 NoSQL Workbench for DynamoDB 来帮助可视化您的分区键设计,请参阅使用 NoSQL Workbench 构建数据模型