爲什麼分區DocumentDB集合中總會有「往返」？

我正在向分區DocumentDB集合發出如下所示的請求。該集合是爲未來目的而分區的，但此時分區鍵只有單一值。爲什麼分區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標題的下一頁時，最終正確的身體將返回（第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": [] }

來源

2016-06-21 barley

在DocumentDB中，對分區鍵進行篩選的查詢將在單個躍點/分區中執行，但對每個分區（每個分區內的查詢都會觸發索引）在每個分區上執行沒有分區鍵篩選器的查詢。

請注意，在分區集合中，文檔的「主鍵」是（，「id」）的複合屬性，而不僅僅是「id」。例如，如果您的分區鍵是「appName」，那麼您應該在「appName = X」上過濾單跳查詢執行。關於「appName = X和id = Y」的查詢是主鍵查找。

另請注意，使用SDK 1.9.0（預覽中），DocumentDB支持並行執行交叉分區查詢。即使查詢在分區鍵上沒有過濾器，並行查詢執行也允許您以非常低的延遲執行查詢。請通過電子郵件[email protected]預覽訪問權限。

來源

2016-06-21 14:35:51

爲什麼分區DocumentDB集合中總會有「往返」？

回答

相關問題