从 Apache Cassandra 迁移数据的指南

从下载兼容的 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 集群中每个表的行大小指标。该脚本使用 Apache Cassandra 导出表数据，cqlsh并awk计算一组可配置的表格数据样本中行大小的最小值、最大值、平均值和标准差。行大小采样器将参数传递给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 计费。Amazon Keyspaces 表大小基于单个副本的原始大小（未压缩）。要监控 Amazon Keyspaces 中的表格大小，您可以使用该指标BillableTableSizeInBytes，该指标显示在中每个表中。 Amazon Web Services Management Console

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

• 使用平均行大小，然后乘以一个或多个行数。

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

• 使用收集表元数据。nodetool

  Nodetool是 Apache Cassandra 发行版中提供的管理工具，可让您深入了解 Cassandra 流程的状态并返回表元数据。您可以使用nodetool对有关表大小的元数据进行采样，并借此推断 Amazon Keyspaces 中的表格大小。要使用的命令是nodetool tablestats。Tablestats 返回表格的大小和压缩比。表格的大小存储tablelivespace为表格的大小，您可以将其除以compression ratio。然后将此大小值乘以节点数。最后除以重复因子（通常为三个）。这是可用于评估表格大小的完整计算公式。

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

  假设你的 Cassandra 集群有 12 个节点。运行该nodetool tablestats命令会返回 200 GB 的 a 和 0.5 compression ratio 的 a。tablelivespace密钥空间的重复因子为三。这就是此示例的计算方式。

  (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 中读/写吞吐量的价格取决于请求的数量和大小。Amazon Keyspaces 中有两种容量模式：按需和预配置容量模式。按需容量模式是一种灵活的计费选项，能够每秒处理数千个请求，而无需进行容量规划。此选项为读取和写入请求提供 pay-per-request 定价，因此您只需为实际用量付费。如果您选择预置的吞吐容量 模式，则指定您的应用程序需要的每秒读取和写入次数。这有助于您管理 Amazon Keyspaces 使用量，使其保持在或低于定义的请求速率以优化价格并保持可预测性。Provisioned 模式提供 a uto Scaling 功能，可自动调整您的预配置速率以向上或向下扩展，从而提高运营效率。有关无服务器资源管理的更多信息，请参阅Amazon Keyspaces（Apache Cassandra 兼容）中的无服务器资源管理。

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

要从现有 Cassandra 集群中收集最准确的利用率指标，请捕获在单个数据中心所有节点上聚合的表在很长一段时间内协调员级读取和写入操作的平均每秒请求数 (RPS)。捕获至少几周内的平均 RPS 将捕捉流量模式中的高峰和低谷，如下图所示。

您可以通过两个选项来确定 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返回 2419,200 秒的正常运行时间，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 表示对大小不超过 4 KB 的行的一个LOCAL_ONE读取请求或两个读取请求。LOCAL_QUORUM如果您需要读取大于 4 KB 的行，则读取操作将使用额外的 RCU。所需的 RCU 总数取决于行大小以及您想要使用一致性LOCAL_QUORUM还是LOCAL_ONE读取一致性。例如，读取 8 KB 的行需要 2 个 RCU 使用LOCAL_QUORUM读取一致性，如果您选择LOCAL_ONE读取一致性，则需要 1 个 RCU。

一个 WCU 表示对大小不超过 1 KB 的行进行一次写入。所有写入操作都使用 LOCAL_QUORUM 一致性，使用轻量级事务 (LWT) 不收取额外费用。如果您需要写入大于 1 KB 的行，则写入操作将使用额外的 WCU。所需 WCU 的总数取决于行大小。例如，如果您的行大小为 2 KB，则需要 2 个 WCU 才能执行一个写入请求。

以下公式可用于估算所需的 RCU 和 WCU。RCU 中的读取容量可以通过将每秒读取次数乘以每次读取的行数乘以平均行大小除以 4KB 并向上舍入到最接近的整数来确定。

WCU 中的写入容量可以通过将请求数乘以平均行大小除以 1KB 并向上舍入到最接近的整数来确定。这用以下公式表示。

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

例如，如果您要在 Cassandra 表上执行 4,960 个行大小为 2.5KB 的读取请求，则在 Amazon Keyspaces 中需要 4,960 个 RCU。如果你目前在 Cassandra 表上每秒执行 1,653 个写入请求，行大小为 2.5KB，那么在 Amazon Keyspaces 中，你需要每秒 4,959 个 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 的月度估算价格

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

预配置模式-读取和写入容量消耗按小时费率计费，基于每秒容量单位数。首先，将该比率除以 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

按需模式-读取和写入容量按请求费率计费。首先，将请求速率乘以 30 个日历日和每天 24 小时。然后除以一百万个请求单位。最后，乘以区域汇率。以下公式汇总了此计算。

((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