本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 估算 Amazon Keyspaces 中读取和写入吞吐量的容量消耗 当您在 Amazon Keyspaces 中读取或写入数据时，您的查询消耗的 read/write 请求单位 (RRUs/WRUs) or read/write capacity units (RCUs/WCUs) 数量取决于亚马逊密钥空间为运行查询而必须处理的数据总量。在某些情况下，返回给客户端的数据可能是 Amazon Keyspaces 为处理查询而必须读取的部分数据。对于条件写入，即使条件检查失败，Amazon Keyspaces 也会消耗写入容量。 要估算请求处理的数据总量，必须考虑行的编码大小和总行数。本主题涵盖一些常见场景和访问模式的示例，向您展示 Amazon Keyspaces 如何处理查询以及对容量消耗的影响。您可以按照示例估算表的容量需求，并使用 Amazon CloudWatch 观察这些用例的读取和写入容量消耗。 有关如何计算 Amazon Keyspaces 中行的编码大小的信息，请参阅[估算 Amazon Keyspaces 中的行大小](calculating-row-size.md)。 **Topics** + [估算 Amazon Keyspaces 中范围查询的容量消耗](range_queries.md) + [估算限制查询的读取容量消耗](limit_queries.md) + [估算表扫描的读取容量消耗](table_scans.md) + [估算 Amazon Keyspaces 中轻量级事务的容量消耗](lightweight_transactions.md) + [估算 Amazon Keyspaces 中静态列的容量消耗](static-columns.md) + [在 Amazon Keyspaces 中为多区域表估算和预置容量](tables-multi-region-capacity.md) + [估算亚马逊 CloudWatch 在 Amazon Keyspaces 中的读取和写入容量消耗](estimate_consumption_cw.md) # 估算 Amazon Keyspaces 中范围查询的容量消耗 要查看范围查询的读取容量消耗，我们使用以下示例表，该表使用按需容量模式。 ``` pk1 | pk2 | pk3 | ck1 | ck2 | ck3 | value -----+-----+-----+-----+-----+-----+------- a | b | 1 | a | b | 50 | a | b | 1 | a | b | 60 | value_1 a | b | 1 | a | b | 70 | ``` 现在，对该表运行以下查询。 ``` SELECT * FROM amazon_keyspaces.example_table_1 WHERE pk1='a' AND pk2='b' AND pk3=1 AND ck1='a' AND ck2='b' AND ck3 > 50 AND ck3 < 70; ``` 您从查询中收到以下结果集，Amazon Keyspaces 执行的读取操作 RRUs 在一`LOCAL_QUORUM`致模式下消耗 2。 ``` pk1 | pk2 | pk3 | ck1 | ck2 | ck3 | value -----+-----+-----+-----+-----+-----+------- a | b | 1 | a | b | 60 | value_1 ``` Amazon Keyspaces 消耗 2 RRUs 来评估包含这些值的行`ck3=60``ck3=70`并处理查询。但是，Amazon Keyspaces 仅返回查询中指定的 `WHERE` 条件为 true 的行，即值为 `ck3=60` 的行。为了评估查询中指定的范围，Amazon Keyspaces 会读取与该范围上限匹配的行（在本例中为 `ck3 = 70`），但不会在结果中返回该行。读取容量消耗基于处理查询时读取的数据，而不是返回的数据。 # 估算限制查询的读取容量消耗 在处理使用 `LIMIT` 子句的查询时，Amazon Keyspaces 会在尝试匹配查询中指定的条件时读取达到最大页面大小的行数。如果 Amazon Keyspaces 找不到符合第一页上 `LIMIT` 值的足够多的匹配数据，则可能需要进行一次或多次分页调用。要继续阅读下一页，可以使用分页令牌。默认页面大小为 1MB。如果希望在使用 `LIMIT` 子句时消耗较少的读取容量，可以缩小页面大小。有关分页的更多信息，请参阅[对 Amazon Keyspaces 中的结果进行分页](paginating-results.md)。 例如，我们来看下以下查询。 ``` SELECT * FROM my_table WHERE partition_key=1234 LIMIT 1; ``` 如果您不设置页面大小，Amazon Keyspaces 会读取 1MB 的数据，即使它只向您返回 1 行。要让 Amazon Keyspaces 只读取一行，您可以将此查询的页面大小设置为 1。在这种情况下，Amazon Keyspaces 只能读取一行，前提是您没有基于 Time-to-live设置或客户端时间戳的过期行。 该`PAGE SIZE`参数决定了 Amazon Keyspaces 为每个请求从磁盘扫描多少行，而不是 Amazon Keyspaces 返回给客户端的行数。Amazon Keyspaces 会应用您提供的筛选条件，例如非键列上的不等式，或者在扫描磁盘上的数据`LIMIT`之后。如果您未明确设置`PAGE SIZE`，Amazon Keyspaces 会在应用筛选条件之前读取最多 1MB 的数据。例如，如果您在使用时`LIMIT 1`未指定`PAGE SIZE`，Amazon Keyspaces 可能会在应用限制子句之前从磁盘读取数千行并仅返回一行。 为避免过度读取，请减少读取，这样`PAGE SIZE`可以减少 Amazon Keyspaces 每次读取时扫描的行数。例如，如果您在查询`LIMIT 5`中定义，请将设置为介于 5-10 之间的值，这样 Amazon Keyspaces 在每次分页调用时仅扫描 5-10 行。`PAGE SIZE`您可以修改此数字以减少读取次数。对于大于页面大小的限制，Amazon Keyspaces 会按分页状态保留结果总数。如果是 10,000 行，Amazon Keyspaces 可以将这些结果分成两页，每页 5,000 行。`LIMIT`1MB 限制是任何页面大小设置的上限。 # 估算表扫描的读取容量消耗 导致全表扫描的查询（例如使用 `ALLOW FILTERING` 选项的查询）是处理的读取数量多于返回结果的另一种查询示例。读取容量消耗基于读取的数据，而不是返回的数据。 对于表扫描示例，我们在按需容量模式下使用以下示例表。 ``` pk | ck | value ---+----+--------- pk | 10 | pk | 20 | value_1 pk | 30 | ``` 默认情况下，Amazon Keyspaces 会在按需容量模式下创建一个具有四个分区的表。在此示例表中，所有数据都存储在一个分区中，其余三个分区为空。 现在，对表运行以下查询。 ``` SELECT * from amazon_keyspaces.example_table_2; ``` 此查询将生成表扫描操作，其中 Amazon Keyspaces 会扫描表的所有四个分区，并在一致性模式下消耗 6 RRUs 个`LOCAL_QUORUM`分区。首先，Amazon Keyspaces 在读 RRUs 取三行时消耗 3。`pk=‘pk’`然后，Amazon Keyspaces 会额外消耗 3 个 RRUs 用于扫描表的三个空分区。由于此查询会导致表扫描，因此 Amazon Keyspaces 会扫描表中的所有分区，包括没有数据的分区。 # 估算 Amazon Keyspaces 中轻量级事务的容量消耗 轻量级事务（LWT）支持您对表数据执行条件写入操作。根据评估当前状态的条件插入、更新和删除记录时，条件更新操作非常有用。 在 Amazon Keyspaces 中，所有写入操作都需要 LOCAL\$1QUORUM 一致性，使用时不收取额外费用。 LWTs的区别在 LWTs 于，当 LWT 条件检查生效时`FALSE`，Amazon Keyspaces 会消耗写入容量单位 WCUs () 或写入请求单位 ()。WRUs WCUs/WRUs 消耗的数量取决于行的大小。 例如，如果行大小为 2 KB，则失败的条件写入将消耗两个 WCUs/WRUs。如果表中当前不存在该行，则该操作将消耗一个 WCUs/WRUs。 要确定导致条件检查失败的请求数，可以在中监控`ConditionalCheckFailed`指标 CloudWatch。 ## 估算带存活时间 (TTL) 的牌桌的 LWT 成本 LWTs 对于配置了 TTL 但不使用客户端时间戳的表，可能需要额外的读取容量单位 (RCUsRRUs) 或读取请求单位 ()。使用`IF EXISTS`或`IF NOT EXISTS`关键字条件检查结果时`FALSE`，会消耗以下容量单位： + RCUs/RRUs – If the row exists, the RCUs/RRUs消耗量基于现有行的大小。 + RCUs/RRUs – If the row doesn't exist, a single RCU/RRU被消耗掉了。 如果评估的条件导致写入操作成功， WCUs/WRUs 则根据新行的大小进行消费。 # 估算 Amazon Keyspaces 中静态列的容量消耗 在包含聚类列的 Amazon Keyspaces 表中，您可以使用 `STATIC` 关键字来创建静态列。存储在静态列中的值在逻辑分区的所有行之间共享。当您更新此列的值时，Amazon Keyspaces 会自动将更改应用于该分区中的所有行。 本节介绍在写入静态列时如何计算编码数据大小。此过程与将数据写入行中的非静态列的过程是分开处理的。除了静态数据的大小限额外，对静态列的读取和写入操作也会单独影响表的计量和吞吐容量。如需了解使用静态列和分页范围读取结果时 Apache Cassandra 的功能差异，请参阅[分页](functional-differences.md#functional-differences.paging)。 **Topics** + [计算 Amazon Keyspaces 中每个逻辑分区静态列的大小](static-columns-estimate.md) + [估算对 Amazon Keyspaces 中的静态数据进行 read/write 操作所需的容量吞吐量](static-columns-metering.md) # 计算 Amazon Keyspaces 中每个逻辑分区静态列的大小 本节详细介绍如何估算 Amazon Keyspaces 中的编码静态列大小。在计算账单和限额使用量时，应使用编码大小。在计算表的预置吞吐容量需求时，也应使用编码大小。要计算 Amazon Keyspaces 中的编码静态列大小，可以遵循以下准则。 + 分区键最多可包含 2048 个字节的数据。分区键中的每个键列最多需要 3 个字节的元数据。这些元数据字节计入每个分区 1MB 的静态数据大小限额。计算静态数据大小时，应假设每个分区键列使用全部 3 个字节的元数据。 + 根据数据类型使用静态列数据值的原始大小。有关数据类型的更多信息，请参阅 [数据类型](cql.elements.md#cql.data-types)。 + 在元数据的静态数据大小上增加 104 个字节。 + 聚类列和常规非主键列不计入静态数据的大小。要了解如何估算行中的非静态数据大小，请参阅[估算 Amazon Keyspaces 中的行大小](calculating-row-size.md)。 编码静态列的总大小基于以下公式： ``` partition key columns + static columns + metadata = total encoded size of static data ``` 考虑以下表示例，其中所有列均为整数类型。此表包含两个分区键列、两个聚类列、一个常规列和一个静态列。 ``` CREATE TABLE mykeyspace.mytable(pk_col1 int, pk_col2 int, ck_col1 int, ck_col2 int, reg_col1 int, static_col1 int static, primary key((pk_col1, pk_col2),ck_col1, ck_col2)); ``` 在此示例中，我们计算以下语句的静态数据大小： ``` INSERT INTO mykeyspace.mytable (pk_col1, pk_col2, static_col1) values(1,2,6); ``` 要估算此写入操作所需的总字节数，可以按照以下步骤操作。 1. 通过将存储在一个分区键列中的数据类型的字节和元数据字节相加，计算该列的大小。针对所有分区键列重复此操作。 1. 计算分区键第一列 (pk\$1col1) 的大小： ``` 4 bytes for the integer data type + 3 bytes for partition key metadata = 7 bytes ``` 1. 计算分区键第二列 (pk\$1col2) 的大小： ``` 4 bytes for the integer data type + 3 bytes for partition key metadata = 7 bytes ``` 1. 将两列相加，得出分区键列的估算总大小： ``` 7 bytes + 7 bytes = 14 bytes for the partition key columns ``` 1. 加上静态列的大小。在此示例中，我们只有一个静态列用于存储一个整数（需要 4 个字节）。 1. 最后，要得出编码静态列数据的总大小，请将主键列和静态列的字节相加，再加上元数据所需的 104 个字节： ``` 14 bytes for the partition key columns + 4 bytes for the static column + 104 bytes for metadata = 122 bytes. ``` 您也可以使用相同的语句更新静态数据和非静态数据。要估算写入操作的总大小，必须先计算非静态数据更新的大小。然后计算行更新的大小（如[估算 Amazon Keyspaces 中的行大小](calculating-row-size.md)中的示例所示），并将结果相加。 在此示例中，您总共可以写入 2MB，1MB 是最大行大小限额，1MB 是每个逻辑分区的最大静态数据大小限额。 要计算同一语句中静态数据和非静态数据更新的总大小，可以使用以下公式： ``` (partition key columns + static columns + metadata = total encoded size of static data) + (partition key columns + clustering columns + regular columns + row metadata = total encoded size of row) = total encoded size of data written ``` 考虑以下表示例，其中所有列均为整数类型。此表包含两个分区键列、两个聚类列、一个常规列和一个静态列。 ``` CREATE TABLE mykeyspace.mytable(pk_col1 int, pk_col2 int, ck_col1 int, ck_col2 int, reg_col1 int, static_col1 int static, primary key((pk_col1, pk_col2),ck_col1, ck_col2)); ``` 在此示例中，我们在向表中写入一行时计算数据的大小，如以下语句所示： ``` INSERT INTO mykeyspace.mytable (pk_col1, pk_col2, ck_col1, ck_col2, reg_col1, static_col1) values(2,3,4,5,6,7); ``` 要估算此写入操作所需的总字节数，可以按照以下步骤操作。 1. 按照之前的步骤计算编码静态数据的总大小。在此示例中，它是 122 个字节。 1. 按照[估算 Amazon Keyspaces 中的行大小](calculating-row-size.md)中的步骤，根据非静态数据的更新，加上编码行总大小。在此示例中，行更新的总大小为 134 个字节。 ``` 122 bytes for static data + 134 bytes for nonstatic data = 256 bytes. ``` # 估算对 Amazon Keyspaces 中的静态数据进行 read/write 操作所需的容量吞吐量 静态数据与 Cassandra 中的逻辑分区相关联，而不是与单个行相关联。Amazon Keyspaces 中的逻辑分区跨越多个物理存储分区，实际上可以不受大小限制。因此，Amazon Keyspaces 分别计量静态数据和非静态数据的写入操作。此外，同时包含静态数据和非静态数据的写入操作需要额外的底层操作来提供数据一致性。 如果您执行包含静态数据和非静态数据的混合写入操作，则会产生两个不同的写入操作，一个用于非静态数据，另一个用于静态数据。这适用于按需和预配置 read/write 容量模式。 以下示例详细介绍了在计算 Amazon Keyspaces 中具有静态列的表的预配置吞吐量需求时，如何估算所需的读取容量单位 (RCUsWCUs) 和写入容量单位 ()。您可以使用以下公式估算表处理同时包含静态数据和非静态数据的写入操作所需的容量： ``` 2 x WCUs required for nonstatic data + 2 x WCUs required for static data ``` 例如，如果您的应用程序每秒写入 27 KBs 个数据，并且每次写入包括 25.5 个 KBs 非静态数据和 1. KBs 5 个静态数据，则您的表需要 56 WCUs （2 x 26 WCUs \$1 2 x 2 WCUs）。 Amazon Keyspaces 计量静态数据和非静态数据的读取方式与计量多行读取的方式相同。因此，在同一操作中读取静态数据和非静态数据的价格取决于为执行读取而处理的数据的总大小。 要了解如何使用 Amazon 监控无服务器资源 CloudWatch，请参阅[使用亚马逊监控亚马逊密钥空间 CloudWatch](monitoring-cloudwatch.md)。 # 在 Amazon Keyspaces 中为多区域表估算和预置容量 您可以通过以下两种方式之一配置多区域表的吞吐能力： + 按需容量模式，以写入请求单位衡量 (WRUs) + 带有 auto Scaling 功能的预置容量模式，以写入容量单位衡量 () WCUs 您可以将预置容量模式与 auto scaling 或按需容量模式配合使用，以帮助确保多区域表具有足够的容量来执行对所有表的复制写入。 AWS 区域 **注意** 在其中一个区域中更改表的容量模式会更改所有副本的容量模式。 默认情况下，Amazon Keyspaces 对多区域表使用按需模式。对于按需模式，您无需指定预期应用程序执行的读写吞吐量。Amazon Keyspaces 会随着工作负载的增加或减少，根据之前达到的任意流量水平即时调节工作负载。如果某个工作负载的流量级别达到一个新的峰值，Amazon Keyspaces 将快速调整以适应该工作负载。 如果您为表选择预置容量模式，则必须配置应用程序所需的每秒读取容量单位 (RCUs) 和写入容量单位 (WCUs) 的数量。 要规划多区域表的吞吐容量需求，应首先估计每个区域 WCUs 每秒所需的吞吐量容量。之后，将复制了表的所有区域的写入容量相加，然后使用该总和为每个区域预置容量。这是必需的操作，因为在一个区域中执行的每一次写入也必须在每个副本区域中重复执行。 如果表没有足够的容量来处理所有区域的写入操作，则会出现容量异常。此外，区域间的复制等待时间也将增加。 例如，如果您有一个多区域表，预计美国东部（弗吉尼亚北部）每秒 5 次写入，美国东部（俄亥俄州）每秒 10 次写入，欧洲（爱尔兰）每秒 5 次写入，则应预计该表在每个区域 WCUs 中消耗 20 次写入：美国东部（弗吉尼亚北部）、美国东部（俄亥俄州）和欧洲（爱尔兰）。这意味着在本示例中，您需要 WCUs 为表的每个副本预置 20。您可以使用 Amazon 监控表的容量消耗 CloudWatch。有关更多信息，请参阅 [使用亚马逊监控亚马逊密钥空间 CloudWatch](monitoring-cloudwatch.md)。 每次写入均按 1 个 WCU 计费，因此在本示例中，您会看到总共计有 60 个 WCU WCUs 计费。有关定价的更多信息，请参阅 [Amazon Keyspaces（Apache Cassandra 兼容）定价](https://aws.amazon.com/keyspaces/pricing)。 有关使用 Amazon Keyspaces 自动扩缩预置容量的更多信息，请参阅[使用 Amazon Keyspaces 自动扩缩自动管理吞吐能力](autoscaling.md)。 **注意** 如果表在具有自动扩缩功能的预置容量模式下运行，则允许预置的写入容量在每个区域的这些自动扩缩设置中浮动。 # 估算亚马逊 CloudWatch 在 Amazon Keyspaces 中的读取和写入容量消耗 要估算和监控读取和写入容量消耗，您可以使用 CloudWatch 控制面板。有关 Amazon Keyspaces 的可用指标的更多信息，请参阅[Amazon Keyspaces 指标与维度](metrics-dimensions.md)。 要监控特定语句使用的读取和写入容量单位 CloudWatch，可以按照以下步骤操作。 1. 创建一个包含样本数据的新表 1. 为表格配置 Amazon Keyspaces CloudWatch 控制面板。首先，您可以使用 [Github](https://github.com/aws-samples/amazon-keyspaces-cloudwatch-cloudformation-templates) 上提供的控制面板模板。 1. 运行 CQL 语句，例如使用 `ALLOW FILTERING` 选项，然后在控制面板中检查全表扫描所消耗的读取容量单位。