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跨分区查询策略

回答

相关问题