azure-cosmosdb - 在 CosmosDB 中使用 GUID 的子字符串作为分区键是一个坏主意吗？

Question

我正在进行一些研发以将产品目录移至 CosmosDB。

用最简单的术语来说，产品文档将具有:

产品 ID (GUID)

产品名称

制造商

制造商将登录该系统，并且只能查询他们自己的数据，因此每次查询都会有一个 ManufacturerId = SINGLE_VALUE 过滤器。

在查看 cosmos 文档时，re:选择正确的分区策略，似乎有 2 个要点。
- 选择基数高的分区键
- 选择一个可以均匀分布数据的分区键。

在我上面的场景中，选择产品 ID 作为 PartitionKey 会非常极端……每个逻辑分区 1 个文档。
另一方面，选择 Manufactuer 也不会很好，因为这不会导致均匀分布(有些制造商有 10 个产品，其他制造商有 100,000 个)

确保均匀分布的一种方法是采用 GUID 的前 4 个字符并将其用作 PartitionKey。 (所以最多 4096 个分区)。根据我现有的数据集，这确实会导致数据的均匀分布。但我想知道这样做有什么缺点。

仅使用整个 productId 作为 PartitionKey(每个分区 1 个文档)是否有任何缺点，因为它们似乎表明对于存储用户配置文件的系统来说这是一种有效的方法。这种方法是否对在同一搜索中搜索多个产品有影响。

Answer 1

使用每个文档唯一的 key 是确保均匀分发以支持高性能的好方法——因此，完整的产品 ID 是一个不错的选择。我不相信使用完整 guid 的子字符串作为分区键会给您带来任何好处 - 而且您会限制可用分区的最大数量。

那么为什么不总是使用唯一标识符作为分区键呢？

首先，如果在查询中添加分区键，则无需启用跨分区查询，总体查询成本(RU/s)会更低。因此，如果您可以设计分区键以减少对跨分区查询的需求，则可以节省 RU/s。我不认为“guid 的子字符串”对您有帮助，因为 guid 的随机特性不会以您可以利用的方式分发文档以进行高效查询。

其次，如果您需要将它们包含在事务存储过程中，则只有具有相同分区键的文档才能保证在同一分区上全部可用。 'guid 的子字符串'也无助于这种情况。

我几乎总是使用基于“标识符”的分区键，例如您的产品 ID。这并不总是对应于文档本身的“id”。有时我有多个文档，内容与同一件事相关。例如，如果我有一些从另一个系统同步的产品信息，那么如果它使用 upsert 同步作业可能是最有效的 - 但由于目前 CosmosDB 中缺乏部分更新支持(请参阅 user voice )，整个文档需要更新。因此，在这种情况下，我有一个用于同步信息的文档，以及一个用于其他信息的单独文档。这可能看起来像:

{
  "id": "12345:myinfo",
  "productid":"12345",
  "info":{}
  "type":"myinfotype"
},
{
  "id": "12345:vendorsync",
  "productid":"12345",
  "syncedinfo":{},
  "type":"vendorsync"
}

此处的产品 ID 是分区键，我有几个与该产品相关的不同文档，我知道这些文档将驻留在同一分区中，因此我可以有效地查询它们或将它们参与到事务中。

我在实现修订系统时也使用了这种模式，以便保证同一逻辑文档的所有修订都放在同一个分区上。在这种情况下，文档具有所有修订版都相同的“documentid”，并且文档的实际“id”是添加了修订号的文档 id。

如果您还没有，请在此处查看“分区设计”:
https://docs.microsoft.com/en-us/azure/cosmos-db/partition-data