创建从 Apache Cassandra 迁移到 Amazon Keyspaces 的迁移计划

从下载兼容的 Python 脚本GitHub并将其移动到可以访问现有 Apache Cassandra 集群的位置。

兼容性脚本使用的参数与 CQLSH 类似。对于 --host 和 --port，输入用于连接集群中的一个 Cassandra 节点并对该节点运行查询的 IP 地址和端口。

如果您的 Cassandra 集群使用身份验证，则还需要提供 -username 和 -password。要运行兼容性脚本，您可以使用以下命令。

python toolkit-compat-tool.py --host hostname or IP -u "username" -p "password" --port native transport port

确定行大小

行大小对于确定 Amazon Keyspaces 中的读取容量和写入容量利用率非常重要。下图显示了 Cassandra 令牌范围内的典型数据分布。

您可以使用上提供的行大小采样器脚本GitHub来收集 Cassandra 集群中每个表的行大小指标。

该脚本使用 cqlsh 和 awk 从 Apache Cassandra 导出表数据，来基于一组可配置的表数据样本计算行大小的最小值、最大值、平均值以及标准差。行大小采样器将参数传递给 cqlsh，因此可以使用相同的参数来连接 Cassandra 集群并从中读取数据。

下面是一个示例语句。

./row-size-sampler.sh 10.22.33.44 9142 \\
   -u "username" -p "password" --ssl

有关如何在 Amazon Keyspaces 中计算行大小的更多信息，请参阅估算 Amazon Keyspaces 中的行大小。

确定表大小

使用 Amazon Keyspaces，您无需提前预置存储空间。Amazon Keyspaces 会持续监控表的可计费大小，以确定存储费用。存储按每人计费。 GB-monthAmazon Keyspaces 表大小基于单个副本的原始大小（未压缩）。

要监控 Amazon Keyspaces 中的表大小，您可以使用指标 BillableTableSizeInBytes， AWS 管理控制台中的每个表都有该指标。

要估算 Amazon Keyspaces 表的可计费大小，您可以使用以下两种方法之一：

• 使用平均行大小，然后乘以行数。

  您可以通过将平均行大小乘以 Cassandra 源表中的行数来估算 Amazon Keyspaces 表的大小。使用上一节中的行大小示例脚本来捕获平均行大小。要捕获行数，您可以使用诸如 dsbulk count 这样的工具来确定源表中的总行数。

• 使用 nodetool 收集表元数据。

  Nodetool 是 Apache Cassandra 发行版中提供的管理工具，可让您深入了解 Cassandra 进程的状态并返回表元数据。您可以使用 nodetool 对有关表大小的元数据进行采样，并借此推断 Amazon Keyspaces 中的表大小。

  要使用的命令是 nodetool tablestats。Tablestats 会返回表的大小和压缩比例。表的大小存储为表的 tablelivespace，您可以将其除以 compression ratio。然后将此大小值乘以节点数。最后除以复制因子（通常为 3）。

  这是可用于评估表大小的完整计算公式。

  ((tablelivespace / compression ratio) * (total number of nodes))/ (replication factor)

  假设你的 Cassandra 集群有 12 个节点。运行 nodetool tablestats 命令会返回 200GB 的 tablelivespace 和 0.5 的 compression ratio。键空间的复制因子为 3。

  这就是此示例的计算方式。

  (200 GB / 0.5) * (12 nodes)/ (replication factor of 3)
                          = 4,800 GB / 3
                          = 1,600 GB is the table size estimate for Amazon Keyspaces

捕获读取和写入数

要确定 Amazon Keyspaces 表的容量和扩缩要求，请在迁移之前获取 Cassandra 表的读取和写入请求速率。

Amazon Keyspaces 采用无服务器模式，您只需按实际使用量付费。通常，Amazon Keyspaces 的 read/write 吞吐量价格取决于请求的数量和大小。

Amazon Keyspaces 中有两种容量模式：

由于您分别在 Amazon Keyspaces 中预置读取和写入吞吐能力，因此您需要单独衡量现有表中的读取和写入请求速率。

要从现有 Cassandra 集群中收集最准确的利用率指标，请针对在单个数据中心中所有节点上聚合的表，捕获较长一段时间内协调器级读取和写入操作的平均每秒请求数（RPS）。

捕获至少几周内的平均 RPS 可以捕捉流量模式中的峰值和低谷，如下图所示。

您可以通过两个选项来确定 Cassandra 表的读取和写入请求速率。

• 使用现有的 Cassandra 监控

  您可以使用下表所示的指标来观察读/写请求。请注意，指标名称可能会因您使用的监控工具而有所差异。

  维度	Cassandra JMX 指标
  读取	org.apache.cassandra.metrics:type=ClientRequest, scope=Write,name=Latency#Count
  写入	org.apache.cassandra.metrics:type=ClientRequest, scope=Read,name=Latency#Count

• 使用 nodetool

  使用 nodetool tablestats 和 nodetool info 捕获表中的平均读取和写入操作数。tablestats 会返回自节点启动之日起的读取和写入总数。nodetool info 则会提供节点的正常运行时间（以秒为单位）。

  要获得每秒平均读取和写入数，请将读取和写入数量除以节点的正常运行时间（以秒为单位）。然后，对于读取，您可以除以一致性级别，而对于写入，则除以复制因子。这些计算用以下公式表示。

  每秒平均读取数的公式：

  ((number of reads * number of nodes in cluster) / read consistency quorum (2)) / uptime

  每秒平均写入数的公式：

  ((number of writes * number of nodes in cluster) / replication factor of 3) / uptime

  假设我们有一个 12 个节点的集群已经运行了 4 周。nodetool info 会返回 2419200 秒的正常运行时间，nodetool tablestats 会返回 10 亿写入数量和 20 亿读取数量。此示例将得出以下计算。

  ((2 billion reads * 12 in cluster) / read consistency quorum (2)) / 2,419,200 seconds
  =  12 billion reads / 2,419,200 seconds
  =  4,960 read request per second
                          ((1 billion writes * 12 in cluster) / replication factor of 3) / 2,419,200 seconds
  =  4 billion writes / 2,419,200 seconds
  =  1,653 write request per second

确定表的容量利用率

要估算平均容量利用率，请从平均请求速率以及 Cassandra 源表的平均行大小开始。

Amazon Keyspaces 使用读取容量单位数（RCU）和写入容量单位数（WCU）来衡量表读取和写入的预置吞吐能力。在此估算中，我们使用这些单位来计算迁移后新 Amazon Keyspaces 表的读取和写入容量需求。

在本主题的后面部分，我们将讨论在预置容量模式和按需容量模式之间的选择会对计费会有怎样的影响。但是在此示例中，为了估算容量利用率，我们假设该表处于预置模式下。

以下公式可用于估算所需的 RCU 和 WCU。

该示例通过以下公式表示。

Read requests per second * ROUNDUP((Average Row Size)/4096 per unit) =  RCUs per second
                
Write requests per second * ROUNDUP(Average Row Size/1024 per unit) = WCUs per second

例如，在 Amazon Keyspaces 中，如果您要在 Cassandra 表上执行 4960 个读取请求（行大小为 2.5 KB），则需要 4960 个 RCU。在 Amazon Keyspaces 中，如果您目前对 Cassandra 表每秒执行 1653 个写入请求（行大小为 2.5 KB），则每秒需要 4959 个 WCU。

此示例用以下公式表示。

4,960 read requests per second * ROUNDUP( 2.5KB /4KB bytes per unit)
= 4,960 read requests per second * 1 RCU
= 4,960 RCUs
                
1,653 write requests per second * ROUNDUP(2.5KB/1KB per unit) 
= 1,653 requests per second * 3 WCUs
= 4,959 WCUs

使用 eventual consistency，您每个读取请求可以节省多达一半的吞吐能力。每次最终一致性读取最多可消耗 8KB。您可以通过将先前的计算结果乘以 0.5 来计算最终一致性读取数，如以下公式所示。

4,960 read requests per second * ROUNDUP( 2.5KB /4KB per unit) * .5 
= 2,480 read request per second * 1 RCU
= 2,480 RCUs

计算 Amazon Keyspaces 的每月价格估算

要根据 read/write 容量吞吐量估算表的每月账单，您可以使用不同的公式计算按需模式和预置模式的定价，并比较表的选项。

预置模式 - 读取和写入容量消耗按小时费率计费，基于每秒的容量单位数。首先，将该费率除以 0.7，表示默认的自动扩缩目标利用率为 70%。然后乘以 30 个日历日、每天 24 小时以及区域费率定价。

此计算总结为以下公式。

(read capacity per second / .7) * 24 hours * 30 days * regional rate
                (write capacity per second / .7) * 24 hours * 30 days * regional rate

On-demand 模式 — 读取和写入容量按每个请求的费率计费。首先，将请求费率乘以 30 个日历日以及每天 24 小时。然后除以 100 万个请求单位。最后，乘以区域费率。

此计算总结为以下公式。

((read capacity per second * 30 * 24 * 60 * 60) / 1 Million read request units) * regional rate
                ((write capacity per second * 30 * 24 * 60 * 60) / 1 Million write request units) * regional rate