列式数据库是怎么炼成的

Tue, 31 Mar 2026 14:44:37 +0800

列式数据库与行式数据库最大的区别在于数据的存储方式，也就是它们在磁盘上的组织方式不同。传统的行式数据库常用于 OLTP (Online Transaction Processing) 场景，在这个场景下需要频繁的进行数据的插入、更新、删除操作，操作的对象往往是单行数据。而列式数据库常用于 OLAP (Online Analytical Processing) 场景，对于数据的聚合查询更为常见，往往需要扫描某一列的大量数据进行计算。

Storage Difference

如果同时用过两种类型的数据库，就会发现：

这里列举的优化原则只是冰山一角，仅用于说明两种数据库最显眼的差异。

使用行式数据库过程中，最简单常见的优化原则就是 尽可能命中索引、降低 B+ 树高度、减少扫描行数，如：

优先对区分度高的列建立索引
覆盖索引（索引中包含查询所需的所有列，避免回表）
索引下推（在存储引擎层提前过滤不满足条件的数据）
最左前缀匹配原则
避免使用函数或者隐式类型转换（如：where date(create_time) = '2022-01-01'），会导致索引失效
避免在索引列上使用 !=、<> 等操作符，会导致索引失效
避免深度分页
分库分表（提出这一优化方向，也是基于单表数据量过大，索引维护的开销会增加，性能也会退化）
等等…

减少扫描行数这一思路对于列式数据库同样适用（如分区裁剪），但列式数据库还有另一个很重要的优化方向，那就是 减少列，如：

行存特性（如果是点查询，列数据库 I/O 反而会增加，这一点和行式数据库正好相悖）
只读取查询涉及的列（行存也提倡避免 SELECT *，但由于行存以行为单位读取磁盘，主要减少的是网络传输量而非磁盘 I/O；而列存中每列独立存储，少读一列就直接少一份磁盘 I/O）
等等…

当然，任何数据库的优化，都逃不开 减少 I/O 这一核心目的。说得更白话一点，如果有一种完美的存储介质，它没有I/O延迟，也不会丢失数据，那么这些优化也就不再需要了。

1. ClickHouse 的设计#

1.1 整体组件#

从 ClickHouse 的架构图来看，列式数据库包含以下核心组件：

ClickHouse Architecture

查询处理层：查询处理遵循传统范式：解析入站查询、构建并优化逻辑与物理查询计划，然后执行
- SQL Parser
- SQL Planner
- Physical Plan Builder
- Plan Executor
存储层：由不同的表引擎组成，这些表引擎封装了表数据的格式和位置
- MergeTree* Family Tables Engines：代表了 ClickHouse 中的主要持久化格式
- Special-Purpose Tables Engines：用于加速或分布查询执行的专用表引擎
  - Dictionary
  - Memory
  - Distributed (Data Sharding) 处理分布式
集成层：用于与外部系统进行双向数据交换的虚拟表引擎，例如关系型数据库 (如 PostgreSQL、MySQL) 、发布/订阅系统 (如 Kafka、RabbitMQ) ，或键值存储 (如 Redis) 。还可以与数据湖 (如 Iceberg) 或对象存储中的文件 (如 AWS S3、Google GCP) 交互
- Virtual Tables Engines
正交组件：提供辅助功能
- Thread pools
- Caches
- RBAC (Role-Based Access Control)
- Backups
- Monitoring
访问层：通过不同协议管理用户会话并与应用程序通信
- User Session
- Wire protocols

我们更进一步，丢掉分布式特性、集成和监控，只保留最影响 OLAP 查询性能的核心设计，如下所示：

Columnar Storage on Yeqown

列式数据库是怎么炼成的

1. ClickHouse 的设计#

1.1 整体组件#