使用 Amazon Keyspaces 中的表 - Amazon Keyspaces(Apache Cassandra 兼容)
Amazon Web Services 文档中描述的 Amazon Web Services 服务或功能可能因区域而异。要查看适用于中国区域的差异,请参阅 中国的 Amazon Web Services 服务入门 (PDF)

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

使用 Amazon Keyspaces 中的表

本节详细介绍如何使用 Amazon Keyspaces(Apache Cassandra 兼容)中的表。

在 Amazon Keyspaces 中创建表

Amazon Keyspaces 以异步方式执行数据定义语言 (DDL) 操作,例如创建和删除表。您可以在中监控新表的创建状态 Amazon Web Services Management Console,该状态会指示表何时处于待处理状态或活动状态。您还可以使用系统模式表以编程方式监控新表的创建状态。

当表可供使用时,会在系统模式中显示为活动状态。要检查新的表何时可供使用,推荐的设计模式是轮询 Amazon Keyspaces 系统架构表 (system_schema_mcs.*)。有关表的 DDL 语句列表,请参阅 CQL 语言参考中的部分。

以下查询显示表的状态。

SELECT keyspace_name, table_name, status FROM system_schema_mcs.tables WHERE keyspace_name = 'mykeyspace' AND table_name = 'mytable';

对于仍在创建且处于待处理状态的表,此查询的输出如下所示。

keyspace_name | table_name | status --------------+------------+-------- mykeyspace | mytable | CREATING

对于已成功创建且处于活动状态的表,此查询的输出如下所示。

keyspace_name | table_name | status --------------+------------+-------- mykeyspace | mytable | ACTIVE

使用 Amazon Keyspaces 中的多区域表

多区域表必须通过以下两种方式之一配置写入吞吐量容量:

  • 按需容量模式,以写入请求单位 (WRU) 衡量

  • 带有 auto Scaling 功能的预置容量模式,以写入容量单位 (WCU) 衡量

您可以将预置容量模式与 auto scaling 或按需容量模式配合使用,以帮助确保多区域表具有足够的容量来执行对所有表的复制写入。 Amazon Web Services 区域

注意

在其中一个区域中更改表的容量模式会更改所有副本的容量模式。

默认情况下,Amazon Keyspaces 对多区域表使用按需模式。在按需模式下,您无需指定您期望应用程序执行的读取和写入吞吐量。Amazon Keyspaces 可在您的工作负载上升或下降到之前达到的任何流量水平时立即适应您的工作负载。如果工作负载的流量水平达到新的峰值,Amazon Keyspaces 会迅速调整以适应工作负载。

如果您为表选择预置容量模式,则必须配置应用程序所需的每秒读取容量单位 (RCU) 和写入容量单位 (WCU) 的数量。

要规划多区域表的吞吐容量需求,应首先估计每个区域每秒所需的 WCU 数量。然后,将表复制到的所有区域的写入数据相加,然后使用该总和为每个区域配置容量。这是必需的,因为在一个区域中执行的每一次写入也必须在每个副本区域中重复。

如果该表没有足够的容量来处理来自所有区域的写入,则会出现容量异常。此外,区域间复制的等待时间将会增加。

例如,如果您有一个多区域表,预计美国东部(弗吉尼亚北部)每秒 5 次写入,美国东部(俄亥俄州)每秒 10 次写入,欧洲(爱尔兰)每秒 5 次写入,则应预计该表在每个区域消耗 20 个 WCU:美国东部(弗吉尼亚北部)、美国东部(俄亥俄州)和欧洲(爱尔兰)。这意味着在本示例中,您需要为表的每个副本预配置 20 个 WCU。您可以使用 Amazon 监控表的容量消耗 CloudWatch。有关更多信息,请参阅使用亚马逊监控亚马逊密钥空间 CloudWatch

由于每次多区域写入按照 WCU 的 1.25 倍计费,因此在本示例中,您总共会看到 75 个 WCU 计费。有关定价的更多信息,请参阅 Amazon Keyspaces(Apache Cassandra 兼容)定价

有关使用 Amazon Keyspaces 自动扩展使用 Amazon Keyspaces 自动扩展功能自动管理吞吐容量的预配置容量的更多信息,请参阅。

注意

如果表在带有 auto Scaling 的预配置容量模式下运行,则允许每个区域的预配置写入容量在这些自动扩展设置内浮动。

Amazon Keyspaces 中的静态列

在包含聚类列的 Amazon Keyspaces 表中,您可以使用 STATIC 关键字来创建静态列。存储在静态列中的值在逻辑分区的所有行之间共享。当您更新此列的值时,Amazon Keyspaces 会自动将更改应用于该分区中的所有行。

本节介绍在写入静态列时如何计算编码数据大小。此过程与将数据写入行中的非静态列的过程是分开处理的。除了静态数据的大小限额外,对静态列的读取和写入操作也会单独影响表的计量和吞吐容量。

计算 Amazon Keyspaces 中每个逻辑分区的静态列大小

本节详细介绍如何估算 Amazon Keyspaces 中的编码静态列大小。在计算账单和限额使用量时,应使用编码大小。在计算表的预置吞吐容量需求时,也应使用编码大小。要计算 Amazon Keyspaces 中的编码静态列大小,可以遵循以下准则。

  • 分区键最多可包含 2048 个字节的数据。分区键中的每个键列最多需要 3 个字节的元数据。这些元数据字节计入每个分区 1MB 的静态数据大小限额。计算静态数据大小时,应假设每个分区键列使用全部 3 个字节的元数据。

  • 根据数据类型使用静态列数据值的原始大小。有关数据类型的更多信息,请参阅 数据类型

  • 在元数据的静态数据大小上增加 104 个字节。

  • 聚类列和常规非主键列不计入静态数据的大小。要了解如何估算行中的非静态数据大小,请参阅计算 Amazon Keyspaces 中的行大小

编码静态列的总大小基于以下公式:

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_col1) 的大小:

      4 bytes for the integer data type + 3 bytes for partition key metadata = 7 bytes
    2. 计算分区键第二列 (pk_col2) 的大小:

      4 bytes for the integer data type + 3 bytes for partition key metadata = 7 bytes
    3. 将两列相加,得出分区键列的估算总大小:

      7 bytes + 7 bytes = 14 bytes for the partition key columns
  2. 加上静态列的大小。在此示例中,我们只有一个静态列用于存储一个整数(需要 4 个字节)。

  3. 最后,要得出编码静态列数据的总大小,请将主键列和静态列的字节相加,再加上元数据所需的 104 个字节:

    14 bytes for the partition key columns + 4 bytes for the static column + 104 bytes for metadata = 122 bytes.

您也可以使用相同的语句更新静态数据和非静态数据。要估算写入操作的总大小,必须先计算非静态数据更新的大小。然后计算行更新的大小(如计算 Amazon Keyspaces 中的行大小中的示例所示),并将结果相加。

在此示例中,您总共可以写入 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 个字节。

  2. 按照计算 Amazon Keyspaces 中的行大小中的步骤,根据非静态数据的更新,加上编码行总大小。在此示例中,行更新的总大小为 134 个字节。

    122 bytes for static data + 134 bytes for nonstatic data = 256 bytes.

计量 Amazon Keyspaces 中的静态数据的读取/写入操作

静态数据与 Cassandra 中的逻辑分区相关联,而不是与单个行相关联。Amazon Keyspaces 中的逻辑分区跨越多个物理存储分区,实际上可以不受大小限制。因此,Amazon Keyspaces 分别计量静态数据和非静态数据的写入操作。此外,同时包含静态数据和非静态数据的写入操作需要额外的底层操作来提供数据一致性。

如果您执行包含静态数据和非静态数据的混合写入操作,则会产生两个不同的写入操作,一个用于非静态数据,另一个用于静态数据。这适用于按需和预置读取/写入容量模式。

以下示例详细介绍了在计算 Amazon Keyspaces 中包含静态列的表的预置吞吐容量需求时,如何估算所需的读取容量单位 (RCU) 和写入容量单位 (WCU)。您可以使用以下公式估算表处理同时包含静态数据和非静态数据的写入操作所需的容量:

2 x WCUs required for nonstatic data + 2 x WCUs required for static data

例如,如果您的应用程序每秒写入 27KB 的数据,并且每次写入包括 25.5KB 的非静态数据和 1.5KB 的静态数据,则您的表需要 56 个 WCU(2 x 26 个 WCU + 2 x 2 个 WCU)。

Amazon Keyspaces 计量静态数据和非静态数据的读取方式与计量多行读取的方式相同。因此,在同一操作中读取静态数据和非静态数据的价格取决于为执行读取而处理的数据的总大小。

要了解如何使用 Amazon 监控无服务器资源 CloudWatch,请参阅使用亚马逊监控亚马逊密钥空间 CloudWatch