DocumentDB的分區鍵

我有一個關於DocumentDB分區鍵選擇的問題。我有UserId，DeviceId和WhateverId的數據。 UserId參數總是在查詢中，所以我選擇了UserId作爲分區鍵。但是我爲一個用戶（數百萬個實體）提供了大量數據，當我使用指定的分區密鑰進行"SELECT * FROM c WHERE c.DeviceId = @DeviceId"這樣的quety時，需要很多時間（大約22萬個返回實體大約需要6分鐘）。也許選擇例如DeviceId作爲分區鍵並針對幾個分區並行查詢（指定EnableCrossPartitionQuery = true並且MaxDegreeOfParallelism =分區數）會更有效？或者對每個用戶使用單獨的集合是一個好主意？DocumentDB的分區鍵

來源

2016-11-03 Paval

這並不是說這個回答你的問題，但是......我想任何時候你試圖檢索一個25萬的實體，你可能想重新考慮你的數據訪問模式。另外，「'SELECT *'」是另一種代碼味道。如果您試圖將大量數據移動到您的應用程序層，我看不出分區鍵的選擇如何產生影響。 –

謝謝。 'SELECT *'只是一個簡單的例子，對不起。我將使用'SELECT c.Value'。而這個問題只是關於選擇分區鍵，因爲azure文檔站點上的信息與我有點抽象。所有這些測量僅用於根據查詢進行性能比較。 – Paval

它可能會有所幫助，但我不認爲每個用戶的分區都能解決您的問題，因爲您基本上已經擁有了該分區。

您可以嘗試使用分區鍵來改善parrallism，但充其量只會讓您的體驗倍增2倍至5倍。夠了嗎？

對於更顯着的改進，您通常不得不採用選擇性非規範化和/或緩存。

來源

2016-11-03 10:42:01

我已經將分區密鑰更改爲DeviceId，並試圖使查詢像'SELECT c.Value FROM c WHERE c.UserId = @userId和c.WhateverId = @ WhateverId'。 19845個退貨實體花費了4.6。那沒問題。但是，當我試圖用分區鍵查詢時，例如'SELECT c.Value FROM c WHERE c.UserId = @userId和c.DeviceId = @ DeviceId'，大概相同數量的返回實體花費了大約27秒。這並不好，因爲使用DeviceId的查詢更頻繁。我知道這是因爲當我們指定分區鍵時沒有並行性。我應該考慮另一個pk – Paval

關鍵是你必須不斷嘗試。不要忘記在您的實驗中包含索引調整。數據前3個字節的默認索引鍵。如果這個變化不夠，你可能會有一個索引熱點。 –

你的意思是說，如果我有很多鍵以相同的字符開始，就會發生。 – Paval

我知道這是有點老了，但對於其他人來到這個話題的利益......

從你的描述我認爲這些設備大多是用戶唯一的。通常建議對像userid這樣的東西進行分區，如果你有一個呼叫中心應用程序，那麼這個分區是很好的，對於給定的用戶標識有許多查詢，並且只想查找不超過幾百個條目。在這種情況下，可以從單個分區快速提取數據，而無需跨分區整理數據。但是，如果用戶擁有數百萬條記錄，那麼在用戶標識上進行分區可能是最糟糕的選擇，因爲從單個分區提取大量數據將很快超過排序開銷。在這種情況下，您希望儘可能均勻地在所有分區上分配用戶數據。除非每個用戶擁有25個以上使用類似的設備，否則設備ID可能不是一個好選擇。

在諸如您的情況下，我通常會發現系統生成的增量鍵（例如事件ID或事務ID）是最佳選擇。

來源

2017-06-22 06:50:33

DocumentDB的分區鍵

回答

相關問題