扩展 DynamoDB：分区、热键和分割如何影响性能（第 3 部分：摘要和最佳实践）

在本系列 的 第 1 部分 中，您了解了 Amazon Dynamo DB 数据加载策略以及 DynamoDB 在短期运行期间的行为。在 第 2 部分 中 ，您了解了查询性能和 DynamoDB 在持续活动期间的自适应行为。

在第三篇也是最后一篇文章中，我们将回顾您所学到的内容，并就扩展 DynamoDB 时的最佳实践提供一些其他见解。这篇文章旨在用作参考。

分区

作为无服务器 NoSQL 数据库，DynamoDB 可通过分区进行扩展。额外的分区为读取和写入提供了更多的容量。

表可能出于多种原因添加分区，例如：

• 预配置表的吞吐量值提高得比以前任何时候都要高。
• 按需表显示，获得的吞吐量创下了新的高水位线。
• 分区的大小接近 10 GB。
• 分区接收接近其吞吐容量限制的读取或写入流量。

今天的分区只是拆分的，从来没有合并的。预置为高容量然后配置为较低容量的表，或切换到按需模式的表将保留其分区。当你预计新的按需表会有大量流量时，最好通过创建按需配置的表来对表格进行预热，然后将其切换到按需配置。

也就是说，分区数超过必要数会降低表的效率（延迟和成本），例如，可能需要 遍历 更多分区 才能 生成查询和扫描结果。因此，最好不要提供超出预期需求的资源。

分区及其拓扑决定了表在任何给定秒内可以实现的最大吞吐量。出于各种原因，请求可能会收到吞吐量超出异常的情况，包括：

• 它访问的分区在那一秒内已达到极限。
• 这是一张处于预置模式的表，其吞吐量超过预置量。
• 这是按需模式下的表，其吞吐量超过表级读取和写入吞吐量限制。

突发容量允许暂时过度使用表级限制，但分区级别限制始终是强制性的。

分区键

具有相同分区键值的项目（称为 项目集合 ）最初往往位于同一个分区中，但如果项目集合被拆分为多个分区，则可能位于不同的分区中。

此外，具有不同分区键值的项目通常位于同一个分区中，因为大多数设计的分区键值多于分区键值。项目是根据其分区键哈希值分配的。每个分区负责密钥空间的特定范围，并且是哈希值在其范围内的项目的所在地。

设计分区键值分散度大（高基数）的表架构自然会将数据分散到各个分区，并且可以提高加载速率和查询速率。低基数分区键（包括全局二级索引 (GSI) 分区键）往往会降低数据的顺畅分布，并可能导致分区之间的使用不均衡。

请注意，加载顺序数据（其中项目按分区键排序，使负载集中在一个分区键上）会产生滚动热分区。

分开加热

当表的分区之间的流量不均匀时，split for heat 可能能够通过拆分接收不均匀流量的分区将具有相同分区键值的数据项分散到不同的分区。这是一个实现细节，用于准确确定何时以及如何适用 split for heat。

自适应容量功能，包括热量分割和突发容量，可在基台和 GSI 上使用。

表中存在任何本地二级索引 (LSI) 可防止项目集合中发生分区拆分。出于这个原因，考虑使用 GSI 而不是 LSI，即使 GSI 的分区键与基表相同。如果我们在 第 1 部分 和第 2 部分 中的测试表是使用 LSI 创建的，那么我们的查询率将永远不会超过初始速率。

只有当它根据最近的活动确定拆分足够有益时，才会执行 Split for Heat。 一种常见的写入模式是写入具有特定分区键值和不断增加的排序键值（例如时间戳）的项目，因为无论选择哪个切入点，使用该分区键的所有新写入操作都将在第二个分区上。 这种写入模式会将该分区键的写入活动限制为 1,000 个 WCU。如果排序键是随机的，则拆分将是有益的，因此分区键可以支持无界的 WCU。

这个事实对于 GSI 和基表都是如此。如果您设计的GSI具有低基数分区键和不断增加的排序键，则可能会遇到无法缓解分散热量的写入限制。写入限制的 GSI 会产生反压，从而限制基表上的写入。

表需要几分钟才能检测到分区拆分并适应分区拆分。没有提示分区何时分裂；性能只会得到改善。大多数客户从来没有意识到 DynamoDB 已经自动适应了他们的工作负载。

结算和成本核算

那么，亚马逊云科技 告诉埃森哲联邦服务了什么？请记住，当他们想知道时，正是他们的问题开始了这个实验：

• 对于查询服务，DynamoDB 的运行效果如何。
• 哪种表格设计最有效。
• 就运行时间、成本和可扩展性而言，哪种设计最有效。
• 理论上每秒 DynamoDB 可以达到的最大查找次数是多少。
• 他们还担心他们的用例看起来不像经典的 DynamoDB 用例，因为没有明显的分区键。他们想知道这是否会限制性能。

亚马逊云科技 告诉他们 DynamoDB 会运行良好，使用一个静态分区键值会起作用，但使用第一个 IP 号可以帮助它更快地扩展，而且该表可以达到的查询速率没有实际限制。

在成本方面，亚马逊云科技估计，基于DynamoDB的解决方案加载项目的成本约为0.18美元，存储费用为每月0.05美元，在完全灵活的按需模式下，他们可以花1美元进行800万次查询。

结论

在这个由三部分组成的系列中，您通过回顾使用不同的分区键设计测试加载和查询性能的结果，了解了 DynamoDB 的内部结构。我们讨论了表分区、分区键值、热分区、热分区、突发容量和表级吞吐量限制。

与往常一样，欢迎您在评论中留下问题或反馈。

作者简介

杰森·亨特 是加利福尼亚的首席解决方案架构师，专门研究 DynamoDB。自 2003 年以来，他一直在使用 NoSQL 数据库。他以对 Java、开源和 XML 的贡献而闻名。

Vivek Natarajan 是普渡大学主修计算机科学，也是 亚马逊云科技 的解决方案架构师实习生。