我们的Azure Cosmos DB集合已经变得足够大，需要一个分区密钥。在阅读这篇文章时，我得到的印象是，最好的分区键是提供均匀分布和更高基数的分区键。这篇来自微软的文章讨论了它。
使用主键作为分区键可以实现均匀分布，但基数仅为1。如果这是我唯一的选择，这是一件坏事吗？前面提到的文章给出了几个例子，似乎表明主键应该在这些情况下用作分区键。在Azure Cosmos DB的情况下，分区是逻辑的，而不是物理的。因此，这不会导致每个文档都在自己的磁盘上，但似乎会导致索引膨胀。
使用主键作为分区键是一种常见的做法吗？它有什么缺点吗？
实际上，分区键的选择是一个需要反复权衡的问题。由于选择主键作为分区键是您唯一的选择，所以我只讨论一些可能的负面因素作为您的参考。
就性能而言，如果查询的字段不是分区键，那么查询肯定会通过跨分区来降低查询性能。可以说，如果数据量很小，就不会产生多大影响。
就成本而言，cosmos db主要由存储空间和RU消耗来收费。正如您所说，选择主键作为分区键将带来更多的索引存储。如果大多数查询都是跨分区的，那么也会导致更多的RU消耗。
在使用存储过程、触发器或UDF方面，不能通过存储过程和触发器使用跨分区事务。因为然后是分区的，所以在使用它们时需要指定分区键(基数只有1)。
只需注意，如果创建了分区键，以后就不能删除或修改它。因此，在选择之前要考虑一下，并确保进行数据备份。
更多详细信息，请参阅官方文档。
不，它没有缺点。努力拥有具有高基数的分区键。不要担心索引或物理分区等
您可以拥有数百万个分区键和10个物理分区。物理分区由CosmosDB在场景后面创建。您永远不应该担心物理分区。
可以说主键是分区键最安全、可能也是最合适的选择。
它保证了值的唯一性，而不是唯一的键，这是唯一的实现方式。分发将是均匀的，因为主键将是您的分区键，您将能够使用它通过读取文档来检索文档，而不是查询，这降低了操作速度和成本。
我认为MS在描述如何最好地确定Cosmos DB的分区密钥方面做得不好，尤其是当人们通常建议使用数据库的主键作为分区密钥时(这可能是完全可以接受的有时，但我看不出这是正常的)。
在最近的一个项目中，这就是我们决定为系统中的对象标识分区键和项id的方式。我认为这将适用于许多在其对象上具有自然复合主键候选者的系统。
在我们的系统中，每个对象都被限制为一个状态(StateCode)和供应商(VendorId)。从那里，我们有多个实体，如销售订单、客户、小工具。。。在我们的SQL Server实现中，每个表都有一个明显的自然复合主键StateCode、VendorId、EntityId。在Cosmos DB场景中，我们选择Partition Key为StateCode Vendor EntityType，Item Id为EntityId。这允许在一个分区内查询特定类型的所有实体(保存RU)，同时仍然允许在该分区内进行非常简单的查询(例如，同质实体)。您最终以这种方式使用了复合自然键的所有部分，但允许实体的实际分区。
在更复杂的场景中，如果我们想跨实体查询给定供应商，我们可以从分区键中删除EntityType，然后将其移动到项id中，或者使用它来过滤要搜索的对象。这允许在分区内进行跨实体查询，但由于异构实体，查询本身稍微复杂一些。
如果实体的整个ID都在Partition Key中，那么你几乎必须始终单独查找项目，或者在不按ID查找时搜索每个分区——在这一点上，如果你必须搜索所有分区，谁在乎你的数据在分区之间的分布有多均匀。
也许OP可以描述更多关于实体的信息——它们是否有自然的复合关键字候选者(无论它们是否在SQL实现中使用)？如果不是，当前的持久层在通过某个id标识系统中的项目方面是什么样子的？