我们正在研究使用 CitusDB。在阅读了所有文档后，我们还不清楚一些基础知识。希望有大神指点一下。
在 Citus 中，您指定 ashard_count和 a shard_max_size，这些设置是根据文档在协调器上设置的（但奇怪的是也可以在节点上设置）。
当您指定 1000 个分片并分配 10 个表和 100 个客户端时会发生什么？
它是否为每个表（users_1、users_2、shops_1 等）创建一个分片（如此有效地使用所有 1000 个分片。
如果你再增加 100 个客户端，我们已经达到了 1000 个限制，这些表是如何分区的？
shard_max_size默认为 1Gb 。如果一个分片大于 1Gb，则会创建一个新分片，但是当 shard_count 已经达到时会发生什么？
最后，是否建议购买 3000 个分片？我们在文档中阅读了 128 建议用于 saas。但是，如果您有 100 个客户 * 10 个表，那么这个接缝很低。（我知道这取决于..但是..）
前 Citus/现任微软员工在这里提出一些建议。
Citus 分片基于分布键的整数哈希范围。当插入一行时，分布键的值被散列，计划器查找分配了该键所在的散列值范围的分片，然后查找分片所在的工作人员，然后运行插入那个工人。这意味着客户以大致均匀的方式分布在分片中，当您添加新客户时，它只会进入现有分片。
至关重要的是，您希望彼此连接的所有分布式表都具有相同数量的分片，并且它们的分布列具有相同的类型。这让我们可以完全在工作人员上执行连接，这对性能来说非常棒。
如果您有一个超级大客户（数据量是普通客户的 100 倍是一个不错的启发式方法），我会提前使用租户隔离功能为他们提供自己的分片。如果您决定在路上这样做，这将使它们更容易移动到专用硬件。
该shard_max_size设置对散列分布式表没有影响。随着您不断插入数据，分片将无限增长，并且散列分布表在正常操作下永远不会增加其分片数。此设置仅适用于附加分发，这些天很少使用（我可以想到一两家公司使用它，但仅此而已）。
对于您描述的用例，我强烈建议不要将 citus.shard_count 更改为 3000。64 或 128 可能是正确的，如果您正在查看 >100TB 的数据，我会考虑 256。如果您最终拥有数千个分布式表并且每个表有 128 个分片，这完全没问题，但最好保持每个表的分片数量合理。