为什么分区 DocumentDB 集合中总是存在“往返”？

Question

我正在向分区 DocumentDB 集合发出如下请求。集合已分区以备将来使用，但此时分区键只有一个值。

{ "query": "SELECT * FROM r where r.id = @id", "parameters": [ {"name": "@id", "value": "4a97b4fe-cbf7-4e7c-be50-e90d3ce7bc14"} ] }

第一页返回空白，其中一些x-ms-continuation 为#PKRID:1。当我浏览下一页指定不同的 x-ms-continuation 标头时，最终正确的正文会在 #PKRID:16 （第 16 页）附近返回。这似乎在 DocumentDB 门户中称为“往返”，因为每次分页都需要网络往返。

问题：

1. 这是正常行为吗？该查询指定了“id”，因此我认为它应该能够立即从索引中获取记录。如果我没记错的话，当我将集合作为单个分区时，它确实在第一页得到了结果。

2. 如果它（不幸地）是 DocumentDB 的正常行为，我可以做些什么来减轻往返效应？将x-ms-max-item-count 指定为像 1000 这样的大数字没有任何效果。同样的记录仍在第 16 页返回。 （事实上​​，这个集合中的每条记录似乎都在第 16 页返回......）

作为补充信息，索引策略是这样的：

{ "indexingMode": "consistent", "automatic": true, "includedPaths": [ { "path": "/*", "indexes": [ { "kind": "Range", "dataType": "Number", "precision": -1 }, { "kind": "Range", "dataType": "String", "precision": -1 }, { "kind": "Spatial", "dataType": "Point" } ] } ], "excludedPaths": [] }

Answer 1

在 DocumentDB 中，过滤分区键的查询将在单个跃点/分区中执行，但没有分区键过滤的查询将在每个分区上执行（在每个分区内，查询命中索引)。

请注意，在分区集合中，文档的“主键”是 (, “id”) 的复合属性，而不仅仅是“id”。例如，如果您的分区键是“appName”，那么您应该过滤“appName = X”以执行单跳查询。对“appName = X and id = Y”的查询是主键查找。

另请注意，使用 SDK 1.9.0+，DocumentDB 支持跨分区查询的并行执行。即使查询没有分区键上的过滤器，并行查询执行也允许您以非常低的延迟执行查询。