我们的Azure Cosmos数据库集合已经足够大，需要分区密钥 . 在做一些阅读时，我得到的印象是最好的分区键是提供均匀分布和更高基数的键 . 来自Microsoft的This article讨论了它 .
使用主键作为分区键提供均匀分布，但基数只有1.如果这是我唯一的选择，这是一件坏事吗？前面提到的文章提供了一些examples，似乎表明主键应该在这些实例中用作分区键 . 对于Azure Cosmos DB，分区是逻辑的，而不是物理的 . 因此，它不会导致将每个文档放在自己的磁盘上，但似乎它可能导致膨胀的索引 .
使用主键作为分区键是一种常见的做法吗？它有什么缺点吗？
3 回答
不，它没有任何缺点 . 力争拥有高基数的分区键 . 不要担心索引或物理分区等 .
您可以拥有数百万个分区键和10个物理分区 . 物理分区由CosmosDB在场景后面创建 . 你永远不应该担心物理分区 .
实际上，分区键的选择是一个值得重复权衡的问题 . 由于选择主键作为分区键是您唯一的选择，我只讨论一些可能的负面因素作为您的参考 .
在性能方面，如果您的查询字段不是分区键，您的查询肯定会通过跨越分区来降低查询性能 . 当然，如果数据量很小，则不会产生太大影响 .
在成本方面，cosmos db主要由存储空间和RU消耗来收费 . 正如您所说，选择主键作为分区键将导致更多的索引存储 . 如果大多数查询是跨分区的，那么它也会导致更多的RU消耗 .
在使用存储过程，触发器或UDF方面，您不能通过存储过程和触发器使用跨分区事务 . 因为然后进行分区，以便在使用它们时需要指定分区键（基数只有1） .
请注意，如果创建了分区键，则以后无法删除或修改它 . 因此，在选择之前请考虑它，并确保进行数据备份 .
更多细节，仍然参考official doc .
希望它能帮到你 .
您可以说主键是分区键的最安全且可能最合适的选择 .
它保证了值的唯一性，除了唯一键之外，它是唯一的实现方式 . 分发将是均匀的，因为主键将是您的分区键，您将能够使用它来通过读取来检索文档，而不是查询，这降低了操作速度和成本 .