本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 创建从 Apache Cassandra 迁移到 Amazon Keyspaces 的迁移计划 为了成功地从 Apache Cassandra 迁移到 Amazon Keyspaces，建议您查看适用的迁移概念和最佳实践，并比较可用选项。 本主题通过介绍几个关键概念以及可供您使用的工具和技术，来概括介绍迁移过程的工作原理。您可以评估不同的迁移策略，选择最能满足您需求的策略。 **Topics** + [功能兼容性](#migrating-cassandra-compatibility) + [估算 Amazon Keyspaces 定价](#migrating-cassandra-sizing) + [选择迁移策略](#migrating-cassandra-strategy) + [在线迁移到 Amazon Keyspaces：策略和最佳实践](migrating-online.md) + [离线迁移过程：Apache Cassandra 到 Amazon Keyspaces](migrating-offline.md) + [使用混合迁移解决方案：Apache Cassandra 到 Amazon Keyspaces](migrating-hybrid.md) ## 功能兼容性 在迁移之前，请仔细考虑 Apache Cassandra 和 Amazon Keyspaces 之间的功能差异。Amazon Keyspaces 支持所有常用的 Cassandra 数据面板操作，例如创建键空间和表、读取数据和写入数据。 但是，有些 Cassandra API 是 Amazon Keyspaces 不支持的。有关支持的 API 的更多信息，请参阅[支持的 Cassandra API、操作、函数和数据类型](cassandra-apis.md)。有关 Apache Keyspaces 与 Apache Cassandra 之间所有功能差异的概述，请参阅[功能差异：Amazon Keyspaces 与 Apache Cassandra](functional-differences.md)。 要将您正在使用的 Cassandra API 和架构与亚马逊密钥空间中支持的功能进行比较，您可以运行亚马逊密钥空间工具包中提供的兼容性脚本。[GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/toolkit-compat-tool.py) **如何使用兼容性脚本** 1. 从下载兼容的 Python 脚本[GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/toolkit-compat-tool.py)并将其移动到可以访问现有 Apache Cassandra 集群的位置。 1. 兼容性脚本使用的参数与 `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 定价 本节概述了您需要从 Apache Cassandra 表中收集哪些信息来计算 Amazon Keyspaces 的估算成本。您的每个表都需要不同的数据类型，需要支持不同的 CQL 查询并保持独特的 read/write 流量。 [根据表格考虑您的需求与 Amazon Keyspaces 表级资源隔离read/write 和吞吐容量模式保持一致。](ReadWriteCapacityMode.md)借助 Amazon Keyspaces，您可以单独为表定义 read/write容量和[自动扩展策略](autoscaling.md)。 了解表的要求有助于您根据功能、成本和迁移工作量确定要迁移的表的优先级。 在迁移之前，请收集以下 Cassandra 表指标。这些信息有助于估算您在 Amazon Keyspaces 上的工作负载的成本。 + **表名** - 完全限定键空间的名称和表名。 + **描述** - 对表的描述，例如表的使用方式或其中存储的数据类型。 + **每秒平均读取数** - 在较长时间间隔内对表进行的协调器级平均读取数。 + **每秒平均写入数** - 在较长时间间隔内对表进行的协调器级平均写入数。 + **平均行大小（以字节为单位）**- 以字节为单位的平均行大小。 + **存储大小（以 GB 为单位）**- 表的原始存储大小。 + **读取一致性明细** - 使用最终一致性（`LOCAL_ONE` 或 `ONE`）与强一致性（`LOCAL_QUORUM`）的读取百分比。 下表显示了计划迁移时需要汇总的表信息的示例。 **** | 表名 | 说明 | 每秒平均读取数 | 每秒平均写入数 | 平均行大小（字节） | 存储大小（GB） | 读取一致性细分 | | --- | --- | --- | --- | --- | --- | --- | | mykeyspace.mytable | 用于存储购物车历史记录 | 10000 | 5000 | 2,200 | 2000 | 100% `LOCAL_ONE` | | mykeyspace.mytable2 | 用于存储最新个人资料信息 | 20000 | 1000 | 850 | 1000 | 25% `LOCAL_QUORUM` 75% `LOCAL_ONE` | ### 如何收集表指标 本节提供了有关如何从现有 Cassandra 集群中收集必要的表指标的分步说明。这些指标包括行大小、表大小和每秒 read/write 请求数 (RPS)。通过这些信息，您可以评估 Amazon Keyspaces 表的吞吐能力要求并估算定价。 **如何在 Cassandra 源表上收集表指标** 1. 确定行大小 行大小对于确定 Amazon Keyspaces 中的读取容量和写入容量利用率非常重要。下图显示了 Cassandra 令牌范围内的典型数据分布。 ![使用 murmur3 分区程序显示 Cassandra 令牌范围内典型数据分布的示意图。](http://docs.amazonaws.cn/keyspaces/latest/devguide/images/migration/migration-data-distribution.png) 您可以使用上提供的行大小采样器脚本[GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/row-size-sampler.sh)来收集 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 中的行大小](calculating-row-size.md)。 1. 确定表大小 使用 Amazon Keyspaces，您无需提前预置存储空间。Amazon Keyspaces 会持续监控表的可计费大小，以确定存储费用。存储按每人计费。 GB-monthAmazon Keyspaces 表大小基于单个副本的原始大小（未压缩）。 要监控 Amazon Keyspaces 中的表大小，您可以使用指标 `BillableTableSizeInBytes`， Amazon Web Services 管理控制台中的每个表都有该指标。 要估算 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 ``` 1. 捕获读取和写入数 要确定 Amazon Keyspaces 表的容量和扩缩要求，请在迁移之前获取 Cassandra 表的读取和写入请求速率。 Amazon Keyspaces 采用无服务器模式，您只需按实际使用量付费。通常，Amazon Keyspaces 的 read/write 吞吐量价格取决于请求的数量和大小。 Amazon Keyspaces 中有两种容量模式： + [On-demand](ReadWriteCapacityMode.OnDemand.md)— 这是一种灵活的计费选项，能够每秒处理数千个请求，而无需进行容量规划。它针对读写请求提供按请求支付定价，以便您只需为使用的资源付费。 + [预置](ReadWriteCapacityMode.Provisioned.md) – 如果您选择预置吞吐能力模式，则指定您的应用程序需要的每秒读取和写入数。这可以帮助您管理 Amazon Keyspaces 的使用情况，使其保持在或低于定义的请求速率，从而保持可预测性。 预置模式提供[自动扩缩](autoscaling.md)功能，可自动调整您的预置速率来进行纵向扩展或缩减，从而提高运营效率。有关管理无服务器资源的更多信息，请参阅[在 Amazon Keyspaces（Apache Cassandra 兼容）中管理无服务器资源](serverless_resource_management.md)。 由于您分别在 Amazon Keyspaces 中预置读取和写入吞吐能力，因此您需要单独衡量现有表中的读取和写入请求速率。 要从现有 Cassandra 集群中收集最准确的利用率指标，请针对在单个数据中心中所有节点上聚合的表，捕获较长一段时间内协调器级读取和写入操作的平均每秒请求数（RPS）。 捕获至少几周内的平均 RPS 可以捕捉流量模式中的峰值和低谷，如下图所示。 ![显示两周内每天平均每秒请求速率的示意图。](http://docs.amazonaws.cn/keyspaces/latest/devguide/images/migration/migration-rps.png) 您可以通过两个选项来确定 Cassandra 表的读取和写入请求速率。 + 使用现有的 Cassandra 监控 您可以使用下表所示的指标来观察读/写请求。请注意，指标名称可能会因您使用的监控工具而有所差异。 **** [See the AWS documentation website for more details](http://docs.amazonaws.cn/keyspaces/latest/devguide/migrating-cassandra.html) + 使用 `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 ``` 1. 确定表的容量利用率 要估算平均容量利用率，请从平均请求速率以及 Cassandra 源表的平均行大小开始。 Amazon Keyspaces 使用*读取容量单位数*（RCU）和*写入容量单位数*（WCU）来衡量表读取和写入的预置吞吐能力。在此估算中，我们使用这些单位来计算迁移后新 Amazon Keyspaces 表的读取和写入容量需求。 在本主题的后面部分，我们将讨论在预置容量模式和按需容量模式之间的选择会对计费会有怎样的影响。但是在此示例中，为了估算容量利用率，我们假设该表处于预置模式下。 + **读取** – 对于大小不超过 4 KB 的行，一个 RCU 代表一个 `LOCAL_QUORUM` 读取请求，或两个 `LOCAL_ONE` 读取请求。如果您需要读取大于 4 KB 的行，则读取操作将使用额外的 RCU。所需的 RCU 总数取决于行大小，以及要使用 `LOCAL_QUORUM` 还是 `LOCAL_ONE` 读取一致性。 例如，使用 `LOCAL_QUORUM` 读取一致性读取一个 8 KB 行需要 2 个 RCU，如果选择 `LOCAL_ONE` 读取一致性，则需要 1 个 RCU。 + **写入** – 对于大小不超过 1 KB 的行，一个 WCU 代表一次写入。所有写入操作都使用 `LOCAL_QUORUM` 一致性，使用轻量级事务 (LWT) 不收取额外费用。 所需 WCU 的总数取决于行大小。如果您需要写入大于 1 KB 的行，则写入操作将使用额外的 WCU。例如，如果行大小为 2KB，则需要 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 ``` 例如，在 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 ``` 1. 计算 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 ``` ## 选择迁移策略 从 Apache Cassandra 迁移到 Amazon Keyspaces 时，您可以在以下迁移策略之间进行选择： + **联机** - 这是一种实时迁移，使用双重写入操作开始同时向 Amazon Keyspaces 和 Cassandra 集群写入新数据。对于迁移期间要求零停机时间以及要求写后读一致性的应用程序，建议使用此迁移类型。 有关如何规划和实施在线迁移策略的更多信息，请参阅[在线迁移到 Amazon Keyspaces：策略和最佳实践](migrating-online.md)。 + **离线** - 这种迁移技术是指在停机时间段内，将数据集从 Cassandra 复制到 Amazon Keyspaces。离线迁移可以简化迁移过程，因为它不需要更改应用程序，也不需要解决历史数据和新写入内容之间的冲突。 有关如何规划离线迁移的更多信息，请参阅[离线迁移过程：Apache Cassandra 到 Amazon Keyspaces](migrating-offline.md)。 + **混合** - 这种迁移技术可以通过近乎实时的方式将更改复制到 Amazon Keyspaces，但无需写后读一致性。 有关如何规划混合迁移的更多信息，请参阅[使用混合迁移解决方案：Apache Cassandra 到 Amazon Keyspaces](migrating-hybrid.md)。 在查看了本主题中讨论的迁移技术和最佳实践之后，您可以将可用选项放在决策树中，以便根据您的要求和可用资源设计迁移策略。