说我有:
以下是我的问题:
发布于 2016-08-17 18:04:31
您所描述的是一个合理的解决方案,可以很好地避免跨分区的数据倾斜和负载平衡。由于对特定租户的查询需要触及所有分区,所以请记住将FeedOptions.EnableCrossPartitionQuery设置为true ( REST中的x documentdb- query -enablecrosspartition分区)。
DocumentDB站点还有一篇关于分区集合的优秀文章,以及一般选择分区键的技巧。https://azure.microsoft.com/en-us/documentation/articles/documentdb-partition-data/
发布于 2016-08-17 19:58:57
我会避免跨分区的查询,它们会带来相当大的代价(基本上将索引和解析成本与分区的数量相乘--默认为25个)。很容易试一试。
我更喜欢可以查询特定分区的解决方案,通常是通过承租者ID进行分区。
请记住,对于分区集合,每个分区仍有限制(10KRU和10GB) --我已经在这里写过了http://blog.ulriksen.net/notes-on-documentdb-partitioning/
发布于 2016-08-17 20:09:35
这取决于您的使用模式以及租户大小的变化。
一般来说,在多租户系统中,99%的操作是在单个租户内进行的.如果您将tenantID作为分区键,那么这些操作只会触及单个分区。这不会使单个操作变得更快(延迟),但是当多个租户加载时,可以提供巨大的吞吐量增益。但是,如果您只有5个租户,其中一个是所有租户的10倍,那么使用tenantID作为您的密钥将导致一个非常不平衡的系统。
我们使用tenantID作为系统的分区密钥,而且它似乎工作得很好。我们已经讨论过,如果它变得非常不平衡,我们会做什么,其中一个想法是将分区键变成tenantID +来将大租户分开。虽然我们还没有做到这一点,所以我们还没有想出所有的细节来知道这是否真的是可能的和有表现力的,但我们认为它会奏效。
https://stackoverflow.com/questions/39001680
复制相似问题