好吧,因此CosmosDb Collection將其索引策略設置爲一致,自動,默認散列和範圍索引和我們在自己的時間戳屬性中添加了一個路徑爲了排序他們。Azure Cosmos Document DB中的自定義索引不起作用
我知道這些路徑是正確的,因爲我無法按它們排序,除非我讓它們設置。但是:
當內置屬性_TS宇宙排序 - 爲排序依據查詢的成本是一樣20 RU/s的。那很棒。 現在,我們OWN時間戳列排序時(我們有兩個,其中一個是一個字符串時間戳,另一個是Unixbased數一樣內置_TS列。 這個查詢費400 RU /小號!???
啓用新的索引規則使我們能夠查詢和訂購,但個RU是瘋了。這是爲什麼?我們如何解決這個問題?
我知道你無法更改索引pol冰冷的Ad Hoc早些時候,但這已經根據微軟解決。
編輯:它是一個簡單集合,沒有分割構造,並且查詢執行鍼對此僅收集,只選擇一個文件(頂部1)。
SELECT top 1 * FROM c WHERE c.AllCompleted = true ORDER BY c.EndFetchDateTimeUtcUnix DESC
VS
SELECT top 1 * FROM c WHERE c.AllCompleted = true ORDER BY c._ts DESC
指數看起來像這樣: { "indexingMode": "consistent", "automatic": true, "includedPaths": [ { "path": "/", "indexes": [ { "kind": "Hash", "dataType": "Number", "precision": 3 }, { "kind": "Hash", "dataType": "String", "precision": 3 } ] }, { "path": "/EndFetchDateTimeUtcUnix/?", "indexes": [ { "kind": "Range", "dataType": "Number", "precision": -1 }, { "kind": "Hash", "dataType": "String", "precision": 3 } ] } ], "excludedPaths": [] }
您是否可以包含更多信息,包括自定義查詢返回的文檔數與_ts的順序以及此查詢是否限於單個分區? –
當然,它只有一個。用上述查詢和索引編輯上面的帖子。 – imbageek