CosmosDb 搜索索引与分区键

Question

默认情况下，在 cosmosDb 中，文档中的所有属性都会建立索引，那么为什么我要关心分区键的研究，而索引搜索也可以完美地工作并且不需要任何成本？

我有一个包含一百万个这样的文档的cosmosDb，每个文档都包含一个数组，分区键是“tankId”，例如：

{
    "id": "67acdb16-80dd-4a6c-a5b0-118d5f5fdb97",
    "tankId": "67acdb16-80dd-4a6c-a5b0-118d5f5fdb97"
    "UserIds": [
        "905336a5-bf96-444f-bb11-3eedb65c3760",
        "432270f5-780f-401b-9772-72ec96166be1",
        "cfecdf7e-5067-46b1-ab4e-25ca7d597248"
    ],
}

如果我对这百万个文档执行“UserIds”请求（不是分区键而是索引属性），则只需要 3.32 RU！哇。

SELECT *
FROM c 
WHERE ARRAY_CONTAINS(c.UserIds, "905336a5-bf96-444f-bb11-3eedb65c3760")

提出这种请求是一个好的做法吗？我对我的设计有点担心。

Answer 1

一旦物理分区的数量开始增长，它就开始变得重要了。使用分区键将允许 Cosmos 将查询映射到驻留在物理分区中的逻辑分区。因此，查询不会是所谓的“跨分区查询”，并且不必检查其他物理分区的索引（这也会消耗 RU）。

在您的情况下，您正在谈论一百万个文档，这些文档可能使用远小于 50GB 的数据（物理分区的最大大小），因此它们全部存储在同一个物理分区中。因此，您不会对 RU 使用产生任何明显的影响。

因此，要回答您是否应该做出任何改变的根本问题。您的数据库读量大吗？您有经常用于查询的属性吗？您确信您的分区保持在逻辑分区大小限制 (20GB) 以内吗？如果是，那么您应该在设计中考虑它。即使如此，只有当您的数据开始在物理分区中分割时，这才有意义。