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