有关适用于 Apache Cassandra 的 Azure Cosmos DB 的常见问题

以下是 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 的 Cassandra API 并不存在这个问题，因为其复制因子始终为 4（对应的仲裁数量为 3）。
• 在 Apache Cassandra 中添加或删除节点需要手动干预，且由于现有节点将部分标记范围转移到新节点，新节点上的 CPU 使用率较高。 停止使用某个现有节点时，会发生同样的情况。 但是，Cassandra API 横向扩展时，服务或应用程序中不会产生任何问题。
• 不需要像在 Apache Cassandra 中那样在群集中每个节点上设置 num_tokens。 Azure Cosmos DB 完全管理节点和令牌范围。
• Cassandra API 是完全托管的。 不需要 Apache Cassandra 中使用的命令，例如修复和解除授权。

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

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

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

吞吐量概念在 Azure Cosmos DB 中的 Request Units 一文中进行了说明。 表的吞吐量平均分布到各个基础物理分区中。

Azure Cosmos DB 使用每秒请求单位数（RU/秒）作为提供吞吐量的货币。 通过 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）时，才会发生此错误。 可以使用 storage 门户找到数据的分布情况。 修复此错误的方法是：重新创建表并选择一个细粒度的主键（分区键），这可以实现更好的数据分布。

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 简化了容量规划和响应吞吐量和storage的弹性需求。 使用 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 或提交支持案例。 有关备份功能的信息，请参阅 Automatic online backup and restore with Azure Cosmos DB 一文。

Cassandra API 从 Azure Cosmos DB 的多区域分布式平台借用。 为了确保应用程序可以容忍数据中心停机，请在Azure portal中为帐户至少启用一个区域。 有关详细信息，请参阅 Azure Cosmos DB 的 高可用性。

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

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

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

您可以在将数据迁移到 Azure Cosmos DB 中的 Cassandra 帐户的 API教程中阅读有关迁移选项的信息。

相关内容

• 入门 弹性缩放用于 Apache Cassandra 帐户的 Azure Cosmos DB

后续步骤