我们正在使用 Cosmos DB SQL API，这是一个集合 XYZ，其中包含：
尺寸：无限制
吞吐量：50000 RU/s
PartitionKey：散列
我们将插入 200,000 条记录，每条记录的大小约为 2.1 KB，并且分区键列的值相同。据我们所知，所有具有相同分区键值的文档都存储在同一个逻辑分区中，无论我们是在固定大小的集合还是无限大小的集合中，逻辑分区都不应超过 10 GB 的限制。
显然，我们的总数据甚至不到 0.5 GB。但是，在 Azure Cosmos DB（在门户中）的指标刀片中，它说：
集合 XYZ 有 5 个分区键范围。预置吞吐量为 均匀分布在这些分区中（每个分区 10000 RU/s）。
这与我们迄今为止从 MSFT 文档中研究的内容不匹配。我们错过了什么吗？为什么要创建这 5 个分区？
【问题讨论】：
标签： azure-cosmosdb partitioning azure-cosmosdb-sqlapi
当使用Unlimited 集合大小时，默认情况下您将被预置 5 个物理 分区键范围。此数字可以更改，但截至 2018 年 5 月，默认值为 5。您可以将每个物理分区视为“服务器”。因此，您的数据将分布在 5 个物理“服务器”中。随着数据大小的增长，您的数据将自动重新分配到更多物理分区。这就是为什么在您的设计中预先设置正确的分区键是如此重要。
对于所有 200k 记录具有相同分区键 (PK) 的方案中的问题是您将有热点。您有 5 个物理“服务器”，但只有一个会被使用。其他 4 个将闲置，结果是相同价位的性能会降低。您支付 50k RU/s 的费用，但永远只能使用 10k RU/s。将您的 PK 更改为分布更均匀的东西。当然，这会改变您读取数据的方式。如果您提供有关您存储的文档的更多详细信息，那么我们可能会帮助您提出建议。如果您只是进行点查找（通过每个文档 ID 调用 ReadDocumentAsync()），那么您可以安全地在文档的 ID 字段上进行分区。这会将您的所有 200k 文档分布在所有 5 个物理分区中，并且您的 50k RU/s 吞吐量将最大化。一旦你有效地做到了这一点，你可能会发现你可以将 RU 的使用量减少到更低，并节省大量资金。如果每个 2.1KB 的记录只有 20 万条，您可能会降低到 2500 RU/s（您现在支付的成本的 1/20）。
*服务器加引号是因为每个物理分区实际上是许多服务器的集合，这些服务器经过负载平衡以实现高可用性和吞吐量（取决于您的一致性级别）。
【讨论】：
来自"How does partitioning work"：
简而言之，这是 Azure Cosmos DB 中分区的工作原理：
- 您使用 T RU/s 预配一组 Azure Cosmos DB 容器 （每秒请求数）吞吐量。
- 在幕后，Azure Cosmos DB 提供每秒服务 T 个请求所需的物理分区。 如果 T 高于每个物理分区的最大吞吐量 t， 然后 Azure Cosmos DB 提供 N = T/t 物理分区。价值 每个分区的最大吞吐量 (t) 由 Azure Cosmos 配置 DB，此值是根据总预置吞吐量分配的，并且 使用的硬件配置。
.. 更重要的是：
当您预配的吞吐量高于 t*N 时，Azure Cosmos DB 会拆分一个或多个物理分区以支持更高的吞吐量。
因此，您请求的 50k RU 吞吐量似乎高于上述t。考虑到这些数字，t 似乎约为 10k RU/s。
关于t的实际值，CosmosDB团队成员Aravind Krishna R.曾说过in another SO post：
[---] 未明确提及此值的原因是因为它会随着 Azure Cosmos DB 团队更改硬件或推出硬件升级而更改（增加）。目的是表明每个分区（机器）始终存在限制，并且分区键将分布在这些分区中。
您可以通过以最大吞吐量饱和单个分区键的写入来发现当前值。
【讨论】：