DocumentDb跨分區查詢策略

https://docs.microsoft.com/en-us/azure/cosmos-db/partition-data

A）我應該構建我的分區鍵，以便我的查詢（最好）在一個分區結束？例如。 PartitionKey =客戶編號

B）文件是否仍處理能夠有效地跨越多個（許多）分區查詢？例如。 PartitionKey =「客戶ID + CONTEXTNAME +類型名」

目前，我們有「A」的實施，但已經討論了，因爲文章的「B」有這句話在它：

它是有一個最佳實踐一個具有許多不同值（至少爲100s-1000s）的分區鍵。

強調「至少」。我們的客戶ID將不會產生超過2-300個分區密鑰。我們應該增加更多的信息，它（「B」），知道一個查詢可打30-50分區（即「TYPEID」除了明確）

SELECT * FROM c 
WHERE(MyPartition = "1+ContextA+TypeA" 
    OR MyPartition = "1+ContextA+TypeB" 
    OR MyPartition = "1+ContextA+TypeC" 
    ...) 
    AND <some other conditions>

在文章中展示的場景似乎假定客戶或用戶會產生大量的密鑰。這對我們來說不會是真的。

來源

2017-08-08 TBone

請參閱[文檔]（https://azure.microsoft.com/zh-cn/blog/10-things-to-know-about-documentdb-partitioned-collections/）以獲取有關Azure的更多信息documentDB。從文檔中，我們可以知道哪些數據存儲在同一個分區中，以及如何選擇正確的分區密鑰屬性 –

@TomSun - 感謝您的鏈接。我已閱讀該文件。我可以通過多種方式區分我的數據。它似乎沒有回答以下基本問題：我的分區是否應該設計爲使我的查詢以單個分區爲目標，還是跨多個分區查詢仍然表現良好？ – TBone

Docdb Sdk在運行交叉分區查詢時進行並行調用。如果您檢查網絡流量，您會注意到它首先查詢物理分區鍵範圍，然後分別調用每個分區鍵範圍。它確實是並行，並且允許控制maxdegreeofparallelism等

話雖如此，有兩個方面需要考慮：

的數據量

如果卷就是說1 TB，這意味着它需要至少100個物理分區（每個分區爲10 GB），因此它會創建至少100個呼叫。如果您的數據量增長較多，撥打更多電話可能會影響性能。

查詢聚集

如果使用聚合，目前由商務部DB SUM/AVG/COUNT /最小/最大支持。這些不能跨分區執行。

來源

2017-08-15 00:17:03 KranthiKiran

DocumentDb跨分區查詢策略

回答

相關問題