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 将查询映射到驻留在物理分区中的逻辑分区。因此，查询不会是所谓的 'cross-partition query'，也不必检查其他物理分区的索引（这也会消耗 RU）。

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

因此，为了回答您的基本问题，您是否应该进行任何更改。您的数据库主要是读取量大吗？有没有经常用来查询的属性？您确定您的分区保持在逻辑分区大小限制 (20GB) 以下吗？如果是，那么您应该在设计中考虑它。即便如此，只有当您的数据开始在物理分区中拆分时，它才会变得重要。

CosmosDb 搜索索引与分区键

CosmosDb search on the Index vs partition Key

azure

azure-cosmosdb

azure-cosmosdb-sqlapi