为什么cosmos db为同一个分区键值创建了5个分区？

Question

我们正在使用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个分区？

Answer 1

使用$ is undefined集合大小时，默认情况下，您将配置5个物理分区键范围。此数字可能会更改，但截至2018年5月，默认值为5。您可以将每个物理分区视为＆＃34;服务器＆＃34;。因此，您的数据将分布在5个物理＆＃34;服务器＆＃34;中。随着数据大小的增加，您的数据将自动针对更多物理分区进行重新分配。这就是为什么在设计中预先获得分区密钥正确的原因非常重要。

对于所有200k记录具有相同分区键（PK）的方案中的问题是您将有热点。你有5个物理＆＃34;服务器＆＃34;但只会使用一个。其他4个将闲置，结果是您在相同的价位上表现较差。您支付50k RU / s，但只能使用10k RU / s。将您的PK更改为更均匀分布的内容。这将改变您阅读数据的方式。如果您提供有关您要存储的文档的更多详细信息，那么我们可以帮助您提供建议。如果您只是简单地进行点查找（按每个文档ID调用Unlimited），那么您可以安全地对文档的ID字段进行分区。这将在所有5个物理分区中传播所有200k文档，并且您的50k RU / s吞吐量将最大化。一旦你有效地做到这一点，你可能会发现你可以将RU使用量降低到更低的水平并节省大量资金。只有20万条记录，每条记录为2.1KB，你可能会低至2500 RU / s（你现在支付的费用的1/20）。

*服务器在引号中，因为每个物理分区实际上是许多服务器的集合，这些服务器负载均衡，以实现高可用性和吞吐量（取决于您的一致性级别）。

Answer 2

来自"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会拆分一个或多个物理分区以支持更高的吞吐量。

因此，您所请求的RU吞吐量50k似乎高于上面提到的t。考虑到数字，似乎t是~10k RU / s。

关于t的实际价值，CosmosDB小组成员Aravind Krishna R.已说过in another SO post：

  

[---]未明确提及此值的原因是因为Azure Cosmos DB团队更改硬件或推出硬件升级时将更改（增加）。目的是显示每个分区（机器）总是有限制，并且分区键将分布在这些分区上。

     

您可以通过在最大吞吐量下使单个分区键的写入饱和来发现当前值。