我发布了一个像下面这样的请求来分区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门户网站中被称为“往返”,因为每个分页都需要网络往返。
问题:
这是正常行为吗?查询是指定“id”,所以它应该能够从索引瞬间获取记录,我想。如果我没记错的话,当我把这个集合作为单个分区时,它确实在第一页得到了结果。
如果(不幸的话)是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": []
}
答案 0 :(得分:3)
在DocumentDB中,过滤分区键的查询将在单个跃点/分区中执行,但在每个分区上执行不具有分区键过滤器的查询(在每个分区内,查询命中索引)。
请注意,在分区集合中,"主键"对于文档而言,是(," id")的复合属性,而不仅仅是" id"。例如,如果您的分区键是" appName",那么您应该过滤" appName = X"用于单跳查询执行。对" appName = X和id = Y"的查询是主键查找。
另请注意,使用SDK 1.9.0(预览版),DocumentDB支持并行执行跨分区查询。即使查询在分区键上没有过滤器,并行查询执行也允许您以非常低的延迟执行查询。请发送电子邮件至askdocdb@microsoft.com进行预览访问。