首页 文章

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

提问于
浏览 次
1

我们正在使用Cosmos DB SQL API，这里有一个集合 XYZ ：

尺寸： Unlimited
吞吐量： 50000 RU/s
PartitionKey： Hashed

我们正在插入200,000条记录，每条记录的大小约为2.1 KB，并且对于分区键列具有相同的值 . 根据我们的知识，具有相同分区键值的所有文档都存储在同一逻辑分区中，并且逻辑分区不应超过10 GB限制，无论我们是固定大小还是无限大小的集合 .

显然，我们的总数据甚至不是0.5 GB . 但是，在Azure Cosmos DB的指标刀片中（在门户网站中），它说：

集合XYZ有5个分区键范围 . 预配置吞吐量均匀分布在这些分区上（每个分区10000 RU / s） .

这与我们迄今为止从MSFT文档中研究的内容不符 . 我们错过了什么吗？为什么要创建这5个分区？

Azure Cosmos DB Metrics

azure-cosmosdb partitioning azure-cosmosdb-sqlapi

2 回答

  • 1

    使用 Unlimited 集合大小时，默认情况下将为您配置5个 physical 分区键范围 . 此数字可能会更改，但截至2018年5月，默认值为5 . 您可以将每个 physical 分区视为"server" . 因此，您的数据将分布在5个物理"servers"中 . 随着数据大小的增加，您的数据将自动针对更多物理分区进行重新分配 . 这就是为什么在设计中预先设置分区键非常重要的原因 .

    对于所有200k记录具有相同分区键（PK）的场景中的问题是您将有热点 . 你有5个物理"servers"但只会使用一个 . 其他4个将闲置，结果是你需要支付50k RU / s，但是只能使用10k RU / s . 将您的PK更改为更均匀分布的内容 . 这将改变您阅读数据的方式 . 如果您提供有关文档的更多详细信息，您只需执行点查找（按每个文档ID调用 ReadDocumentAsync() ），那么您可以安全地对文档的ID字段进行分区 . 这将在所有5个物理分区中传播所有200k文档，并且您的50k RU / s吞吐量将最大化 . 一旦你有效地做到这一点，你可能会发现你可以将RU使用量降低到更低的水平并节省大量资金 . 只有20万条记录，每条记录为2.1KB，你可能会低至2500 RU / s（你现在支付的费用的1/20） .

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

    回复于
  • 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会拆分一个或多个物理分区以支持更高的吞吐量 .

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

    关于 t 的实际值，CosmosDB团队成员Aravind Krishna R.已经说in another SO post：

    [---]未明确提及此值的原因是因为Azure Cosmos DB团队更改硬件或推出硬件升级时将更改（增加） . 目的是显示每个分区（机器）始终存在限制，并且分区键将分布在这些分区上 . 您可以通过在最大吞吐量下使单个分区键的写入饱和来发现当前值 .

    回复于

相关问题