在cosmos db中,如果数据很少,每个数据库只有一个客户,那么应该选择哪个分区键?

根据你提供的信息听起来像 docType 是一个很好的属性,可以用作分区键,因为它可以用来避免跨分区查询。尤其是因为您声明这将经常用于您的查询中。按照您所说的最大大小,它也不太可能给您带来问题,因为单个分区最多可以包含20GB的数据。

需要注意的一件事是热分区。你说你的 users 分区可能比其他分区大得多。这可能会导致一个分区执行所有提升操作,而其他分区大部分处于空闲状态,从而导致总吞吐量效率低下。

另一方面,这对你的用例来说并不重要。因为没有一个数据库会超过5GB,所以你会一直呆在一个分区内,但事先考虑一下总是好的;由于情况可能会发生变化,最终会出现一个拆分为多个分区的数据库。

最后,我永远不会对所有数据使用单个分区。它没有任何好处。如果您没有可用作分区键的属性,那么 id 是更好的选择(因此每个文档都有一个逻辑分区)。它不会达到存储限制,并在分区之间均匀分配吞吐量。

我强烈建议你先看看这个 segment of the Data Modelling & Partitioning presentation 托马斯·韦斯,宇宙数据库项目经理。在我看来,这是了解如何思考分区的最佳资源之一。

同意David Makogon的观点,你没有提供足够的数据。例如,我们知道每个数据库有30个文档类型——给定cosmosdb数据库使用容器,我实际上希望每个文档类型都有自己的容器——与您所写的相反:

使用customerId(因此所有数据都在一个分区中)或docType作为分区键是否更有意义?

这意味着您希望对所有数据使用单个容器。我不会把用户和员工作为文档放在同一个容器中。它们是独立的域,应该有自己的容器。 请参见上的Azure文档页面 Partition Strategy 以及关于访问模式的后续段落。建议是:

选择一个分区键,使访问模式能够均匀分布在逻辑分区上。

在访问模式一节中,提到的良好实践是将数据分为热数据、中数据和冷数据,并将其放入各自的容器中。一个警告是,根据这个 page 每个数据库共享吞吐量的最大容器数为25。

如果这是不可能的,并且所有数据都必须在一个容器中结束,那么docType似乎是正确的分区键,因为如果我理解正确,您的查询将按docType获取数据。

正如404所写,您希望避免热分区,即将容器中的大多数文档阻塞到单个或几个逻辑分区中。因此,您需要根据最频繁的操作选择分区键。