azure - DocumentDB PartitionKey 和性能

Question

我有一个场景，我存储大量第三方数据以供业务用户进行临时分析。大多数针对数据的查询都会很复杂，需要使用多个自连接、投影和范围。

在选择用于 Azure DocumentDB 的 PartitionKey 时，我看到人们建议使用逻辑分隔符，例如 TenantId、DeviceId 等。

然而，鉴于 DocumentDB 的并行性质，我很好奇它如何处理基于某种 GUID 或大整数的 PartitionKey ，以便在大量读取期间，它将高度并行化.

考虑到这一点，我设计了一个包含两个集合的测试:

1. 测试-col-1
   • PartitionKey 是具有大约 100 个可能值的 TenantId
2. 测试-col-2
   • PartitionKey 是第三方分配的唯一值，遵循模式“AB1234568”。由第三方保证全局唯一。

两个集合都设置为 100,000 RU。

在我的实验中，我加载了两个包含大约 2,000 个文档的集合。每个文档的大小大约为 20 KB，并且是高度非规范化的。每个文档是一个订单，其中包含多个作业，每个作业包含用户、价格等。

示例查询:

SELECT
orders.Attributes.OrderNumber,
orders.Attributes.OpenedStamp,
jobs.SubOrderNumber,
jobs.LaborTotal.Amount As LaborTotal,
jobs.LaborActualHours As LaborHours,
jobs.PartsTotal.Amount As PartsTotal,
jobs.JobNumber,
jobs.Tech.Number As TechNumber,
orders.Attributes.OrderPerson.Number As OrderPersonNumber,
jobs.Status
FROM orders
JOIN jobs IN orders.Attributes.Jobs
JOIN tech IN jobs.Techs
WHERE   orders.TenantId = @TentantId
    AND orders.Attributes.Type = 1
    AND orders.Attributes.Status IN (4, 5)";

在测试中我调整了以下设置:

1. 默认ConnectionPolicy
2. Best practices ConnectionPolicy
   • ConnectionMode.Direct、Protocol.Tcp
3. 各种 MaxDegreeOfParallelism 值
4. 各种MaxBufferedItemCount

使用 EnableCrossPartitionQuery = true 查询具有 GUID PartitionKey 的集合。我正在使用 C# 和 .NET SDK v1.14.0。

在使用默认设置的初始测试中，我发现使用 TentantId 作为 PartitionKey 查询集合的速度更快，与 相比，平均需要 3,765 毫秒>4,680 毫秒(在 GUID 键控集合上)。

当我使用 TCP 将 ConnectionPolicy 设置为 Direct 时，我发现 TenantID 集合查询时间减少了近乎1000 毫秒，平均为2,865 毫秒，而 GUID 收集增加了约 800 毫秒，平均为5,492 毫秒。

当我开始使用 MaxDegreeOfParellelism 和 MaxBufferedItemCount 时，事情开始变得有趣。 TentantID 集合查询时间通常不受影响，因为查询不是跨集合，但 GUID 集合的速度显着加快，达到450 毫秒的值( >MaxDegreeOfParellelism = 2000，MaxBufferedItemCount = 2000)。

<小时/>

鉴于这些观察结果，为什么您不想使 PartitionKey 的值尽可能广泛？

Answer 1

Things started getting interesting when I started playing around with MaxDegreeOfParellelism and MaxBufferedItemCount. The TentantID collection query times were generally unaffected because the query wasn't cross-collection, however the GUID collection sped up considerably, reaching values as fast as 450 ms (MaxDegreeOfParellelism = 2000, MaxBufferedItemCount = 2000).

MaxDegreeOfParallelism可以设置 ParallelOptions 实例启用的最大并发任务数。据我所知，这是客户端并行性，它会消耗您站点上的 CPU/内存资源。

Given these observations, why would you not want to make the PartitionKey as broad a value as possible?

对于写入操作，我们可以跨分区键进行扩展，以便使用您配置的整个空间。而对于读取操作，我们需要尽量减少跨分区查找以降低延迟。

此外，正如该官方文档提到的:

The choice of the partition key is an important decision that you have to make at design time. You must pick a property name that has a wide range of values and has even access patterns.

It is a best practice to have a partition key with many distinct values (100s-1000s at a minimum).

To achieve the full throughput of the container, you must choose a partition key that allows you to evenly distribute requests among some distinct partition key values.

更多详情，您可以引用How to partition and scale in Azure Cosmos DB这个 channel 9 教程是关于 Azure DocumentDB Elastic Scale - Partitioning .