azure - 在迭代数组 cosmos db 之前过滤分区键

Question

我有一个 CosmosDbQuery 工作正常，但有点慢且昂贵:

SELECT c.actionType as actionType, count(1) as count 
FROM c in t.processList
WHERE c.processTimestamp > @from
GROUP BY c.actionType

为了优化我的查询，我想首先在我的父分区Key上有一个Where子句，例如在迭代进程列表之前，parent.month > x。在此之后，不需要 c.processTimestamp > @from。

"id": "b6fd10cc-3a0b-4666-bf55-f22436a5f8d9",
"Name": "xxx",
"Age": 1,
"minute": 202302021026,
"processList": [
   {
      "processTimestamp": "2023-02-01T10:28:48.3004825Z",
      "actionType": "Action1",
      "oldValue": "2/1/2023 10:28:41 AM",
      "newValue": "2/1/2023 10:28:48 AM"
   },
   {
      "processTimestamp": "2023-02-01T10:28:48.3004825Z",
      "actionType": "Action2",
      "oldValue": "2/1/2023 10:28:48 AM",
      "newValue": "2/1/2023 10:28:48 AM"
   }],
}

我尝试过子查询和连接，但无法让它工作:

SELECT c.actionType as actionType, count(1) as count 
FROM (SELECT * FROM C WHERE c.minute > 9) in t.processList
WHERE c.processTimestamp > @from
GROUP BY c.actionType")

我想要的结果是:

[
    {
        "actionType": "action1",
        "count": 85351
    },
    {
        "actionType": "action2",
        "count": 2354
    }
]

Answer 1

这里有一些评论。

正如我的评论中所述，不支持带有子查询的 Group By，documented here .

使用日期/时间值作为分区键通常是 Cosmos DB 的反模式。此查询可能缓慢且昂贵，因为在大规模情况下，使用时间作为分区键意味着由于数据新近性(较新的数据比旧数据获得更多的请求)，大多数查询都会命中同一分区。出于同样的原因，这也不利于写入。

发生这种情况时，通常会增加吞吐量。然而，这通常没有什么帮助，在某些情况下甚至会使事情变得更糟。此外，由于吞吐量均匀分布在所有分区上，这会导致旧日期的分区键上未使用的吞吐量被浪费。

有两件事需要考虑。将分区键设置为两个属性的组合以增加基数。在 IOT 场景中，这通常是 deviceId_dateTime ( Hierarchical Partition keys ，现在处于预览状态，是您现在可以执行此操作的更好方法)。这将有助于写入，特别是在数据始终使用当前日期时间写入的情况下。

在查询的读取路径上，您可以探索使用“更改源”到第二个容器中来实现物化 View 。这将移动用于摄取的容器的读取吞吐量，并可以提高吞吐量的使用效率。但是，您应该亲自测量一下才能确定。

如果您的容器很小并且始终保持这种状态，则以下信息将不适用(< 10K RU/s 和 50GB)。然而，这样的设计无法扩展。