制定从 Apache Cassandra 迁移到 Amazon Keyspaces 的迁移计划 - Amazon Keyspaces（Apache Cassandra 兼容）
兼容性估算定价迁移策略

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

制定从 Apache Cassandra 迁移到 Amazon Keyspaces 的迁移计划

要成功从 Apache Cassandra 迁移到 Amazon Keyspaces，我们建议您查看适用的迁移概念和最佳实践，并比较可用选项。本主题通过介绍几个关键概念以及可供您使用的工具和技术，概述了迁移过程的工作原理。您可以评估不同的迁移策略，以选择最符合您要求的策略。

主题

功能兼容性

在迁移之前，请仔细考虑 Apache Cassandra 和 Amazon Keyspaces 之间的功能差异。Amazon Keyspaces 支持所有常用的 Cassandra 数据面板操作，例如创建键空间和表、读取数据和写入数据。但是，有些 Cassandra APIs 是 Amazon Keyspaces 不支持的。有关支持的更多信息APIs，请参阅支持的 Cassandra API、操作、函数和数据类型。有关 Amazon Keyspaces 和 Apache Cassandra 之间所有功能差异的概述，请参阅。功能差异：Amazon Keyspaces 与 Apache Cassandra

要将您正在使用的 Cassandra APIs 和架构与 Amazon Keyspaces 中支持的功能进行比较，您可以在上运行亚马逊密钥空间工具包中提供的兼容性脚本。GitHub

如何使用兼容性脚本

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

  2. 兼容性脚本使用的参数与类似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查询，并保持独特的读/写流量。根据表考虑您的需求，与 Amazon Keyspaces 表级资源隔离和读/写吞吐量容量模式保持一致。借助 Amazon Keyspaces，您可以单独为表定义读/写容量和自动扩展策略。了解表要求有助于您根据功能、成本和迁移工作量确定要迁移的表的优先级。

在迁移之前，请收集以下 Cassandra 表指标。此信息有助于估算您在 Amazon Keyspaces 上的工作负载成本。

  • 表名-完全限定密钥空间的名称和表名。

  • 描述-对表的描述，例如表的使用方式或其中存储的数据类型。

  • 每秒平均读取次数-在较长时间间隔内对表进行坐标级读取的平均次数。

  • 每秒平均写入次数-在较长时间间隔内对表执行的平均坐标级写入次数。

  • 平均行大小（以字节为单位）-以字节为单位的平均行大小。

  • 中的存储大小 GBs-表的原始存储大小。

  • 读取一致性细分-使用最终一致性（LOCAL_ONE或ONE）与强一致性（）的读取的百分比。LOCAL_QUORUM

下表显示了计划迁移时需要汇总的有关表的信息的示例。

表名称 描述 每秒平均读取次数 平均每秒写入次数 平均行大小（以字节为单位） 存储空间大小 GBs 读取一致性分解

mykeyspace.myt

用于存储购物车历史记录

10000

5000

2,200

2000

100% LOCAL_ONE

我的keyspace.mytable2

用于存储最新的个人资料信息

20000

1000

850

1000

25% LOCAL_QUORUM 75% LOCAL_ONE

如何收集表格指标

本节提供了有关如何从现有 Cassandra 集群中收集必要的表格指标的分步说明。这些指标包括行大小、表大小和每秒读/写请求数 () RPS。它们允许您评估 Amazon Keyspaces 表的吞吐量容量要求并估算价格。

如何在 Cassandra 源表上收集表格指标

  1. 确定行大小

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

    该图显示了使用分区器在 Cassandra 代币范围内的典型数据murmur3分布。

    您可以使用上提供的行大小采样器脚本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 中的行大小

  2. 确定桌子大小

    使用 Amazon Keyspaces，您无需提前配置存储空间。Amazon Keyspaces 会持续监控您的表格的可计费大小，以确定您的存储费用。存储按每月每 GB 计费。Amazon Keyspaces 表大小基于单个副本的原始大小（未压缩）。要监控 Amazon Keyspaces 中的表格大小，您可以使用该指标BillableTableSizeInBytes，该指标显示在中每个表中。 AWS 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

  3. 捕获读取和写入次数

    要确定 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 表的读取和写入请求速率。

    • 使用现有的卡桑德拉监控

      您可以使用下表中显示的指标来观察读取和写入请求。请注意，指标名称可能会根据您使用的监控工具而变化。

      维度 卡桑德拉公制 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

  4. 确定表的容量利用率

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

    Amazon Keyspaces 使用读取容量单位 (RCUs) 和写入容量单位 (WCUs) 来衡量表读取和写入的预配置吞吐容量。在此估算中，我们使用这些单位来计算迁移后新 Amazon Keyspaces 表的读取和写入容量需求。在本主题的后面部分，我们将讨论在预置容量模式和按需容量模式之间的选择如何影响计费。但是为了估算容量利用率，我们假设该表处于预配置模式。

    一个RCULOCAL_QUORUM表示对大小不超过 4 KB 的行的一个LOCAL_ONE读取请求或两个读取请求。如果您需要读取大于 4 KB 的行，则读取操作会使用额外的RCUs。RCUs所需的总数取决于行大小，以及您是要使用一致性LOCAL_QUORUM还是LOCAL_ONE读取一致性。例如，RCUs使用读取一致性读取 8 KB 的行需要 2，RCU如果您选择LOCAL_QUORUMLOCAL_ONE读取一致性，则需要 1。

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

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

    中的写入容量WCUs可以通过将请求数乘以平均行大小除以 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 个读取请求。RCUs如果您目前在 Cassandra 表上每秒执行 1,653 个写入请求，行大小为 2.5KB，则亚马逊密钥空间中每秒需要执行 4,9 WCUs 59 个写入请求。此示例用以下公式表示。

    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

  5. 计算 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

选择迁移策略

从 Apache Cassandra 迁移到 Amazon Keyspaces 时，您可以在以下迁移策略之间进行选择：

  • 联机 — 这是一次实时迁移，使用双写操作开始同时向 Amazon Keyspaces 和 Cassandra 集群写入新数据。对于迁移期间要求零停机时间且写入一致性后读取的应用程序，建议使用此迁移类型。有关如何规划和实施在线迁移策略的更多信息，请参阅在线迁移到 Amazon Keyspaces：策略和最佳实践。

  • 离线 — 这种迁移技术涉及在停机时间段内将数据集从 Cassandra 复制到 Amazon Keyspaces。离线迁移可以简化迁移过程，因为它不需要更改应用程序，也不需要解决历史数据和新写入之间的冲突。有关如何规划离线迁移的更多信息，请参阅离线迁移流程：Apache Cassandra 到 Amazon Keyspaces。

  • 混合 — 这种迁移技术允许以近乎实时的方式将更改复制到 Amazon Keyspaces，但不会保持写后读取的一致性。

在查看了本主题中讨论的迁移技术和最佳实践之后，您可以将可用选项放在决策树中，以便根据您的要求和可用资源设计迁移策略。