我正在为将查询Cosmos DB的微服务创建概念证明。该数据库将包含从数千个SQL数据库中收集的大量数据。每个SQL数据库都是一个带有siteId的站点，每个记录都有一个uniqueref（在该站点内是唯一的，但在全局上不是唯一的）。 Cosmos DB的想法是保存包含非常广泛的搜索功能可以查询的所有数据位的文档（我认为可能有25种以上的搜索词）。但是，约82％的搜索仅靠uniqueref进行（用户无需选择siteId，因为它们已经有效地登录到自己的站点，并且无法搜索其他任何站点）。加上另外7个字词组合，涵盖了所有搜索的97.5％。
我们之所以选择Cosmos是因为SQL数据库很大且其结构并非最佳，这意味着这些搜索会从多个表中加载10或什至100的数千行数据，以便将它们联接内存（次最佳设计决策中没有强制使用的外键）仅返回一行数据。不幸的是，我们不能更改SQL数据库。
我要决定的是什么将使Cosmos中的分区键变得更好？ uniqueref不能保证完全是全局唯一的，这意味着如果我正确地理解了文档，仅凭它是不好的，因为您将拥有成千上万个逻辑分区，其中可能包含1到3000条记录在里面。
每个站点的数据量变化很大：有些记录可能相对较少，可能只有几千条或更少，有些记录可能有几百条，因此siteId就像是物理分区热点在等待发生，好像我们有3000个站点，那么我认为那是3000个逻辑分区，其中有大量数据，除非我误解了热点的发生方式
另一种可能性是从siteId和uniqueref中合成密钥，因为我相信这是尝试均匀分配数据的一种流行方法。在所有情况下，我们都可以在搜索中包含siteId，在82％的情况下，我们可以包含uniqueref，这样我们就可以静默地创建和添加合成键。其余约18％的查询可能会吞噬更多的吞吐量，但这可能仍然比这些搜索产生的SQL Server资源成本高得多。麻烦的是，作为一个非常直观的学习者，我很难想象这将如何分发数据！ siteId和uniqueref的组合可能不像唯一值那样散布值。
文档大小是可变的，但平均可能在1.5KB到2.5KB之间。我还不知道每个站点的最大文档数量，但是无论如何这个数量还会增长，而且我不认为我们目前在任何一个站点上都达到400万大关，分区的上限大约为10GB。我不确定这对我的主要选择有多大影响或应该影响多少。
我在Cosmos方面的经验有限，因此我不确定该如何进行。我应该使用唯一值，数据分布不均的值还是可能不是唯一值但可能会分散很大值的值？