我们有一个Cosmos DB Collection，包含大约100万个包含用户信息的文档 . 每天添加或更新的次数不多 . 但是，我们需要非常高的读取吞吐量 .
大多数查询都基于UserId . UserId属性是一个由运行数和校验位组成的数值 .
根据官方文档
有人可能认为 both ，完整的UserId和UserId的子字符串（假设最后4位数字）可以成为一个好的分区键，即
-
均匀分配请求和存储
-
查询可以"efficiently?"路由到相应的分区
-
提供高基数
将来，我们_1186378_每个UserId有多个文档，但假设不超过5个 .
我的理解是，还希望在分区数量和每个分区的文档数量之间取得 balancer . 因此，在100万个分区中每个分区具有1个文档也是不理想的 . 但是，在此SO thread上，Microsoft工程师建议使用完整的唯一标识符作为分区键 . （值得注意的是，我们的情况略有不同，因为这里UserId是一个运行数字而不是随机GUID） . 此外，在this blog post的注释中，还建议使用ID作为分区键 .
所以，考虑到：a）这个集合主要用于读取操作，b）我们将有100到200万个UserIds，c）每个UserId我们不会有超过5个文档，d）我们没有跨多个用户的SP或交易的要求 . 什么分区键会更高效？
-
完整的UserId
-
UserId的子字符串（例如，最后4位数）
1 回答
基于@ RafatSarosh的评论和进一步研究，我了解到每个分区拥有数百万个分区和1个文档并不是一个坏习惯，我们可以依靠Cosmos DB查询执行优化 .
我们将使用userId作为分区键 .
HTH