复制会导致请求限制吗？答案

【问题标题】：Can replication cause request throttling?复制会导致请求限制吗？
【发布时间】：2021-11-23 02:46:29
【问题描述】：

我有以下用例：

我们有单个写入区域 Azure Cosmos
数据库将被复制到其他 Azure 区域（例如，另外 5 个 Azure 区域被视为只读副本）
我们有一个日常 ETL 作业，不能中断用户查询数据库。正因为如此，我们在应用层限制了我们向 Cosmos 发出的请求——例如在配置的 10k RUs/s 中，我们仅消耗 5k RUs/s（严格来说，我们使用 Auto-Scale 设置配置 1k RUs/s）。多亏了这一点，我们在执行 ETL 工作时消耗了 50% 的可用 RU。

问题：

是否有可能在复制期间我们会在其中一个只读副本中达到 100% 的 RU 利用率，因为 Cosmos 会尝试尽可能快地复制所有内容？

【问题讨论】：

标签： azure-cosmosdb database-replication throttling

【解决方案1】：

这取决于 (1) ETL 是从 Cosmos DB 读取作为源还是写入 Cosmos DB 作为目标，以及 (2) 聚合工作负载（ETL + 应用程序）是什么样的。

我会解释的-

考虑 RU 的最佳方式是将其作为执行请求所需的物理系统资源（CPU、内存、IOP）的代理指标。
必须将写入应用到所有区域 - 因此会消耗每个复制区域中的 RU（CPU/内存/IOP）。假设一个由美国西部 + 美国东部 + 北欧组成的 3 区域设置示例 - 写入记录将导致美国西部、美国东部和北欧的 RU 消耗。
可以独立于另一个区域向单个区域提供读取。假设一个由美国西部 + 美国东部 + 北欧组成的 3 区域设置示例 - 在美国西部读取记录对美国东部或北欧没有影响。

按照你的建议-

对 ETL 作业进行速率限制是一个不错的选择。取决于您的 ETL 工具 - 其中一些工具更易于使用客户端速率限制配置选项（例如，Azure 数据工厂数据流和 Cosmos DB 核心 SQL API 的 spark 连接器具有“写入吞吐量预算”概念） - 或者，您可以缩减 ETL 作业本身，以确保 ETL 作业成为自然瓶颈。
配置自动缩放最大值以便为 [速率受限的 ETL 所需的 RU/秒] + [应用程序所需的预期 RU/秒的上限] 留有足够的余量也是一个不错的选择 - 同时还要注意 Cosmos DB 的自动缩放带有 10 倍的缩放因子。（例如，在 cosmos db 自动缩放上配置 20K RU/秒的最大值会导致自动缩放在 2K - 20K RU/秒之间）。
值得一提的旁注...取决于 ETL 作业的用例 - 如果这是来自 OLTP => OLAP 的经典 ETL，则可能值得考虑查看 Cosmos DB 的分析存储 + Synapse链接功能集作为一种更简单的开箱即用解决方案。

【讨论】：

谢谢！在我们的用例中，它是数据负载，因此 99% 的 RU 用于创建文档。我们正在配置最大 10k RU（因为我们现在只想拥有一个物理分区）。我们不想在加载期间消耗超过 50% 的最大 RU，因为我们仍然需要处理查询（我们可以接受更多时间的加载）。在我们的单一写入区域中，我们可以限制我们的请求。但是，我们担心复制可能每秒需要更多的 RU（总共相同的 RU，但时间段更短），并且查询将受到限制。能否详细说明一下？
每个区域都有自己的 RU/s。如果您想限制为 5000 RU/s，然后测量插入您尝试 ETL 的每个文档的成本，然后将您的摄取限制在该数量。（1 个文档是 10 RU/s 插入 = 500 个文档/秒）。
感谢马克的评论！我在这里想说的是，我们只能对我们正在发出的请求应用速率限制。我们无法控制复制的速度/吞吐量（或者至少我不知道该怎么做）。我们可以为每个区域提供最多 10k RU。如果文件的负载超过例如2 小时消耗不超过 5k RUs/s 创建文档，是否有可能由于其他区域的复制，我们会看到 RU 爆发消耗 10k RUs/s，从而使所有可用吞吐量饱和，例如1 分钟？
一致性策略是控制复制速度的唯一方法，但即便如此，它也可能起不了多大作用。该服务将使用您拥有的给定 RU 尽可能快地复制。每个区域都有自己的 RU/s。您不计算写入区域的 RU/s。复制使用剩余的 RU/s。除非您使用强一致性，否则它不应该阻止写入，但它不会是 RU/s 的因素，而是由于在远距离区域 (PACLC) 中复制和提交导致的延迟。
知道了，谢谢。所以答案是：是的，复制可能会导致吞吐量饱和，并且在我的读取区域中，查询可能会因此受到限制，对吗？