在 CosmosDb 中使用 /id 作为分区键的含义
在每分钟有1000个条目(惟一键)进入cosmos的场景中，使用/id作为分区键安全吗？
特别是，有逻辑分区的概念https://docs.microsoft.com/en-us/azure/cosmos-db/partition-data这里的图形让我有点害怕，显示逻辑分区是实际实体（例如“城市”：“伦敦”）。如果我有一个8小时的TTL和每分钟1000个条目，我不一定需要cosmos需要管理的48万个逻辑分区。
我想象发生的是分区键的值只是简单地散列并与物理分区的数量模数，例如。https://docs.microsoft.com/en-us/azure/cosmos-db/partitioning-overview#choose-partitionkey表明这在“逻辑分区管理”部分是正确的。此外，“选择分区键”部分建议（但实际上并未说明） /id将是一个奇妙的分区键，因为它不必担心10GB限制、吞吐量限制、没有热点、宽（大）范围的值，并且由于应用程序不需要过滤除id之外的任何内容，因此跨分区查询对于这个用例来说不会是一个问题。
综上，我需要担心几十万个分区键值(逻辑分区)的内存/CPU/etc开销吗？文档表明分区键的值越多越好，但是没有说明是否可能有太多的值。
共有2个答案
影响是：
>
轻松
没有事务，因为事务范围是分区键
PS。我很难想象除了id读取/查询之外不需要任何东西的情况。除了文档缓存（与TTL结合）。
我来自Cosmos DB工程团队。
您不必担心在Cosmos DB集合/容器上创建的逻辑分区键的数量。只要分区键是适合您的写操作(每个逻辑分区键上限为10GB)和查询的选择，您就应该做得很好。
-
null 关于如何管理分区密钥的依赖关系，您有什么建议吗？或者我没有根据cosmosdb最佳实践以最佳方式对数据层建模？
-
问题内容： 我创建了一个使用@Id指向@Embeddable复合键的实体。我认为一切正常。但是，据我所知，在将@Id切换为@EmbeddedId之后，一切仍然可以正常工作。 之前： 后： 引用复合键时，使用@Id和@EmbeddedId批注之间有区别吗？ 问题答案： 实际上，我对 “之前” 版本的工作感到惊讶。根据规范，映射您的复合键的正确方法是 “之后” 版本。引用JPA 1.0规范： 2.1.
-
我正在用单个主题和多个分区实现kafka producer。我通过消息中的一个特定值（消息json中的feedName属性值）选择消息到哪个分区。我正在为feedName-partitionId映射维护一个SQL表。我的问题是，leader和副本的分区Id是否相同？如果不同，如何在所有代理中唯一地标识分区？
-
问题内容： 我需要将GUID / UUID作为行的ID列。 这是为了能够在线和离线创建条目，并且合并时当然不会在PK上存在这些冲突。我知道我可以缓解这种情况，但是我想保持简单，并且已有一些遗留应用程序已经在使用uuid / guid定义关系。以后还需要双向同步数据。重写现有应用程序不是一种选择。 当我尝试在grails上使用GUID或UUID时，出现错误500。（在h2上使用GUID会导致另一个错
-
在幕后，Azure Cosmos DB提供了服务T请求/S所需的分区。如果T高于每个分区的最大吞吐量T，那么Azure Cosmos DB提供N=T/T分区。