运维 PB 级 ClickHouse 五年：架构、存储与代价的真实教训
来源：tinybird.co — tinybird.co · 62 分 · by adastral
📋 概述
作者在 Tinybird 从 ClickHouse 18.4 起运维了近六年，管理过多个 PB 级集群，这篇文章是他认为最值得告诉后来者的部分：搭集群容易，让它一直跑下去才是难点。架构仍是分片加副本的老配方——按 hash 把数据切桶丢进分片，每个分片再放若干副本；但复制方案本身正在被质疑，越来越多人相信要把计算与存储分离、把数据放到云对象存储上。他提到自己几年前从「只有副本、没有分片」起步，靠垂直扩容扛查询、加副本扛流量，本地 SSD 换低延迟；不分片的原因是重新分片极其痛苦，而如果 schema 设计得足够聪明，还能再押后一阵。代价是内存与磁盘成倍放大：一张 300TB 的表若需要 10 个副本，实际就要 3000TB。
🔑 核心要点
- 搭集群容易，让它长期稳定运行才是难点，文章重点在踩过的坑。
- 架构是分片 + 副本，但计算存储分离正在成为主流看法。
- 从「只有副本、没有分片」起步，靠垂直扩容 + 加副本撑过早期。
- 不分片的原因是重新分片极其痛苦，schema 设计可以推迟这件事。
- 副本放大会把成本成倍推高，例如 300TB 的表可能变成 3000TB。
- 他建议给写入单独留一个副本，即compute-compute 分离，并对高 p99 查询做负载隔离。
💡 金句
一开始我也以为难点在调参——后来才明白，真正的难点是这台机器五年里每一天都得活着。
👍 0
👎 0
← 返回 Hacker News 首页