弹性缩放 Azure Cosmos DB Cassandra API 帐户Elastically scale an Azure Cosmos DB Cassandra API account

适用于: Cassandra API

有多种不同的选项可以探索 Azure Cosmos DB API for Cassandra 的弹性。There are a variety of options to explore the elastic nature of the Azure Cosmos DB API for Cassandra. 若要了解如何在 Azure Cosmos DB 中有效地进行缩放,必须了解如何预配合适数量的请求单位(RU/秒),以考虑系统的性能需求。To understand how to scale effectively in Azure Cosmos DB, it is important to understand how to provision the right amount of request units (RU/s) to account for the performance demands in your system. 若要了解请求单位的详细信息,请参阅请求单位一文。To learn more about request units, see the request units article.

对于 Cassandra API,可以使用 .NET 和 Java SDK 检索单个查询的请求单位费用。For the Cassandra API, you can retrieve the Request Unit charge for individual queries using the .NET and Java SDKs. 这有助于确定你在服务中需要预配的 RU 数/秒。This is helpful in determining the amount of RU/s you will need to provision in the service.

数据库操作消耗请求单位

处理速率限制(429 错误)Handling rate limiting (429 errors)

如果客户端消耗的资源(RU/秒)超过了预配的量,Azure Cosmos DB 将返回速率限制 (429) 错误。Azure Cosmos DB will return rate-limited (429) errors if clients consume more resources (RU/s) than the amount that you have provisioned. Azure Cosmos DB 中的 Cassandra API 在 Cassandra 本机协议中将这些异常解释为过载错误。The Cassandra API in Azure Cosmos DB translates these exceptions to overloaded errors on the Cassandra native protocol.

如果系统对延迟不敏感,使用重试可能就足以应对吞吐量速率限制。If your system is not sensitive to latency, it may be sufficient to handle the throughput rate-limiting by using retries. 请参阅 Java 代码示例,了解如何通过 Java 使用用于 Cassandra 重试策略Azure Cosmos DB 扩展,从而以透明方式处理速率限制。See the Java code sample for how to handle rate limiting transparently by using the Azure Cosmos DB extension for Cassandra retry policy in Java. 还可以使用 Spark 扩展来处理速率限制。You can also use the Spark extension to handle rate-limiting.

管理缩放Manage scaling

如果需要最大程度地降低延迟,可以在 Cassandra API 中使用多种选项来管理缩放和预配吞吐量 (RU):If you need to minimize latency, there is a spectrum of options for managing scale and provisioning throughput (RUs) in the Cassandra API:

下面的几节介绍了这些方法的优缺点。The following sections explain the advantages and disadvantages of each approach. 然后,可以确定最佳的策略,以便在系统的缩放需求、整体成本以及解决方案的效率需求之间做出平衡。You can then decide on the best strategy to balance the scaling needs of your system, the overall cost, and efficiency needs for your solution.

使用 Azure 门户Use the Azure portal

可以使用 Azure 门户缩放 Azure Cosmos DB Cassandra API 帐户中的资源。You can scale the resources in Azure Cosmos DB Cassandra API account by using Azure portal. 有关详细信息,请参阅有关对容器和数据库预配吞吐量的文章。To learn more, see the article on Provision throughput on containers and databases. 此文解释了通过 Azure 门户在数据库容器级别设置吞吐量的相对优势。This article explains the relative benefits of setting throughput at either database or container level in the Azure portal. 这些文章中提到的术语“数据库”和“容器”分别对应于 Cassandra API 的“密钥空间”和“表”。The terms "database" and "container" mentioned in these articles map to "keyspace" and "table" respectively for the Cassandra API.

此方法的优点是能够以直截了当的统包方式管理数据库的吞吐量。The advantage of this method is that it is a straightforward turnkey way to manage throughput capacity on the database. 但缺点是,在许多情况下,缩放方法可能要求实现某些程度的自动化,它既要确保经济高效,同时又要具备高性能。However, the disadvantage is that in many cases, your approach to scaling may require certain levels of automation to be both cost-effective and high performing. 后续部分将介绍相关的方案和方法。The next sections explain the relevant scenarios and methods.

使用控制平面Use the control plane

用于 Cassandra 的 Azure Cosmos DB API 提供使用各种控制平面功能以编程方式调整吞吐量的功能。The Azure Cosmos DB's API for Cassandra provides the capability to adjust throughput programmatically by using our various control-plane features. 有关指导和示例,请参阅 Azure 资源管理器PowerShellAzure CLI 文章。See the Azure Resource Manager, PowerShell, and Azure CLI articles for guidance and samples.

此方法的优点是可以根据计时器自动扩展或缩减资源,以反映活动的高峰或低活动期。The advantage of this method is that you can automate the scaling up or down of resources based on a timer to account for peak activity, or periods of low activity. 请参阅此处的示例,了解如何使用 Azure Functions 和 PowerShell 实现此目的。Take a look at our sample here for how to accomplish this using Azure Functions and PowerShell.

此方法的一个缺点是,你无法实时响应不可预知的规模需求变化。A disadvantage with this approach may be that you cannot respond to unpredictable changing scale needs in real-time. 相反,你可能需要在客户端/SDK 级别利用系统中的应用程序上下文,或使用自动缩放Instead, you may need to leverage the application context in your system, at the client/SDK level, or using Autoscale.

将 CQL 查询与特定的 SDK 配合使用Use CQL queries with a specific SDK

可以针对给定的数据库或容器执行 CQL ALTER 命令,通过代码动态缩放系统。You can scale the system dynamically with code by executing the CQL ALTER commands for the given database or container.

此方法的优点在于,能够以适合应用程序的自定义方式动态应对缩放需求。The advantage of this approach is that it allows you to respond to scale needs dynamically and in a custom way that suits your application. 使用此方法,仍可利用标准 RU/秒的费用和速率。With this approach, you can still leverage the standard RU/s charges and rates. 如果系统的缩放需求大部分是可预测的(大约 70% 或更多),那么将 SDK 与 CQL 配合使用可能是一种比使用自动缩放更为经济高效的自动缩放方法。If your system's scale needs are mostly predictable (around 70% or more), using SDK with CQL may be a more cost-effective method of auto-scaling than using autoscale. 此方法的缺点是,实现重试可能会很复杂,同时,速率限制可能会增大延迟。The disadvantage of this approach is that it can be quite complex to implement retries while rate limiting may increase latency.

使用自动缩放预配吞吐量Use autoscale provisioned throughput

除了标准(手动)或以编程方式预配吞吐量外,还可以在自动缩放预配的吞吐量中配置 Azure cosmos 容器。In addition to standard (manual) or programmatic way of provisioning throughput, you can also configure Azure cosmos containers in autoscale provisioned throughput. 自动缩放会自动立即缩放,以满足指定 RU 范围内的消耗需求,而不会影响 SLA。Autoscale will automatically and instantly scale to your consumption needs within specified RU ranges without compromising SLAs. 若要了解详细信息,请参阅在自动缩放中创建 Azure Cosmos 容器和数据库一文。To learn more, see the Create Azure Cosmos containers and databases in autoscale article.

此方法的优点是,它是在系统中管理缩放需求的最简单的方法。The advantage of this approach is that it is the easiest way to manage the scaling needs in your system. 它不会在已配置的 RU 范围内应用速率限制。It will not apply rate-limiting within the configured RU ranges. 缺点是,如果系统中的缩放需求是可预测的,那么相比使用上面提到的定制控制平面或 SDK 级别方法,自动缩放在处理缩放需求方面可能并没有那么经济高效。The disadvantage is that, if the scaling needs in your system are predictable, autoscale may be a less cost-effective way of handling your scaling needs than using the bespoke control plane or SDK level approaches mentioned above.

若要设置或更改使用 CQL 的自动缩放的最大吞吐量 (RU),请使用以下内容(相应地替换密钥空间/表名称):To set or alter max throughput (RUs) for autoscale using CQL, use the following (replacing keyspace/table name accordingly):

# to set max throughput (RUs) for autoscale at keyspace level:
create keyspace <keyspace name> WITH cosmosdb_autoscale_max_throughput=5000;

# to alter max throughput (RUs) for autoscale at keyspace level:
alter keyspace <keyspace name> WITH cosmosdb_autoscale_max_throughput=4000;

# to set max throughput (RUs) for autoscale at table level:
create table <keyspace name>.<table name> (pk int PRIMARY KEY, ck int) WITH cosmosdb_autoscale_max_throughput=5000;

# to alter max throughput (RUs) for autoscale at table level:
alter table <keyspace name>.<table name> WITH cosmosdb_autoscale_max_throughput=4000;

后续步骤Next steps