我有一个关于DocumentDB分区键选择的问题 . 我有UserId，DeviceId和WhateverId的数据 . UserId参数总是在查询中，所以我选择了UserId作为分区键 . 但是我为一个用户（数百万个实体）提供了大量数据，并且当我使用指定分区键的 "SELECT * FROM c WHERE c.DeviceId = @DeviceId" 进行了类似操作时，需要花费大量时间（大约220,000个返回实体大约需要6分钟） . 选择DeviceId作为分区键并对并行的几个分区进行查询（指定EnableCrossPartitionQuery = true和MaxDegreeOfParallelism =分区计数）可能更有效率？或者也许为每个用户使用单独的集合是个好主意？
2 回答
它可能会有所帮助但我认为每个用户的分区都不会解决您的问题，因为您基本上已经掌握了这个问题 .
您可以尝试使用分区键来改善并行性，但最多可以使我的体验提高2到5倍 . 够了吗？
对于更显着的改进，您通常不得不求助于选择性非规范化和/或缓存 .
我知道这有点旧，但是为了其他人的利益来到这个话题......
根据您的描述，我假设这些设备对用户来说几乎是唯一的 . 通常建议对像userid这样的东西进行分区，如果你有一个很好的话，比如呼叫中心应用程序，对给定的用户ID有很多查询，并且想查找不超过几百个条目 . 在这种情况下，可以从单个分区快速提取数据，而无需跨分区整理数据 . 但是，如果您有数百万条用户记录，那么在User Id上进行分区可能是最糟糕的选择，因为从单个分区中提取大量数据很快就会超出整理的开销 . 在这种情况下，您希望在所有分区上尽可能均匀地分发用户数据 . 除非每个用户有25个具有相似用途的设备，否则设备ID可能也不是一个好的选择 .
在像你这样的情况下，我通常会发现系统生成的递增密钥（例如事件ID或事务ID）是最佳选择 .