zhibo shan1. ClickHouse存储架构的本质
作为一名长期使用ClickHouse的数据工程师，我必须首先澄清一个根本性问题：ClickHouse从设计之初就是一个纯粹的列式存储数据库。这与我们熟悉的MySQL、PostgreSQL等行式数据库有着本质区别。
1.1 列式存储的核心特征
ClickHouse的存储结构具有以下典型特征：
- 按列分文件存储：每个列单独存储为物理文件
- 数据块组织：数据按Block/Granule为单位组织
- 向量化执行：数据处理采用SIMD指令并行计算
这种设计带来的直接优势是：
- 极高的压缩率（同类型数据压缩效果更好）
- 极快的聚合查询速度（只需读取相关列）
- 优秀的批量写入性能（顺序IO吞吐量高）
1.2 为什么列存不适合OLTP场景
然而，这种设计也带来了明显的局限性：
- 点查性能差：需要从多个文件重组行数据
- 单行写入成本高：每次写入都会生成新的数据块
- 更新操作昂贵：需要重写整个列文件
这解释了为什么在21.x版本之前，ClickHouse几乎无法用于任何需要频繁单行读写的场景。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. "行友好"能力的演进历程
2.1 早期版本（≤20.x）的局限
在2021年之前的版本中，ClickHouse确实是一个纯粹的OLAP引擎：
- 只适合大批量追加写入
- 点查需要全列扫描
- 高频小批量insert会导致大量小文件
2.2 21.x～22.x版本的突破
这个阶段引入了多项关键改进：
2.2.1 写入优化
- 格式支持增强：
sql复制INSERT INTO table FORMAT Values (v1,v2),(v3,v4) - 小批量写入合并：自动合并小的数据块
- Compact Parts：减少小文件数量
2.2.2 读取优化
- 延迟物化：先过滤后组装行
- 主键点查优化：
sql复制-- 性能显著提升的查询 SELECT * FROM table WHERE primary_key = value LIMIT 1
2.3 23.x～24.x版本的成熟
最新