在Azure Cosmos DB中，这是一个糟糕的分区密钥方案吗？

Question

{
    "id": "M7o_ddRB7VRpjUA",
    "ownerTime": "2458671015_202008",
    "ownerId": "2458671015",
    "callTime": "2020-08-30T18:47:44.424+00:00",
    "direction": "Outbound",
    "action": "VoIP Call",
    "result": "Call connected",
    "duration": 57,
    "hasR": true,
    "hasV": false,
    "xNums": [
        "2605"
    ],
    "xIds": [
        "2204328014"
    ],
    "names": [
        "sally wayfield"
    ],
    "phoneNums": [
        "2098368307",
        "2097449211"
    ],
    "emails": [
        "[e-mail]"
    ],
    "xNums_s": "2605",
    "xIds_s": "2204328014",
    "phoneNums_s": "2098368307 2097449211",
    "names_s": "sally wayfield",
    "emails_s": "[e-mail]",
    "_rid": "QB1nAK5kxPMBAAAAAAAAAA==",
    "_self": "dbs/QB1nAA==/colls/QB1nAK5kxPM=/docs/QB1nAK5kxPMBAAAAAAAAAA==/",
    "_etag": "\"d2013319-0000-0500-0000-5f4c63dd0000\"",
    "_attachments": "attachments/",
    "_ts": 1598841821
}

我的下一个想法是将时态数据作为分区密钥的一部分。这似乎是有意义的，因为我们每天都在批量导入大量的时间戳数据。而且，99%的针对该数据库的查询都包含日期范围。我提出了一个派生的抽象值，在上面的文档中标记为ownertime。此值将帐户id与时间因子（每个电话的年和月）组合在一起。使用该方案，每个租户每年将获得12个分区，而不是整个帐户的单个分区。每个租户的容量仍然不同，所以我们仍然会有一些大的分区和一些小的分区。但是差异不会像我们每个租户有一个分区时那么严重。

使用“每个租户一个分区”策略，典型的查询如下所示：

partitionKey=/ownerID

select c.id,c.callTime,c.direction,c.action,c.result,c.duration,c.hasR,c.hasV,c.callers
from c
where
ownerId='2458671015'
and c.callTime>='2020-01-01T00:00:00 +000'
and c.callTime<='2020-08-31T23:59:59 +000'
and (CONTAINS(c.phoneNums_s, 'rus')
or CONTAINS(c.names_s, 'rus')
or CONTAINS(c.xNums_s, 'rus'))
order by c.callTime desc

select c.id,c.callTime,c.direction,c.action,c.result,c.duration,c.hasR,c.hasV,c.callers
from c
where array_contains([
 '2458671015_202001',
 '2458671015_202002',
 '2458671015_202003',
 '2458671015_202004',
 '2458671015_202005',
 '2458671015_202006',
 '2458671015_202007',
 '2458671015_202008'], c.ownerTime)
and c.callTime>='2020-01-01T00:00:00 +000'
and c.callTime<='2020-08-31T23:59:59 +000'
and (CONTAINS(c.phoneNums_s, 'rus')
or CONTAINS(c.names_s, 'rus')
or CONTAINS(c.xNums_s, 'rus'))
order by c.callTime desc

似乎ownertime策略是更好的选择，只要所有查询都包含日期范围。但我想得到一些关于这个策略的反馈。它并不完美，但似乎工作得很好。我来自SQL背景，这是我第一次实现文档数据库。我这样做是为了利用改进的文本搜索和可伸缩性。使用ownertime分区策略，我将来可能会遇到“gotcha”吗？根据我提供的信息，是否有更好的分区策略？

Answer 1

有界跨分区查询肯定比无界查询要好得多，所以根据您在这里的问题中所包含的内容，我同意包含time元素来创建合成分区键是一个很好的分区策略。

这里没有解释的是，是否有其他高容量运行的查询在过滤器谓词中不包括时间（或ownerId）？如果是这样，则需要使用Change Feed将第一个数据容器中的数据复制到第二个容器中并保持同步，该容器具有对这些查询也有意义的分区键。

另外一个选择是启用分析存储并使用Synapse Link，然后对数据编写Spark（很快还有SQL Serverless）查询，特别是如果您希望对这些数据进行分析的话。