什么是 ClickHouse:OLAP 与列式存储

从一个场景出发

假设在做一个电商后台,运营同事提了一个需求:"我想看过去一年,每个省份每天的订单量和销售额,能按日期和地区自由筛选."

用 MySQL 写一条查询:

SELECT province, DATE(created_at) AS day,
       COUNT(*) AS order_cnt, SUM(amount) AS total
FROM orders
WHERE created_at >= '2025-01-01'
GROUP BY province, day
ORDER BY day, province;

一年几百万订单,这条查询跑了 8 秒.运营说"还行,但我还想加上用户留存,复购率,SKU 维度...",每条新需求都在挑战查询时间的上限.

这不是 MySQL 的问题--是工具和场景不匹配. 这条查询属于"分析型查询",而 MySQL 是为"事务型操作"设计的. 这时候需要一个专门干这件事的数据库--ClickHouse.

数据库的两类工作负载

数据库领域有一个经典划分:OLTP 和 OLAP. 这两个词决定了数据库的架构设计走向,理解它们是理解 ClickHouse 的前提.

现在问题来了:OLTP 和 OLAP 对数据库的读写模式差异如此之大,用同一套存储结构能同时做好两件事吗? 答案是不能.这就引出了行存与列存的分野.

行存与列存:核心分水岭

假设有一张用户表,存了 4 列数据:

行式存储(Row Store)

MySQL,PostgreSQL 等 OLTP 数据库把一行数据完整地存在一起:

磁盘布局: [1,张三,28,北京] [2,李四,35,上海] [3,王五,22,北京] [4,赵六,41,深圳]
               ← 第 1 行 →     ← 第 2 行 →     ← 第 3 行 →     ← 第 4 行 →

好处:读一行时,一次磁盘 I/O 就能拿到整行所有列--OLTP 的"按主键查一行"刚好需要这个.

坏处:如果只想算 AVG(age),也得把所有行的 name,city 一起读进内存--这些查询并不需要的列占了带宽和内存,纯属浪费.

列式存储(Column Store)

ClickHouse 反其道而行,把同一列的所有值存在一起:

磁盘布局: [1,2,3,4] [张三,李四,王五,赵六] [28,35,22,41] [北京,上海,北京,深圳]
               ← id →    ←     name      →   ←  age →    ←      city      →

好处:SELECT AVG(age) FROM users 只读 age 那一列的数据,其余列完全跳过. 列中同类型数据压缩率极高(比如 age 全是整数,用 Delta 编码可以把 [28,35,22,41] 压成几个字节).

坏处:如果要取一整行的所有列,得从四个不同的列文件中分别定位和拼接--OLTP 的点查场景下这是灾难.但 OLAP 很少取整行,通常只关注某几列的聚合.

行存和列存不是谁替代谁的关系,它们各自适合不同类型的工作负载. 下面的对比帮助建立直觉:

ClickHouse 是什么

有了 OLAP 和列存的背景,ClickHouse 的定义就很好理解了:

ClickHouse(简称 CH)是俄罗斯搜索引擎 Yandex 于 2016 年开源的列式 OLAP 数据库管理系统(Column-Oriented OLAP DBMS),使用 C++ 编写,专为海量数据的实时分析查询而设计.

拆开来看,ClickHouse 的核心设计选择都围绕一个目标:用最短的时间扫描最多的数据.

它是怎么做到快的?

ClickHouse 的快不是某一个技巧,而是一组策略的叠加.这里先建立整体印象,不用逐条死记--后续各篇会逐个展开:

一个直观的对比

Yandex 在公开 Benchmark 中展示过这样的数据(同一台机器,1 亿行数据集):

这不是魔法,就是架构选择带来的差距--专为此类查询设计的存储结构和执行引擎,比通用引擎高效几个数量级.

ClickHouse 不擅长什么

了解一个工具的边界,比了解它的能力更重要.以下场景不适合用 ClickHouse,或者需要额外的设计来规避:

与常见数据库的关系

把 ClickHouse 放进你已有的技术栈认知里,梳理与其他数据库的关系: