DocumentDB的分区键

Question

我有一个关于DocumentDB分区键选择的问题。 我有UserId，DeviceId和WhateverId的数据。 UserId参数总是在查询中，所以我选择了UserId作为分区键。但是我为一个用户（数百万个实体）提供了大量数据，当我使用指定了分区键的"SELECT * FROM c WHERE c.DeviceId = @DeviceId"进行了类似的操作时，需要花费大量时间（大约220,000个返回实体大约需要6分钟）。 也许选择例如DeviceId作为分区键并对并行的几个分区进行查询会更有效 （指定EnableCrossPartitionQuery = true和MaxDegreeOfParallelism =分区计数）？ 或者也许为每个用户使用单独的集合是个好主意？

Answer 1

它可能会有所帮助，但我认为每个用户的分区都不会解决您的问题，因为您基本上已经掌握了这个问题。

您可以尝试使用分区键来改善并行性，但最多可以使我的体验提高2到5倍。那够了吗？

对于更显着的改进，您通常不得不求助于选择性非规范化和/或缓存。

Answer 2

我知道这有点老了，但为了其他人的利益而来到这个话题......

根据您的描述，我假设这些设备对用户来说几乎是唯一的。通常建议对像userid这样的东西进行分区，如果你有一个很好的话，比如呼叫中心应用程序，对给定的用户ID有很多查询，并且想查找不超过几百个条目。在这种情况下，可以从单个分区快速提取数据，而无需跨分区整理数据。但是，如果您有数百万条用户记录，那么在User Id上进行分区可能是最糟糕的选择，因为从单个分区中提取大量数据很快就会超出整理的开销。在这种情况下，您希望在所有分区上尽可能均匀地分发用户数据。除非每个用户拥有25个具有相似用途的设备，否则设备ID可能也不是一个好选择。

在像你这样的情况下，我通常会发现系统生成的递增密钥（例如事件ID或事务ID）是最佳选择。