管理 DynamoDB 预调配容量表的吞吐量设置 - Amazon DynamoDB
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

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

管理 DynamoDB 预调配容量表的吞吐量设置

在 Amazon DynamoDB 中创建新的预置表时,您必须指定其预置的吞吐量容量。这是表可以支持的读取和写入活动量。DynamoDB 使用这些信息来预留足够的系统资源,以满足吞吐量需求。

注意

您可以创建按需模式表,这样不必管理服务器、存储或吞吐量的任何容量设置。DynamoDB 会随着工作负载的增加或减少,根据之前达到的任意流量水平即时调节工作负载。如果某个工作负载的流量级别达到一个新的峰值,DynamoDB 将快速调整以适应该工作负载。有关更多信息,请参阅按需模式

您可以选择允许 DynamoDB Auto Scaling 管理表的吞吐容量。但是,创建表时,您仍必须提供读取和写入容量的初始设置。DynamoDB Auto Scaling 使用这些初始设置作为起点,然后动态调整以满足应用程序要求。有关更多信息,请参阅使用 DynamoDB Auto Scaling 自动管理吞吐能力

随着应用程序数据和访问要求的变化,您可能需要调整表的吞吐量设置。如果您使用 DynamoDB Auto Scaling,则吞吐量设置将自动调整以响应实际工作负载。您也可以使用 UpdateTable 操作来手动调整表的吞吐容量。如果您需要将现有数据存储中的数据批量加载到新的 DynamoDB 表中,则可能会决定执行此操作。您可以使用较大的写入吞吐量设置创建表,然后在批量加载完数据后减小此设置。

根据容量单位,应用程序每秒需要读取或写入的数据量指定吞吐量需求。您可以稍后修改这些设置(如果需要)或启用 DynamoDB Auto Scaling 以自动修改这些设置。

读取容量单位

一个读取容量单位表示对高达 4KB 大小的项目每秒执行一次强一致性读取,或每秒执行两次最终一致性读取。

注意

要了解有关 DynamoDB 读取一致性模型的更多信息,请参阅 读取一致性

例如,假设您创建一个带 10 个预置读取容量单位的表。对于最大 4KB 的项目,允许您每秒执行 10 次强一致性读取,或者每秒 20 次最终一致性读取。

读取大于 4KB 的项目时,将使用更多读取容量单位。例如,对 8 KB (4KB × 2) 的项目的强一致性读取占用 2 个读取容量单位。对同一项目执行最终一致性读取时,将仅使用 1 个读取容量单位。

对于读取操作,项目大小会向上取整为 4KB 的倍数。例如,读取一个 3500 字节的项目将使用的吞吐量与读取一个 4KB 项目相同。

读取的容量单位消耗

下面介绍 DynamoDB 读取操作如何占用读取容量单位:

  • GetItem—从表中读取单个项目。要确定 GetItem 将使用的容量单位的数量,请使用项目大小并将其向上取整到下一个 4KB 界限值。如果指定了强一致性读取,则这是所需的容量单位数。对于最终一致性读取(默认值),请将此数字除以 2。

    例如,如果您读取一个 3.5 KB 的项目,DynamoDB 会将项目大小向上取整到 4KB。如果您读取一个 10 KB 的项目,DynamoDB 会将项目大小向上取整到 12 KB。

  • BatchGetItem—从一个或多个表中读取多达 100 个项目。DynamoDB 将批次中的每个项目作为单个 GetItem 请求进行处理,因此 DynamoDB 会先将每个项目的大小向上取整到下一个 4KB 界限值,然后再计算总大小。计算得到的结果未必与所有项目大小的总和相同。例如,如果 BatchGetItem 读取一个 1.5 KB 的项目和一个 6.5 KB 的项目,则 DynamoDB 计算得出的大小为 12 KB (4KB + 8 KB),而不是 8 KB (1.5 KB + 6.5 KB)。

  • Query-读取具有相同分区键值的多个项目。返回的所有项目将视为一个读取操作,此时 DynamoDB 会计算所有项目的总大小,然后向上取整到下一个 4KB 界限值。例如,假设查询返回 10 个项目,其组合大小为 40.8 KB。DynamoDB 将操作的项目大小舍入为 44KB。如果查询返回了 1500 个项目,每个项目大小为 64 个字节,则累计大小为 96 KB。

  • Scan-读取表中的所有项。DynamoDB 考虑的是所评估的数据的大小,而不是扫描返回的数据的大小。

如果对不存在的项目执行读取操作,DynamoDB 仍会占用预置读取吞吐量:强一致性读取请求占用一个读取容量单位,而最终一致性读取请求占用 0.5 个读取容量单位。

对于返回项目的任意操作,您可以请求检索属性的子集。不过,这样做对项目大小计算没有影响。另外,QueryScan 返回的是项目数而不是属性值。获取项目计数使用相同数量的读取容量单位,并且需要执行相同的项目大小计算。这是因为 DynamoDB 必须读取每个项目才能增加计数。

读取操作和读取一致性

前面的计算都假设提交的是强一致性读取请求。对于最终一致性读取请求,操作仅占用一半的容量单位。对于最终一致性读取,如果项目总大小为 80 KB,则操作仅占用 10 个容量单位。

写入容量单位

一个写入容量单位表示对大小最多为 1 KB 的项目每秒执行一次写入。

例如,假设您创建一个带 10 个写入容量单位的表。这允许对于最大 1 KB 的项目,每秒执行 10 次写入操作。

对于写入操作,项目大小会向上取整为 1 KB 的倍数。例如,写入一个 500 字节的项目使用的吞吐量与写入一个 1 KB 项目相同。

写入的容量单位消耗

下面介绍 DynamoDB 写入操作如何占用写入容量单位:

  • PutItem—将单个项目写入表中。如果该表中存在具有相同主键的项目,此操作会替换该项目。在计算预置的吞吐量占用时,起作用的项目是二者中较大的那个。

  • UpdateItem-修改表中的单个项目。DynamoDB 将考虑项目在更新前后显示的大小。消耗的预置吞吐量反映这些项目大小中较大的数据。即使您只更新项目属性的子集,UpdateItem 仍会占用全部的预置吞吐量 (“之前”和“之后”项目大小中的较大者)。

  • DeleteItem—从表中删除单个项目。预置吞吐量占用情况取决于已删除的项目大小。

  • BatchWriteItem-向一个或多个表写入最多 25 个项目。DynamoDB 将批处理中的每个项目作为单独的 PutItem 或者 DeleteItem 请求(不支持更新)。因此,DynamoDB 会首先将每个项目的大小向上取整到下一个 1 KB 界限值,然后再计算总大小。计算得到的结果未必与所有项目大小的总和相同。例如,如果 BatchWriteItem 写入一个 500 字节的项目和一个 3.5 KB 的项目,则 DynamoDB 计算得出的大小为 5 KB (1 KB + 4KB),而不是 4KB(500 字节 + 3.5 KB)。

适用于PutItemUpdateItem, 和 DeleteItem 操作时,DynamoDB 会将项目大小四舍五入到下一个 1 KB。例如,如果放入或删除 1.6 KB 的项目,则 DynamoDB 会将项目大小舍入为 2 KB。

PutItemUpdateItemDeleteItem 允许有条件写入,其中指定一个表达式的求值结果必须为 true,才能成功执行操作。如果该表达式计算为 false,DynamoDB 仍会消耗表的写入容量单位。消耗量取决于项目的大小(无论是表中的现有项目,还是您正在尝试创建或更新的新项目)。例如,如果现有项目为 300kb,而您尝试创建或更新的新项目为 310kb,则消耗的写入容量单位将为 310kb 项目。

请求节流和容量暴增

如果您的应用程序执行读取或写入操作的速率高于表能够支持的速率,则 DynamoDB 将开始限制这些请求。当 DynamoDB 限制读取或写入时,它会将 ProvisionedThroughputExceededException 返回给调用方。随后,应用程序可以采取相应的措施,例如,在重试请求之前等待一段较短的间隔。

注意

我们建议您使用软件开发 Amazon 工具包进行软件开发。 Amazon SDK 提供对重试受限制请求的内置支持;您无需自行编写此逻辑。有关更多信息,请参阅错误重试和指数回退

DynamoDB 控制台显示您的表的 CloudWatch Amazon 指标,因此您可以监控受限的读取请求和写入请求。如果您遇到过多的限制,则应考虑增大表的预置吞吐量设置。

在某些情况下,DynamoDB 使用容量暴增来容纳超出表吞吐量设置的读取或写入。利用容量暴增,意外的读取或写入请求可在原本会受限制的环境中获得成功。有关更多信息,请参阅有效使用容量暴增

请求节流和自适应容量

DynamoDB 会自动跨分区分发您的数据,这些分区存储在云中的多个服务器上(有关更多信息 Amazon ,请参阅)。分区和数据分布不可能总是均匀地分布读活动和写活动。当数据访问不平衡时,与其他分区相比,“热”分区可以接收更高的读取和写入流量。自适应容量的工作原理是,自动增加分区的吞吐量容量来接收更多流量。有关更多信息,请参阅了解 DynamoDB 自适应容量

选择初始吞吐量设置

每个应用程序对在数据库中执行的读取和写入有不同的要求。在确定 DynamoDB 表的初始吞吐量设置时,请考虑以下输入:

  • 项目大小。一些项目足够小,可使用单个容量单位进行读取或写入。较大的项目需要多个容量单位。通过估计表中将包含的项目的大小,您可以为表的预置吞吐量指定正确设置。

  • 预期的读取和写入请求速率。除了项目大小之外,您还应估计每秒需要执行的读取和写入次数。

  • 读取一致性要求。读取容量单位基于强一致性读取操作,这些操作占用的数据库资源是最终一致性读取的两倍。您应确定您的应用程序是否需要强一致性读取,或者是否能放宽此要求并改为执行最终一致性读取操作。(默认情况下,DynamoDB 中的读取操作最终是一致性读取。如有必要,您可以请求执行这些操作的强一致性读取。)

例如,假设您希望从表中每秒读取 80 个项目。这些项目的大小为 3 KB,而且您需要强一致性读取。在这种情况下,每次读取需要一个预置读取容量单位。为确定此数字,您应将此操作的项目大小除以 4KB,然后向上取整到最近的整数,如下所示:

  • 3 KB / 4KB = 0.75,或者 1 读取容量单位

在这种情况下,您必须将表的预置读取吞吐量设置为 80 个读取容量单位:

  • 每个项目 1 个读取容量单位 x 每秒 80 次读取 = 80 个读取容量单位

现在假设您希望每秒向您的表写入 100 个项目,并且项目大小为 512 个字节。在这种情况下,每次写入需要一个预置写入容量单位。为确定此数字,您应将此操作的项目大小除以 1 KB,然后向上舍入到最近的整数,如下所示:

  • 512 个字节/1 KB = 0.5 或 1

在这种情况下,您需要将表的预置写入吞吐量设置为 100 个写入容量单位:

  • 每个项目 1 个写入容量单位 x 每秒 100 次写入 = 100 个写入容量单位

注意

有关预配置吞吐量和相关主题的建议,请参阅 设计分区键并有效使用的最佳实践

修改吞吐量设置

如果您已为表启用 DynamoDB Auto Scaling,则其吞吐容量将动态调整以响应实际使用情况。无需手动干预。

您可以使用 Amazon Web Services Management Console 或UpdateTable操作修改表的预配置吞吐量设置。有关每天的吞吐量增加和减少的更多信息,请参阅 Amazon DynamoDB 中的服务、账户和表限额

排查节流问题

要对看似与节流相关的问题进行问题排查,首先要确认节流是来自 DynamoDB 还是来自应用程序。

以下是一些常见场景以及帮助解决这些问题的可能步骤。

DynamoDB 表似乎有足够的预置容量,但请求受到限制。

当吞吐量低于每分钟平均值但吞吐量超过每秒可用量时,就会发生这种情况。DynamoDB 仅 CloudWatch向报告分钟级别的指标,然后将这些指标计算为一分钟的总和并求平均值。但是 DynamoDB 本身会应用每秒的速率限制。因此,如果在这分钟的一小段时间(例如几秒钟或更短)内出现了过多的吞吐量,则这分钟剩余时间的请求可能会受到限制。例如,如果我们在表上预置了 60 个 WCU,那么它可以在 1 分钟内完成 3600 次写入。但是,如果所有 3600 个 WCU 请求都在同一秒内到达,那么那一分钟的剩余时间将受到限制。

解决这个问题的一种方法是在 API 调用中添加一些抖动和指数退避。有关更多信息,请参阅这篇有关退避和抖动的博文。

自动扩缩已启用,但表仍会受到限制。

这可能发生在流量突然猛增期间。当两个数据点在一分钟内突破配置的目标利用率值时,可以触发自动扩展。因此,之所以可以进行自动扩展,是因为消耗的容量在连续两分钟内高于目标利用率。但是,如果峰值间隔超过一分钟,则可能不会触发自动缩放。同样,当 15 个连续的数据点低于目标利用率时,可以触发缩减事件。无论哪种情况,触发 auto Scaling 后都会UpdateTable调用一个调用。然后,可能需要几分钟才能更新表或索引的预配置容量。在此期间,任何超出表先前预配置容量的请求都将受到限制。

总之,自动扩缩需要连续的数据点超出目标利用率值,才能纵向扩展 DynamoDB 表。因此,不建议将自动扩缩作为处理高峰工作负载的解决方案。有关更多信息,请参阅自动扩缩文档

表处于“按需”容量模式,但仍处于限制状态。

对于按需表,当您的流量增加时,DynamoDB 会自动分配更多容量。只要访问权限均匀地分布在各个分区中,并且该表的流量不超过其先前峰值流量的两倍,整个表就不会受到限制。但是,如果吞吐量在 30 分钟内超出先前峰值的两倍,则可能发生节流。有关更多信息,请参阅OnDemand 缩放

热键可能会导致节流问题。

在 DynamoDB 中,基数不高的分区键可能会导致许多请求,这些请求仅针对几个分区。如果生成的“热分区”超过了每分区每秒 3000 RCU 或 1000 WCU 的限制,这可能会导致节流。诊断工具 Cont CloudWatch ributor Insights 可以通过为每个表的项目访问模式提供 CCI 图表来帮助调试此问题。您可以持续监控 DynamoDB 表中最常访问的键值和其他流量趋势。要了解有关 CloudWatch 投稿人见解的更多信息,请参阅 CCI。有关选择正确热键的具体信息,请参阅选择正确的热键

使用 CloudWatch 指标来调查限制

以下是在节流事件期间需要监控的一些 DynamoDB 指标,以帮助确定哪些操作正在创建受限请求并确定根本问题。

1。 ThrottledRequests

  • 一个受限请求可以包含多个受限事件,因此检查事件更为相关。

    例如,如果使用 GSI 更新表中的项目,则存在多个事件 - 对表的写入和对每个索引的写入。即使这些事件中的一个或多个被限制,也只会有一个。 ThrottledRequest

2。 ReadThrottleEvents

  • 留意是否有超出表或 GSI 的预置 RCU 的请求。

3。 WriteThrottleEvents

  • 留意是否有超出表或 GSI 的预置 WCU 的请求。

4。 OnlineIndexConsumedWriteCapacity

  • 注意向表添加新的 GSI 时消耗的 WCU 数。请注意,GSI 的 ConsumedWriteCapacityUnits 不包括索引创建过程中消耗的 WCU。

  • 如果您将 GSI 的 WCU 设置得过低,回填阶段的传入写入活动可能会受到限制。

5。 OnlineIndexThrottleEvents

  • 查看向表添加新的 GSI 时发生的写入限制事件数。

  • 如果您发现 WCU 设置得过低并且受到限制,则即使在回填期间也可以更新 GSI 的 WCU 值。

6. Provisioned Read/Write

  • 查看表或指定的全局二级索引在指定时间段内消耗的预置读取或写入容量单位数。

  • 请注意,默认情况下,TableName 维度仅返回表的 ProvisionedReadCapacityUnits。要查看全局二级索引的预置读取或写入容量单位数,您必须指定 TableNameGlobalSecondaryIndexName

7. Consumed Read/Write

  • 查看在指定时间段内消耗了多少读取或写入容量单位。

有关 DynamoDB CloudWatch 指标的更多信息,请参阅指标和维度。