有关 Azure Cosmos DB for Apache Cassandra 的常见问题解答

以下是 API for Cassandra 服务和 API for Apache Cassandra 之间的一些主要差异：

• Apache Cassandra 建议分区键的大小限制为 100 MB。 用于 Azure Cosmos DB 的 Cassandra API 允许每个分区的大小高达 20 GB。
• Apache Cassandra 允许禁用持久提交。 可以跳过写入提交日志，直接转到内存中数据结构。 如果在将内存中数据结构刷新到磁盘上的 SSTables 之前节点出现故障，则可能导致数据丢失。 Azure Cosmos DB 始终执行持久提交，以帮助防止数据丢失。
• 如果工作负荷涉及多次替换或删除，Apache Cassandra 可能会降低性能。 原因是“读取工作负荷”需要跳过逻辑删除来提取最新数据。 当工作负载有许多替换操作或删除操作时，Cassandra API 不会降低读取性能。
• 在高替换工作负载的情况下，需要运行压缩来合并磁盘上的 SSTables。 （需要合并，因为 Apache Cassandra 的写入是只进行追加。多个更新会存储为需要定期合并的单个 SSTable 条目）。 这种情况还可能会导致压缩期间读取性能降低。 Cassandra API 中不会对性能造成影响，因为 API 不实现压缩。
• 使用 Apache Cassandra 可以将复制因子设置为 1。 但是，如果包含数据的唯一节点出现故障，则会导致低可用性。 这对于 Azure Cosmos DB 的 API for Cassandra 而言不是问题，因为复制因子始终为 4（仲裁为 3）。
• 在 Apache Cassandra 中添加或删除节点需要手动干预，且由于现有节点将部分标记范围转移到新节点，新节点上的 CPU 使用率较高。 停止使用某个现有节点时，会发生同样的情况。 但是，Cassandra API 横向扩展时，服务或应用程序中不会产生任何问题。
• 不需要像在 Apache Cassandra 中那样在群集中每个节点上设置 num_tokens。 Azure Cosmos DB 完全托管节点和标记范围。
• Cassandra API 是完全托管的。 不需要 Apache Cassandra 中使用的命令，例如修复和解除授权。

Azure Cosmos DB 的 API for Cassandra 支持 Cassandra 查询语言 (CQL) 版本 3.x。 它的 CQL 兼容性基于公共 Apache Cassandra GitHub 存储库。 如果有关于支持其他协议的反馈，请发送电子邮件至 askcosmosdbcassandra@microsoft.com。

Azure Cosmos DB 根据以下表的创建位置设置容器的默认吞吐量：Azure 门户或 CQL。

Azure Cosmos DB 针对操作设置上限，在性能和延迟方面提供保障。 如果引擎可以针对租户的操作实施调控，则可以提供这些保证。 设置吞吐量可确保在吞吐量和延迟方面获得保障，因为平台会保留此容量，并保证操作成功。 可以灵活更改吞吐量以便从应用程序的季节性因素中受益并节省成本。

Azure Cosmos DB 中的请求单位数一文介绍了吞吐量概念。 表的吞吐量平均分布到各个基础物理分区中。

Azure Cosmos DB 使用每秒请求单位数 (RU/s) 作为所提供的吞吐量的单位。 通过 CQL 创建的表的默认吞吐量为 400 RU。 可以通过 Azure 门户更改 RU。

CQL

CREATE TABLE keyspaceName.tablename (user_id int PRIMARY KEY, lastname text) WITH cosmosdb_provisioned_throughput=1200

.NET

int provisionedThroughput = 400;
var simpleStatement = new SimpleStatement($"CREATE TABLE {keyspaceName}.{tableName} (user_id int PRIMARY KEY, lastname text)");
var outgoingPayload = new Dictionary<string, byte[]>();
outgoingPayload["cosmosdb_provisioned_throughput"] = Encoding.UTF8.GetBytes(provisionedThroughput.ToString());
simpleStatement.SetOutgoingPayload(outgoingPayload);

Azure Cosmos DB 针对操作设置上限，在性能和延迟方面提供保障。 如果引擎可以针对租户的操作实施调控，则可以提供这些保证。 设置吞吐量可确保在吞吐量和延迟方面获得保障，因为平台会保留此容量，并保证操作成功。

当超出此容量时，会收到以下错误消息，指出已耗尽容量：

0x1001 超载：无法处理此请求，因为“请求速率太大”

必须查明是哪些操作（及其数据量）导致了此问题。 可以通过 Azure 门户上的指标了解超出了预配容量的已消耗容量。 然后，你需要确保容量差不多是在所有基础分区中平均消耗的。 如果你看到一个分区在消耗大多数吞吐量，则说明存在工作负载倾斜。

相关指标显示了吞吐量在若干小时内、若干天内以及每七天内在各个分区中的使用情况或总体使用情况。 有关详细信息，请参阅使用 Azure Cosmos DB 中的指标进行监视和调试。

Azure Cosmos DB 诊断日志记录一文中介绍了诊断日志。

是，分区键用来将实体放置在正确位置。 在 Azure Cosmos DB 中，它用来查找存储在物理分区中的正确逻辑分区。 在 Azure Cosmos DB 中分区和缩放一文中很好地解释了分区概念。 此处必须记住的一点是，逻辑分区不应当超出 20 GB 的限制。

Azure Cosmos DB 是基于服务级别协议 (SLA) 的系统。 可提供无限缩放，并在延迟、吞吐量、可用性和一致性方面提供保障。 此无限制的存储是通过使用分区作为键概念的数据水平横向扩展实现的。 在 Azure Cosmos DB 中分区和缩放一文中很好地解释了分区概念。

应当遵循每个逻辑分区的实体数或项数不超过 20-GB 的限制。 为确保应用程序能够很好地进行缩放，建议不要创建热分区，即，将所有信息存储在一个分区内并查询它。 只有存在数据倾斜时，也就是说，当一个分区键有大量数据（超过 20 GB）时，才会发生此错误。 可以使用存储门户查明数据的分布。 修复此错误的方法是：重新创建表并选择一个细粒度的主键（分区键），这可以实现更好的数据分布。

Azure Cosmos DB 可以通过对存储进行横向扩展来存储无限的数据。 此存储与吞吐量无关。 是的，你始终可以使用 Cassandra API 通过指定正确的主键/分区键来存储和检索键和值。 这些单独的键获取其自己的逻辑分区并存在于物理分区之上，且不会出现问题。

是的，可以使用 Cassandra API 创建多个表。 这些表中的每一个都被视为用于吞吐量和存储的单元。

Azure Cosmos DB 是资源调控的系统，适用于数据和控制平面活动。 与集合和表一样，容器是针对给定吞吐量容量预配的运行时实体。 快速连续创建这些容器是非预期的活动，可能会被限制。 如果存在立即删除或创建表的测试，请尽量将它们隔开。

表的数量没有实际限制。 如果需要创建大量表（总大小超过 10 TB 的数据），而不是常见的数十个或几百个，请发送电子邮件到 askcosmosdbcassandra@microsoft.com。

键空间的数量没有实际限制，因为它们是元数据容器。 如果有大量键空间，请发送电子邮件到 askcosmosdbcassandra@microsoft.com。

是的。 假设均匀分布分区，存储容量会自动管理，并在推入更多的数据时增加。 因此，可放心地导入所需数量的数据，不需要管理和预配节点等等。 但是，如果预期数据随即会有大量增长，比较有意义的做法是直接预配预期的吞吐量，而不是一开始预配较低的吞吐量，然后随即增加。

用于 Azure Cosmos DB 的 Cassandra API 提供协议级的兼容性来执行操作。 它消除了管理、监视和配置的复杂性。 开发人员/用户无需担心可用性、逻辑删除、键缓存、行缓存、布隆筛选器和其他许多设置。 Cassandra API 注重于提供所需的读取和写入性能，不会产生配置和管理开销。

Cassandra API 可简化容量规划，并应对吞吐量和存储方面的弹性需求。 借助 Azure Cosmos DB，你可以预配所需的吞吐量。 然后，可以在一整天中多次上调和下调吞吐量，而无需担心如何添加、删除或管理节点。 节点和群集管理不需要使用工具。

出于可用性和低延迟的原因，Azure Cosmos DB 提供现成的全局分发。 不需要设置副本或其他内容。 写入内容均在你进行写入的区域中经过仲裁永久认可，同时提供性能保障。

Azure Cosmos DB 为读取、写入和吞吐量提供性能保障。 因此，无需担心改动配置设置或不小心实施了手动操控会出现问题。 这些设置包括布隆筛选器、缓存、读取修复机会、gc_grace 和压缩 memtable_flush_period。

是的，支持 TTL。

Azure Cosmos DB 是一个平台服务，可帮助你提高工作效率，而无需担心如何管理和监视基础结构。 例如，你无需使用各种工具监视节点状态、副本状态、gc 和 OS 参数。 只需在门户指标中关注可用的吞吐量，以查明你是否受到限制，然后增大或减小该吞吐量。 方法：

• 监视 SLA
• 使用指标
• 使用诊断日志

Apache Cassandra SDK 的使用 CQLv3 的客户端驱动程序用于客户端程序。 如果使用其他驱动程序或者遇到问题，请向 askcosmosdbcassandra@microsoft.com 发送邮件。

是的，可以使用正则语法创建复合分区键。

不可以，不支持 sstableloader。

目前，Azure Cosmos DB 针对云环境提供了优化的体验，且不产生操作开销。 如果需要配对，请向 askcosmosdbcassandra@microsoft.com 发送邮件并在其中提供你的方案的说明。 我们正致力于提供一项产品/服务，以便帮助用户将本地或云 Cassandra 群集与用于 Azure Cosmos DB 的 Cassandra API 配对。

Azure Cosmos DB 的所有 API 都提供间隔四小时的两个免费完整备份。 因此，无需设置备份计划。

可以自行管理备份保留期和频率。

如果想从备份进行还原，请发送电子邮件至 askcosmosdbcassandra@microsoft.com 或提交支持案例。 Azure Cosmos DB 的自动联机备份和还原一文中提供了有关备份功能的信息。

Cassandra API 借助 Azure Cosmos DB 的全局分布式平台。 为了确保应用程序能够容许数据中心停机，需在 Azure 门户中至少再为帐户启用一个区域。 有关详细信息，请参阅使用 Azure Cosmos DB 实现高可用性。

可以视需要为帐户添加任意数目的区域，并通过提供故障转移优先级来控制可将该帐户故障转移到哪个位置。 若要使用数据库，还需要在那里提供一个应用程序。 这样，客户就不会遇到停机情况。

否。 Cassandra API 支持辅助索引，后者与 Apache Cassandra 的行为类似。 API 默认不会对每个属性编制索引。

是，系统支持该操作。 可以在使用 Azure Cosmos DB 模拟器进行本地开发和测试一文中找到有关如何启用此操作的详细信息。

可以通过将数据迁移到 Azure Cosmos DB 中的 Cassandra API 帐户教程，了解迁移选项。

相关内容

• 入门：弹性缩放 Azure Cosmos DB for Apache Cassandra 帐户

下一步