ClickHouse中的多租户功能

Question

很多人不想仅仅将ClickHouse用于公司或项目的分析，他们希望将其作为SaaS数据/分析项目的主干。这往往需要支持半结构化JSON数据，这可能会导致为每个用户创建大量列。

现在，一些有经验的ClickHouse用户认为表越少性能越好。因此，为每个用户单独创建一个表不是一个选择。

此外，将太多用户的数据放入同一个数据库中将导致非常多的列，一些实验表明这可能会使CH无响应。

那么对于每个数据库20个用户，每个用户限制50个列的方案如何？但如果您有成千上万的用户呢？难道要创建成千上万个数据库吗？

这个问题的最佳解决方案是什么？

注意：在我们的情况下，数据隔离不是问题，我们正在应用程序级别上解决它。

- Marwan abdel moneim

Answer 1

在单个数据库中有1000个表和在单个表中有1000个分区（按租户ID或日期等分类）几乎没有区别。

问题出在MergeTree和ReplicatedMergeTree引擎的开销上。同时也与你需要创建/读取的文件数量有关（数据本地化问题，与文件系统无关的情况下也会存在）。

如果有1000个租户，则唯一的方法是使用order by (tenant_id,..) + 使用行策略或应用程序级别的限制。

我曾经遇到过使用700个复制表的客户，要不停地解决复制问题，需要调整后台池，还有与Zookeeper的问题（巨大的DB大小，CH和ZK之间的巨大网络流量）。 Clickhouse需要4小时才能启动，因为它需要从所有1000000部分读取元数据。对于每个查询，在查询分析期间，分区修剪速度较慢，因为需要遍历所有部分。

问题的根源在于最初的设计，我猜在Metrika中只有3个表。

例如，请查看此链接https://github.com/ClickHouse/ClickHouse/issues/31919

- Denny Crane

---

我（以及其他人）难以理解为什么大量表或数据库会成为问题。也许我需要更多地了解MergeTrees。但我的理解是ClickHouse必须在单独的并发进程中处理这些数据库或表。因此，启动时间可能会很长，但如果虚拟机有足够的资源，那么为什么会影响查询时间呢？-- 另外，我理解你的解决方案，那正是我们正在做的。但是使用数组或常规列支持半结构化数据（对于许多租户）将导致大量[物化]列。 - Marwan abdel moneim

注意：我们可能有许多集群，也可能在每个集群内安装了许多ClickHouse（还不确定如何确切完成）。因此，我不是在谈论每个安装中拥有1K个数据库或表。我甚至不想在集群中分散拥有1K个数据库，我们希望数量较少，但某种程度上数学并不奏效。-- 20个用户限制50个列意味着1K个列，这个表现在被排除掉了。那么当你有成千上万的用户时会发生什么？ - Marwan abdel moneim

我也在同样的问题上苦苦挣扎。 - Apurv Gupta

多租户我认为在中国是一个半解决的问题。 - danthegoodman