azure - CosmosDb 具有高分区键基数的缓慢更改性能

Question

我目前正在使用 Cosmos 的 IOT 事件源构建一个应用程序。 Cosmos 文档中指出

Have a high cardinality. In other words, the property should have a wide range of possible values.

我有 4 个容器事件、快照、租约和 View 。

数据库中的每个文档都有一个通过在末尾应用新的 Guid 综合创建的唯一分区键。我使用 STARTSWITH 查询来查询数据。因此，这创建了可能的最高基数，因为每个值都是唯一的。我选择这种方法是因为不同的物联网设备发送不同量的数据并试图避免热分区。

事件发生后，每个物化 View 都有一个 Azure 函数共享相同的租赁容器，这就是性能下降的地方。

所以现在我有 6 个 View ，这意味着我有 6 个 Azure 函数来构建每个 View 。我尝试将 RU 增加到 10,000 并水平扩展功能(应用程序服务计划)。然而，Cosmos 仍然使用单个分区键范围，每个 View 仍然只使用单个更改源分区，导致有时延迟超过 6 小时才能保证 View 准确。因此，没有可扩展性让更多设备上线。

对分区键使用唯一值是一种糟糕的设计吗？我是否应该使用类似于 id|day|month|year 的内容每天接受某些热分区？

或者我完全错过了其他东西吗？

编辑一些附加信息

• CosmosDb 和 Functions 托管在同一区域
• 通过应用服务计划，我可以看到 CPU 在更改源延迟期间确实跳至 100%，但其他实例并未按预期消耗
• 当我们开始摄取更多事件时会导致延迟，因此更改提要/功能无法跟上
• 该函数中发出的唯一请求是向 Cosmos 发出的，没有任何外部请求
• 租约不会分散以帮助处理更大的工作量

在下面您可以看到某些 View /函数仍然落后，而其他 View /函数正在迎头 catch 。我本以为它们会并行工作，因为它们是单独的函数

Answer 1

如果您的目的是确保函数尽快读取数据，我首先看一下 https://learn.microsoft.com/en-us/azure/cosmos-db/troubleshoot-changefeed-functions#my-changes-take-too-long-to-be-received

您需要了解并分析函数执行中的滞后/延迟在哪里。例如，如果瓶颈受 CPU 限制，则实例卷意义上的扩展通常会有所帮助(因为扩展有效地将部分更改源处理分配给其他计算机)。更改源触发器使用下面的更改源处理器，该处理器由以下逻辑控制:https://learn.microsoft.com/en-us/azure/cosmos-db/change-feed-processor#dynamic-scaling (跨机器分配租约，其中 1 个租约代表一个物理分区)。如果您有 10 个租约/物理分区，则您可以将工作负载分配到 10 个实例。但同样，这仅有助于衡量问题是否受 CPU 限制。如果您的函数代码的主要时间消耗是 I/O 操作(例如对其他服务的网络请求)，那么您需要弄清楚如何改进它，因为拥有更多可用的机器可能不会像您想象的那样有帮助(抛出更多 CPU 并不总是答案)。

如果您已经确保连接配置正确(从最近的区域读取)，则应该分析您的函数代码以了解性能问题所在。由于 Change Feed 需要断言顺序(Change Feed 的功能之一是事件按顺序传递)，因此只有在处理了先前的事件后才能读取新事件。如果您以每秒 X/文档的速度摄取数据，而您的函数以每秒 Y/文档的速度处理，其中 X 远高于 Y，那么您的问题是您的处理逻辑较慢，并且可能始终落后。

编辑:在添加新信息后，当事件量增加时，函数代码听起来好像出现了问题。如前所述，并行性基于租约数量，目前基于 physical partitions 。 1 个租约 = 1 个物理分区 = 1 个实例的软上限可以处理该工作，因为随着数据的增长会添加新分区，动态添加新租约，可以利用更多实例。

我的建议仍然是双击为什么事件数量增加会导致功能代码增加其延迟。状态或逻辑中存在某些东西，它经历的事件越多，处理就越滞后，这可能是关键/原因。