我们有个标签表,单表大概1P
https://www.163.com/dy/article/H4RAV2NC0511D3QS.html
ClickHouse 社区版原生的 Replication 方案有太多的信息存在 ZooKeeper 上,为了保证服务,一般会有一个或者几个副本,在字节内部主要是两个副本的方案。
早期内部曾有一个 400 个节点的集群,只存了半年的数据。突然有一天团队发现服务特别不稳定,ZK 的响应经常超时,table 可能变成只读模式,发现 znode 太多。而且 ZK 并不是可水平扩展的框架,按照当时的数据预估,整个服务很快就会不可用了。
团队分析后得出结论,实际上 ClickHouse 把 ZK 当成了三种服务的结合,而不仅把它当作一个 Coordinate service,可能这也是大家使用 ZK 的常用用法。ClickHouse 还会把它当作 Log Service,很多行为日志等数字的信息也会存在 ZK 上;还会作为表的 catalog service,像表的一些 schema 信息也会在 ZK 上做校验,这就会导致 ZK 上接入的数量与数据总量会成线性关系。按照这样的数据增长预估,ClickHouse 可能就根本无法支撑头条、抖音的全量需求。