DocumentDB PartitionKey和性能

Question

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

PartitionKey在Azure DocumentDB中选择使用时,我看到人们建议使用逻辑分隔符,如TenantId,DeviceId等.

然而,鉴于DocumentDB的并行特性,我很好奇它如何处理PartitionKey基于某种GUID或大整数的基于某种GUID或大整数,因此在大型读取期间,它将是高度分辨的.

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

1. test-col-1
   • PartitionKey 是TenantId,大约有100个可能的值
2. test-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. 最佳做法 ConnectionPolicy
   • ConnectionMode.Direct, Protocol.Tcp
3. 各种MaxDegreeOfParallelism价值观
4. 各个 MaxBufferedItemCount

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

在我使用默认设置进行的初始测试中,我发现使用TentantIdPartitionKey 查询集合的速度更快,平均值为3,765 ms,而GUID键控集合则为4,680 ms.

当我设置ConnectionPolicy为Directwith时TCP,我发现TenantID集合查询时间减少了近1000毫秒,平均减少了2,865毫秒, 而GUID集合增加了大约800毫秒,平均为5,492毫秒.

事情开始变得有趣,当我开始玩弄MaxDegreeOfParellelism和MaxBufferedItemCount.的TentantID集合查询时间分别通常不受影响,因为查询不是跨集合,然而,GUID收集加快相当,尽可能快地达到值450毫秒(MaxDegreeOfParellelism= 2000,MaxBufferedItemCount= 2000).

---

鉴于这些观察,为什么你不想让PartitionKey尽可能广泛的价值？

Answer 1

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

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

鉴于这些观察结果，您为什么不希望将 PartitionKey 设置为尽可能广泛的值？

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

另外，正如这份官方文件提到的：

分区键的选择是您在设计时必须做出的重要决定。您必须选择一个具有广泛值且具有均匀访问模式的属性名称。

最佳实践是使用具有多个不同值（至少 100-1000 个）的分区键。

为了实现容器的全部吞吐量，您必须选择一个分区键，该分区键允许您在一些不同的分区键值之间均匀分配请求。

有关更多详细信息，您可以参阅如何在 Azure Cosmos DB 中进行分区和缩放以及有关Azure DocumentDB Elastic Sc​​ale - 分区的频道 9 教程。