📚 课程目录第1章 ClickHouse前世今生

1. ClickHouse 前世今生：列式存储的起源、OLAP 定位与核心设计哲学

大家好，我是你们的 ClickHouse 讲师。今天咱们聊聊这个数据库的「出身」。

很多人问我：ClickHouse 为什么这么快？它跟 MySQL、PostgreSQL 到底有什么区别？

要回答这个问题，得先搞清楚一件事——列式存储是怎么来的。

传统的关系型数据库，比如 MySQL、Oracle，用的都是行式存储。数据一行一行地存，像 Excel 表格一样。

行式存储适合 OLTP（在线事务处理）。你查一条订单，把整行数据拉出来，很快。但如果你要分析几亿行数据，只取其中两列呢？

行式存储会把所有列都读出来，再扔掉不需要的。磁盘 I/O 浪费严重。

列式存储的思路正好相反——按列存，按列读。每一列的数据连续存放在磁盘上。查询时只读取需要的列，I/O 量大幅减少。

我记得 2016 年第一次接触列存时，有个场景让我印象很深：一张 10 亿行的日志表，行存跑一个聚合查询要 40 秒，换成列存后，同样的查询只用了 0.8 秒。当时我就觉得，这条路走对了。

核心差异一句话总结：

OLAP 领域其实很拥挤。有 Druid、Greenplum、Apache Doris、Snowflake……ClickHouse 凭什么脱颖而出？

我个人习惯把 OLAP 引擎分成三类：

ClickHouse 的定位非常明确：面向在线分析，追求极致查询速度。它不追求事务能力，也不做行级更新。它只做一件事——让分析查询跑得飞快。

你想想看，如果你的业务场景是：

那 ClickHouse 几乎是最优解。

我的建议：不要拿 ClickHouse 当 MySQL 用。它不适合频繁的单行插入或更新。如果你需要强事务，请选 OLTP 数据库。

ClickHouse 的设计哲学可以概括为四个字：一切为了速度。

具体来说，体现在以下几个方面：

列式存储只是基础。真正让 ClickHouse 起飞的是向量化执行引擎。

传统数据库处理数据是一条一条来的（逐行处理）。ClickHouse 是一次处理一批数据（向量），充分利用 CPU 的 SIMD 指令集。说白了，就是让 CPU 一次干更多活。

我在项目中遇到过这样一个对比：同样的 1 亿行数据求和，MySQL 需要 12 秒，ClickHouse 只需要 0.03 秒。差距接近 400 倍。

ClickHouse 的主键索引不是 B+ 树，而是稀疏索引。它每隔 N 行记录一个索引条目，索引体积很小，可以完全加载到内存中。

查询时，先通过稀疏索引定位到数据块，再在块内顺序扫描。这种方式对范围查询和聚合查询特别友好。

注意：ClickHouse 的索引不适合精确查找单行。如果你经常做 WHERE id = 123 这种查询，ClickHouse 不是最佳选择。

列式存储天然有利于压缩。同一列的数据类型相同，值往往也相似。ClickHouse 提供了多种压缩算法：LZ4、ZSTD、Delta 等。

我习惯用 LZ4 作为默认压缩算法。它压缩比虽然不如 ZSTD，但解压速度极快，适合高并发查询场景。

ClickHouse 充分利用多核 CPU。一个查询会被拆成多个子任务，并行执行。在分布式集群中，每个节点只处理本地数据，最后汇总结果。

这种设计让 ClickHouse 在硬件资源充足时，查询性能可以线性扩展。

下面这张图是我梳理的 ClickHouse 核心知识体系，你可以把它当作整个课程的地图：

我带过不少团队，发现新手在接触 ClickHouse 时，经常踩这几个坑：

我曾经见过一个团队，把 ClickHouse 的排序键设成 UUID，结果数据膨胀了 3 倍，查询慢得像蜗牛。后来改成时间戳 + 业务 ID 后，压缩比从 3:1 提升到 8:1，查询速度提升了 10 倍。

这一章我们聊了：