Azure Cosmos DB - 了解分区键

Stp*_*111 36 azure azure-cosmosdb

我正在设置我们的第一个Azure Cosmos数据库 - 我将导入第一个集合,即我们的一个SQL Server数据库中的表中的数据.在设置集合时,我无法理解分区键的含义和要求,我在设置此初始集合时必须特别指出.

我在这里阅读了文档:(https://docs.microsoft.com/en-us/azure/cosmos-db/documentdb-partition-data)并且仍然不确定如何继续使用此分区键的命名约定.

有人可以帮我理解我应该如何考虑命名这个分区键吗?请参阅下面的屏幕截图,了解我要填写的字段.分区键名称

如果它有帮助,我导入的表包含7列,包括唯一的主键,一列非结构化文本,一列URL和该记录的URL的其他几个辅助标识符.不确定是否有任何信息与我如何命名我的分区密钥有关.

编辑:我已根据@Porschiey的请求添加了我正在导入的表格中的几条记录的屏幕截图.

在此输入图像描述

Por*_*iey 23

老实说,这里视频*是理解CosmosDb中分区的主要帮助.

但是,简而言之:PartitionKey是一个属性,它将存在于最适合将类似对象组合在一起的每个对象上.

好的例子包括位置(如城市),客户ID,团队等.当然,它很大程度上取决于你的解决方案; 所以,如果您要发布您的对象的样子,我们可以推荐一个好的分区键.

编辑:应该注意,10GB以下的集合不需要PartitionKey.(感谢David Makogon)


*此视频曾用于此MS文档页面,名为"Azure Cosmos DB中的分区和水平扩展",但此后已被删除.上面提供了直接链接.

  • 实际上,对于大于10GB的集合,分区键*是*. (4认同)
  • 不再有固定存储(10GB)。您必须选择分区键。但是,如果不需要这样做该怎么办? (3认同)
  • 遗憾的是视频链接再次失效。MSDN 页面现在链接到这个 [2 分钟的 YouTube 视频](https://www.youtube.com/watch?v=277kuTO33yI&list=PLmamF3YkHLoLLGUtSoxmUkORcWaTyHlXp),但还有一个更好的视频,[分区策略 | 分区策略] Azure Cosmos DB Essentials](https://www.youtube.com/watch?v=QLgK8yhKd5U&list=PLmamF3YkHLoLLGUtSoxmUkORcWaTyHlXp) 在同一播放列表中,其中包含更多详细信息。 (3认同)

Ana*_*uza 13

我在这里整理了一篇详细的文章Azure Cosmos DB。分区

什么是逻辑分区?

Cosmos DB 设计为基于物理分区 (PP)(将其视为可单独部署的底层自给自足节点)和逻辑分区(具有相同特征(分区键)的文档存储桶)之间的数据分布进行水平扩展,该存储桶应该是完全存储在同一个PP上。所以LP不能有PP1上的部分数据和PP2上的另一部分数据。

物理分区有两个主要限制:

  • 最大吞吐量:10k RU
  • 最大数据大小(此 PP 中存储的所有 LP 大小的总和):50GB

逻辑分区的大小限制为 1 - 20GB。

注意:由于 Cosmos DB 的初始版本的大小限制有所增加,因此大小限制很快可能会增加,我不会感到惊讶。


如何为我的容器选择正确的分区键?

根据 Microsoft 对可维护数据增长的建议,您应该选择基数最高的分区键(例如Id文档或复合字段)。主要原因

将请求单位 (RU) 消耗和数据存储均匀分布在所有逻辑分区上。这可确保跨物理分区的 RU 消耗和存储分布均匀。

在考虑正确的分区键时,分析应用程序数据消耗模式至关重要。在极少数情况下,较大的分区可能会起作用,但同时此类解决方案应该实施数据归档以从一开始就维持数据库大小(请参阅下面的示例解释原因)。否则,您应该准备好增加运营成本,只是为了维持相同的数据库性能和潜在的 PP 数据偏差、意外的“分裂”和“热”分区。

采用非常细粒度和小的分区策略将导致在消耗分布在多个物理分区 (PP) 之间的数据时产生 RU 开销(绝对不是 RU 的倍增,而是每个请求几个额外的 RU),但与以下情况相比,它可以忽略不计:数据开始增长超过 50、100、150GB。


为什么在大多数情况下大分区是一个糟糕的选择,尽管文档说“选择最适合你的分区”

主要原因是 Cosmos DB 设计为水平扩展,并且每个 PP 的预配置吞吐量仅限于[total provisioned per container (or DB)] / [number of PP].

一旦由于超过 50GB 大小而发生 PP 分割,现有 PP 以及两个新创建的 PP 的最大吞吐量将低于分割之前。

因此,想象一下以下场景(将天数视为行动之间时间的度量):

  1. 您已经创建了一个容器,其中配置了 10k RU 和CustomerId分区键(这将生成一个底层 PP1)。每个 PP 的最大吞吐量为10k/1 = 10k RUs
  2. 逐渐将数据添加到容器中,最终您将获得 3 个大客户的发票,其中包括 C1[10GB]、C2[20GB] 和 C3[10GB]
  3. 当另一个客户使用 C4[15GB] 数据登录到系统时,Cosmos DB 必须将 PP1 数据拆分为两个新创建的 PP2 (30GB) 和 PP3 (25GB)。每个 PP 的最大吞吐量为10k/2 = 5k RUs
  4. 另外两个客户 C5[10GB] C6[15GB] 被添加到系统中,最终都进入 PP2,这导致另一个分裂 -> PP4 (20GB) 和 PP5 (35GB)。现在每个 PP 的最大吞吐量为10k/3 = 3.333k RUs

在此输入图像描述

重要信息:因此,[Day 2] C1查询数据时最多使用 10k RU,但最多[Day 4]使用3.333k ​​RU,这直接影响查询的执行时间

这是在当前版本的 Cosmos DB (12.03.21) 中设计分区键时要记住的一件主要事情。



Ani*_*Ani 6

CosmosDB可用于存储任何数据限制.后端如何使用分区键.它与主键相同吗? - 没有

主键:唯一标识数据分区键有助于分片数据(例如,当城市是分区键时,城市纽约的一个分区).

分区的限制为10GB,我们越好地跨分区传播数据,我们就越能使用它.虽然最终需要更多连接才能从所有分区获取数据.示例:从查询中获取相同分区中的数据总是比从多个分区获取数据更快.


Udi*_*dhi 6

分区键充当逻辑分区。

现在,您可能会问什么是逻辑分区?逻辑分区可能会根据您的要求而有所不同。假设您具有可以根据客户进行分类的数据,因为该客户“ Id”将充当逻辑分区,并且将根据其客户ID放置用户的信息。

这对查询有什么影响?

在查询时,您会将分区键作为供稿选项,并且不会将其包含在过滤器中。

例如:如果您的查询是

SELECT * FROM T WHERE T.CustomerId= 'CustomerId';
Run Code Online (Sandbox Code Playgroud)

现在将是

var options = new FeedOptions{ PartitionKey = new PartitionKey(CustomerId)};

var query = _client.CreateDocumentQuery(CollectionUri,$"SELECT * FROM T",options).AsDocumentQuery(); 
Run Code Online (Sandbox Code Playgroud)