azure - 如何加速 Cosmos DB 聚合查询？

Question

我们的 cosmos db 聚合查询看起来很慢并且消耗大量 RU。以下是详细信息(请参见下面的屏幕截图): 2.4 秒和 3222RU 来计算 414k 记录的结果集。这也仅算一项。通常我们希望一次对多个字段进行求和(只能在单个分区内进行)，但这样做的性能要差得多。

该集合中有 200 万条记录。我们正在使用带 SQL API 的 Cosmos DB。该特定集合按国家/地区代码分区，其中有 414,732 条记录位于法国(“FR”)，其余记录位于美国。文档大小平均为 917 字节，最小为 800 字节，最大为 1300 字节。

请注意，我们还尝试了更稀疏的分区键，例如 device_id(其中有 200 万个，每个设备 1 个文档)，这对于该查询来说结果更差。 c.calcuated.flag1 字段仅代表我们想要保留计数的“状态”(实际上我们有 8 个状态我想总结一下)。

此集合上的索引是默认的，它使用“一致”索引模式，并对所有字段进行索引(包括数字和字符串的范围索引)。RU 设置为 20,000，数据库上没有其他事件。

所以让我知道你对此的想法。是否可以合理地使用 Cosmos DB 来获得一些字段的总和或计数，而不会增加我们的 RU 费用并花费很长时间？虽然 2.4 秒还不错，但我们确实需要亚秒级的查询来完成这种事情。我们的应用程序(基于物联网)通常需要单独的文档，但有时也需要对一个国家/地区的所有文档进行此类计数。

有没有办法提高性能？

Answer 1

Cosmos DB 团队现已对聚合性能和索引的使用方式进行了一些重大更改。这是他们的索引“v2”策略，最近才推出(可能尚未对所有帐户可用，如果您有需要升级的旧数据库，请联系 MSFT)。

您可以将新结果与我最初发布的图片进行比较。

您现在会注意到文档加载时间显示为 0 毫秒，并且检索到的文档大小为 0 字节。我可以确认的加载时间现在确实非常快，因此从服务器端测量时可能会低于 1 毫秒。文档大小为 0 更有意义，因为不需要为此检索文档(仅根据索引进行计数)。

最后你可以看到 RU 从 3222 下降到 7.4 !!!!差异相当大。

现在，在单个分区内对多个列进行求和现在也非常高效，我们可以使用约 50 个 RU 对 200 万个文档一次进行大约 8 次求和，并且从函数 API 端点测量时需要大约 20-70 毫秒(因此包括网络时间)。

Cosmos DB 团队仍需要做更多工作来实现跨分区多列聚合，但我们现在的改进非常有希望。