列式 OLAP

业务库扛 OLTP（点查、小事务），报表、漏斗、留存、大盘 往往要扫亿级行——ClickHouse 等 列式 OLAP 引擎按列压缩、向量化执行，让 分析查询 与 在线交易 分离。

学习目标

• 理解列存 vs 行存：压缩、扫描、写入模式差异
• 知道 ClickHouse 的 MergeTree 与典型 SQL 分析写法
• 衔接 postgresql-essentials 报表与 elasticsearch-essentials 日志聚合

行存 vs 列存

	OLTP 行存（PostgreSQL）	OLAP 列存（ClickHouse）
优化目标	单行读写、索引点查	大范围聚合、GROUP BY
写入	频繁小事务	批量 append、后台 merge
典型查询	SELECT * WHERE id = ?	COUNT DISTINCT user_id BY date
JOIN	成熟	有限，常 ETL 宽表

不要把 ClickHouse 当主库：无完整 OLTP 事务语义，与 orm-essentials 的 JPA 实体生命周期不匹配。

ClickHouse 要点

-- MergeTree 表示例：按日分区、用户排序
CREATE TABLE events (
  event_date Date,
  user_id UInt64,
  event_type String,
  props String
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(event_date)
ORDER BY (event_date, user_id);

-- 典型分析
SELECT event_date, count(DISTINCT user_id)
FROM events
WHERE event_date >= today() - 7
GROUP BY event_date;

数据常经 CDC、Kafka、定时 ETL 从 MySQL/PostgreSQL 同步；读路径见 scale-read-write 的读写分离思想——分析走专用库。

与 Elasticsearch 分工

场景	更常见
全文检索、日志关键词	es-intro
结构化指标、多维聚合、BI	ClickHouse
实时仪表板秒级	ES + 或 ClickHouse 物化视图

两者可并存：ES 探查日志，ClickHouse 落盘长期分析。

练习

• 写一条「近 7 日每日 UV」伪 SQL，标出适合列存的 reason
• 说明为何 OLTP 库直接跑全表 GROUP BY 会拖垮业务