很多人不想只使用ClickHouse为他们的公司或项目进行分析。他们希望将其作为SaaS数据/分析项目的骨干。大多数情况下，这需要支持半结构化的json数据，这可能会导致为每个用户创建大量列。
现在，一些经验丰富的ClickHouse用户表示，更少的表意味着更高的性能。因此，为每个用户提供一个单独的表并不是一种选择。
此外，将太多用户的数据放入同一数据库将导致大量的列，一些实验表明，这可能会使CH没有响应。
那么，每个数据库有20个用户，每个用户只能有50列，这又如何呢。但如果你有成千上万的用户呢？是否应该创建数千个数据库？
这个问题的最佳解决方案是什么？
注意：在我们的案例中，数据隔离不是一个问题，我们正在应用程序级别解决它。
单个数据库中的1000个表与具有单个表的1000个数据库之间没有区别。
1000个表和具有*1000个分区的表partition by (tenant_id, .some_expression_from_datetime.)之间几乎没有区别
该问题存在于MergeTree和ReplicatedMergeTree引擎的开销中。并且是您需要创建/读取的文件数量(与文件无关的数据位置问题，在没有文件系统的情况下也是一样的(。
如果您有1000个租户，唯一的方法是使用行策略或应用程序级别的order by (tenant_id,..)+限制。
我有一次与拥有700个Replicated表的客户打交道的经验——复制时经常出现混乱，需要调整后台池，Zookeeper的问题(巨大的DB大小，CH和ZK之间巨大的网络流量(。Clickhouse启动4个小时，因为它需要从所有1000000个部分读取元数据。分区修剪的工作速度较慢，因为它在每个查询的查询分析过程中遍历所有部分。
问题的来源是最初的设计，我想他们在metrika有大约3张桌子。
举个例子https://github.com/ClickHouse/ClickHouse/issues/31919