在每分钟有 1000 个条目（唯一键）进入 cosmos 的场景中，使用 /id 作为分区键安全吗？
特别是，有一个逻辑分区的概念https://learn.microsoft.com/en-us/azure/cosmos-db/partition-data https://learn.microsoft.com/en-us/azure/cosmos-db/partition-data这里的图形让我有点害怕，显示逻辑分区是实际的实体（例如“城市”：“伦敦”）。如果我有 8 小时 TTL 和每分钟 1000 个条目，我不一定需要 Cosmos 需要管理的 480,000 个逻辑分区。
我想象的情况是，分区键的值简单地散列并与物理分区的数量取模，例如。https://learn.microsoft.com/en-us/azure/cosmos-db/partitioning-overview#choose-partitionkey https://learn.microsoft.com/en-us/azure/cosmos-db/partitioning-overview#choose-partitionkey在“逻辑分区管理”部分中表明这是正确的。此外，“选择分区键”部分建议（但实际上并未说明）/id 将是一个很棒的分区键，因为它不必担心 10GB 限制、吞吐量限制、无热点、宽（巨大）的值范围，并且由于应用程序不需要过滤除 id 之外的任何内容，因此跨分区查询不会成为此用例的问题。
综上所述，我是否需要担心数十万个分区键值（逻辑分区）的内存/CPU/等开销？文档表明分区键的值越多越好，但没有说明是否可能有太多值。
我来自 Cosmos DB 工程团队。
您不必担心在 Cosmos DB 集合/容器上创建的逻辑分区键的数量。只要分区键适合您的写入（每个逻辑分区键的上限为 10GB）和查询，您就应该没问题。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
