之前使用 Apache Cassandra 的用户如何适应 Azure Cosmos DB for Apache Cassandra

项目
04/03/2023

适用对象： Cassandra

Azure Cosmos DB for Apache Cassandra 提供与现有 Cassandra SDK 和工具的线路协议兼容性。只需进行极少量的更改，就能运行旨在通过 API for Cassandra 连接到 Apache Cassandra 的应用程序。

使用 API for Cassandra 时，请务必注意 Apache Cassandra 与 Azure Cosmos DB 之间的差异。如果你熟悉本机 Apache Cassandra，本文可以帮助你开始使用 Azure Cosmos DB for Apache Cassandra。

功能支持

API for Cassandra 支持大量的 Apache Cassandra 功能。有些功能不受支持或存在限制。在迁移之前，请确保所需的 Azure Cosmos DB for Apache Cassandra 功能受支持。

复制

在规划复制时，同时考虑迁移和一致性非常重要。

尽管可以通过 Cassandra 查询语言 (CQL) 二进制协议 v4 线路协议来与 API for Cassandra 通信，但 Azure Cosmos DB 实现自身的内部复制协议。不能使用 Cassandra gossip 协议进行实时迁移或复制。有关详细信息，请参阅使用双重写入从 Apache Cassandra 实时迁移到 API for Cassandra。

有关脱机迁移的信息，请参阅使用 Azure Databricks 将数据从 Cassandra 迁移到 Azure Cosmos DB for Apache Cassandra 帐户。

尽管在 Apache Cassandra 和 Azure Cosmos DB 中实现复制一致性的方法相似，但了解两者的不同之处非常重要。有一份映射文档比较了 Apache Cassandra 和 Azure Cosmos DB 实现复制一致性的方法。但是，强烈建议你具体参阅 Azure Cosmos DB 一致性设置。

代码示例

API for Cassandra 旨在与现有的应用程序代码配合使用。如果你遇到连接相关的错误，请使用快速入门示例作为起点，发现可能需要在现有代码中做出的次要设置更改。

我们还提供了适用于 Java v3 和 Java v4 驱动程序的更多深入示例。这些代码示例实现自定义扩展，从而实现建议的客户端配置。

你还可以使用适用于 Java Spring Boot（v3 驱动程序）和 Java Spring Boot（v4 驱动程序）的示例。

存储

API for Cassandra 由文档导向的 NoSQL 数据库引擎 Azure Cosmos DB 提供支持。 Azure Cosmos DB 维护元数据，这可能会导致特定工作负载所需的物理存储量发生变化。

本机 Apache Cassandra 和 Azure Cosmos DB 之间的存储要求差异在较小的行大小中最为明显。在某些情况下可能会抵消这种差异，因为 Azure Cosmos DB 不实现压缩或逻辑删除。这种因素很大程度上取决于工作负载。如果你不确定存储要求，我们建议首先创建概念证明。

多区域部署

默认情况下，本机 Apache Cassandra 是一个多主数据库系统。 Apache Cassandra 不提供单主数据库和使用多区域复制进行只读操作的选项。在应用程序级别故障转移到用于写入的另一区域的概念在 Apache Cassandra 中是多余的。所有节点都是独立的，并且不存在单一故障点。但是，Azure Cosmos DB 提供现成的功能来配置用于写入的单主数据库或多主数据库区域。

使用单主数据库区域进行写入的优势之一是可以避免跨区域冲突的情况。你可以选择在多个区域之间保持强一致性，同时仍保持一定程度的高可用性。

注意

对于本机 Apache Cassandra，无法实现跨区域的强一致性和零恢复点目标 (RPO)，因为所有节点都能够为写入提供服务。可以在单写入区域配置中为 Azure Cosmos DB 配置跨区域的强一致性。但是，与本机 Apache Cassandra 一样，无法为配置了多个写入区域的 Azure Cosmos DB 帐户配置强一致性。分布式系统无法在提供零 RPO 的同时提供零恢复时间目标 (RTO)。

有关详细信息，请参阅 API for Cassandra recommendations for Java（适用于 Java 的 API for Cassandra 建议）中的 Load balancing policy（负载均衡策略）。另请参阅官方 Cassandra Java v4 驱动程序的代码示例中的故障转移方案。

请求单位

运行本机 Apache Cassandra 群集与预配 Azure Cosmos DB 帐户的主要差别之一是预配数据库容量的方式。在传统的数据库中，容量以 CPU 核心数、RAM 和 IOPS 表示。 Azure Cosmos DB 是一个多租户平台即服务数据库。容量是使用称作请求单位的单个规范化指标表示的。发送到数据库的每个请求都会产生请求单位成本（RU 成本）。可以分析每个请求以确定其成本。

使用请求单位作为指标的好处是能够确定性地预配数据库容量，以获得高度可预测的性能和效率。在分析每个请求的成本后，可以使用请求单位将发送到数据库的请求数直接与需要预配的容量相关联。这种容量预配方式的难点在于需要深入了解工作负载的吞吐量特征。

我们强烈建议分析你的请求。使用这些信息来帮助估算需要预配的请求单位数。下面这些的文章可帮助你做出估算：

容量预配模型

在传统的数据库预配中，已提前预配固定的容量来应对预期的吞吐量需求。 Azure Cosmos DB 提供称作预置吞吐量的基于容量的模型。作为多租户服务，Azure Cosmos DB 还提供自动缩放和无服务器模式的基于消耗量的模型。工作负载从每种基于消耗量的预配模型中受益的程度取决于该工作负载的吞吐量可预测性。

一般而言，具有可预测吞吐量的稳定态工作负载主要从预配吞吐量中受益。休眠期较长的工作负载从无服务器模型中受益。具有持续最小吞吐量级别但具有不可预测峰值的工作负载主要从自动缩放模式中受益。建议查看以下文章来清楚地了解满足吞吐量需求的最佳容量模型：

分区

Azure Cosmos DB 中的分区类似于 Apache Cassandra 中的分区。主要差异之一是，Azure Cosmos DB 针对水平缩放进行了更多优化。在 Azure Cosmos DB 中，对任一物理分区中可用的垂直吞吐量容量施加了限制。当现有数据模型存在显著的吞吐量偏差时，此项优化的效果最为明显。

采取相应措施，确保分区键设计能够让请求相对均匀地分布。有关逻辑分区和物理分区的工作原理，以及每个分区的吞吐量容量限制的详细信息，请参阅 Azure Cosmos DB for Apache Cassandra 中的分区。

缩放

在本机 Apache Cassandra 中，增大容量和规模涉及到在群集中添加新节点，并确保将这些节点正确添加到 Cassandra 环中。在 Azure Cosmos DB 中，添加节点的操作是透明的且可自动完成。缩放取决于为键空间或表预置了多少请求单位。当物理存储或所需吞吐量达到逻辑或物理分区允许的限制时，就会发生物理计算机缩放。有关详细信息，请参阅 Azure Cosmos DB for Apache Cassandra 中的分区。

速率限制

预配请求单位的难点之一（尤其是使用预配吞吐量的情况下）是速率限制。如果客户端消耗的资源超过预配数量，Azure Cosmos DB 将返回速率限制错误。 Azure Cosmos DB 中的 API for Cassandra 在 Cassandra 本机协议中将这些异常解释为过载错误。有关如何避免应用程序中发生速率限制的信息，请参阅防止 Azure Cosmos DB for Apache Cassandra 操作发生速率限制错误。

Apache Spark 连接器

许多 Apache Cassandra 用户使用 Apache Spark Cassandra 连接器来查询其数据，以解决分析和数据移动需求。你可以使用相同的连接器以相同方式连接到 API for Cassandra。在连接到 API for Cassandra 之前，请先查看从 Spark 连接到 Azure Cosmos DB for Apache Cassandra。具体而言，请参阅优化 Spark 连接器吞吐量配置部分。

排查常见问题

有关常见问题的解决方法，请参阅排查 Azure Cosmos DB for Apache Cassandra 中的常见问题。