我正在设置我们的第一个 Azure Cosmos DB - 我将导入第一个集合，即我们的一个 SQL Server 数据库中的表中的数据。在设置集合时，我无法理解分区键的含义和要求，我在设置这个初始集合时特别需要命名。
我已阅读此处的文档：(https://docs.microsoft.com/en-us/azure/cosmos-db/documentdb-partition-data)，但仍然不确定如何继续使用此分区键的命名约定。
谁能帮我理解我在命名这个分区键时应该怎么想？请参阅下面的屏幕截图了解我要填写的字段。
如果有帮助，我要导入的表由 7 列组成，包括一个唯一的主键、一列非结构化文本、一列 URL 和该记录 URL 的其他几个辅助标识符。不确定是否有任何信息对我应该如何命名我的分区键有任何影响。
编辑：根据@Porschiey 的请求，我添加了要从中导入的表中的几条记录的屏幕截图。
【问题讨论】：
标签： azure azure-cosmosdb
老实说，video here* 对理解 CosmosDb 中的分区非常有帮助。
但是，简而言之： PartitionKey 是一个将存在在每个对象上的属性，该属性最好用于将相似对象组合在一起。
很好的例子包括位置（如城市）、客户 ID、团队等。自然，这在很大程度上取决于您的解决方案；因此，也许如果您要发布您的对象的外观，我们可以推荐一个好的分区键。
编辑：应该注意，10GB 以下的集合不需要 PartitionKey。 （感谢 David Makogon）
* The video 曾经生活在 this MS docs page 上，标题为“Azure Cosmos DB 中的分区和水平缩放”，但此后已被删除。上面提供了直接链接。
【讨论】：
SourceCountry作为PartitionKey，来自其他国家的结果不会看到查询性能受到影响如果美国有更多的文件。我会选择 SourceCountry 或 Category - 但你应该尝试不同的方法，看看哪种方法最适合你。
分区键充当逻辑分区。
现在，您可能会问什么是逻辑分区？逻辑分区可能因您的要求而异；假设您有可以根据您的客户进行分类的数据，因为此客户“ID”将充当逻辑分区，并且用户的信息将根据他们的客户 ID 放置。
这对查询有什么影响？
在查询时，您会将分区键作为提要选项，并且不会将其包含在您的过滤器中。
例如：如果您的查询是
SELECT * FROM T WHERE T.CustomerId= 'CustomerId';
马上就到了
var options = new FeedOptions{ PartitionKey = new PartitionKey(CustomerId)};
var query = _client.CreateDocumentQuery(CollectionUri,$"SELECT * FROM T",options).AsDocumentQuery();
【讨论】：
CosmosDB 可用于存储任何限制的数据。它在后端的作用是使用分区键。和主键一样吗？ - 没有
主键：唯一标识数据 分区键有助于数据分片（例如，当城市是分区键时，纽约市的一个分区）。
分区有 10GB 的限制，我们将数据分布在分区之间的越好，我们可以使用的越多。尽管它最终需要更多的连接来从所有分区获取数据。示例：在查询中从同一分区获取数据总是比从多个分区获取数据要快。
【讨论】：
我在这里整理了一篇详细的文章Azure Cosmos DB. Partitioning。
Cosmos DB 旨在基于物理分区 (PP)（将其视为可单独部署的底层自给自足节点）和逻辑分区之间的数据分布水平扩展 - 具有相同特征的文档桶 （分区键) 应该完全存储在同一个 PP 上。所以 LP 不能有 PP1 上的一部分数据和 PP2 上的另一个数据。
物理分区有两个主要限制：
逻辑分区的大小限制为 1 - 20GB。
注意：由于 Cosmos DB 的初始版本大小限制增加，我不会对很快大小限制可能会增加感到惊讶。
根据 Microsoft 对可维护数据增长的建议，您应该选择具有最高基数的分区键（如文档的 Id 或复合字段）。对于main reason：
将请求单元 (RU) 消耗和数据存储均匀地分布在所有逻辑分区中。这可确保在您的物理分区中均匀地分配 RU 消耗和存储。
在考虑正确的分区键时，分析应用程序数据消耗模式至关重要。在极少数情况下，较大的分区可能会起作用，但同时此类解决方案应实施数据归档以从一开始就保持 DB 大小（请参见下面解释原因的示例）。否则，您应该准备好增加运营成本，以保持相同的数据库性能和潜在的 PP 数据倾斜、意外的“分裂”和“热”分区。
具有非常精细和小的分区策略将导致 RU 开销（绝对不是 RU 的倍增，而是每个请求耦合额外的 RU）消耗分布在多个物理分区 (PP) 之间的数据，但与当数据开始超过 50、100、150GB 时会出现问题。
主要原因是 Cosmos DB 旨在水平扩展，每个 PP 的预置吞吐量限制为 [total provisioned per container (or DB)] / [number of PP]。
一旦由于超过 50GB 大小而发生 PP 拆分，您现有 PP 以及两个新创建的 PP 的最大吞吐量将低于拆分前的水平。
因此想象以下场景（将天数视为操作之间的时间度量）：
CustomerId 分区键的容器（将生成一个底层 PP1）。 每个 PP 的最大吞吐量为 10k/1 = 10k RUs
10k/2 = 5k RUs
10k/3 = 3.333k RUs
重要提示：因此在
[Day 2]C1上查询了多达 10k RU 的数据 但是在[Day 4]上 only max 到 3.333k 个 RU，这会直接影响查询的执行时间
这是在当前版本的 Cosmos DB (12.03.21) 中设计分区键时要记住的主要事项。
【讨论】：
Partition Key 用于分片，它充当数据的逻辑分区，并为 Cosmos DB 提供跨分区分布数据的自然边界。
您可以在此处阅读更多信息：https://docs.microsoft.com/en-us/azure/cosmos-db/partition-data
【讨论】：
表上的每个分区最多可以存储 10GB（单个表可以存储任意数量的文档架构类型）。您必须选择您的分区键，以便针对该键存储的所有文档（因此属于该分区）都在该 10GB 限制之下。
我现在也在考虑这个问题——那么分区键应该是某种类型的日期范围吗？在这种情况下，这实际上取决于一段时间内存储了多少数据。
【讨论】：