OLTP vs OLAP：兩種完全不同的存取模式
OLTP（Online Transaction Processing）：
- 每次操作影響幾筆 row（一筆訂單、一個用戶）
- 大量的讀寫操作並發
- 需要 ACID transaction
- 查詢都走 index，不做全表掃描
OLAP（Online Analytical Processing）：
- 每次查詢掃描幾百萬到幾十億 row
- 讀取幾個欄位的聚合值（
SUM、AVG、COUNT） - 幾乎不寫，或批次寫
- 不需要逐行 index，需要高效的欄位掃描
同一個資料庫被要求同時做好這兩件事，就像要求同一輛車既能做賽車又能做貨車——物理設計就是不相容的。
Columnar Storage：為什麼 OLAP 快
行式儲存（Row-oriented，PostgreSQL 預設）：一個 row 的所有欄位存在一起。讀整 row 快，但聚合時要讀所有欄位（其中 90% 你不需要）。
欄式儲存（Columnar）：每個欄位獨立存放，同一欄的所有值連續存在一起。
行式（PostgreSQL）：
[id=1, name=Alice, amount=100, date=2024-01-01]
[id=2, name=Bob, amount=200, date=2024-01-02]
欄式（ClickHouse）：
id: [1, 2, ...]
name: [Alice, Bob, ...]
amount: [100, 200, ...]
date: [2024-01-01, 2024-01-02, ...]
查詢 SELECT SUM(amount) FROM orders，欄式儲存只讀 amount 欄位，壓縮率高、CPU cache 友善，速度差距可以是 10x-100x。
主要產品
ClickHouse（開源）：Yandex 開發，列式儲存，MergeTree 引擎，適合時序數據和高 QPS 的實時分析。自建成本低，開源社群活躍。Altinity 提供商業支援。
DuckDB（開源）：嵌入式 OLAP，像 SQLite 一樣單檔案，不需要 server。適合本機分析、data pipeline 中間層、Jupyter notebook 裡的分析。可以直接查 Parquet / CSV 檔案。
BigQuery（Google Cloud）：Serverless，按查詢量計費，不需要管 cluster。適合偶發性的大型分析，無需預置容量。
Snowflake：Cloud-native，計算和存儲分離，multi-cloud。企業級功能完整，但成本高。
Apache Spark / Databricks：分散式計算框架，適合 ETL pipeline 和需要程式邏輯的複雜轉換。
典型架構：OLTP + OLAP 分離
用戶行為 → PostgreSQL（OLTP）
↓ ETL / CDC（每小時或實時）
ClickHouse（OLAP）
↓
BI Tool（Metabase / Grafana / Tableau）
CDC（Change Data Capture）：監聽 OLTP 資料庫的 binlog / WAL，近實時地同步到分析 DB。Debezium 是最常用的 CDC 工具，可以把 PostgreSQL 的變更串流到 Kafka，再寫進 ClickHouse。
選型建議
- 本機分析 / 小規模：DuckDB——零成本，直接查 CSV / Parquet
- 中規模自建分析平台：ClickHouse——效能最好的開源選項
- 已在 GCP 且量不固定：BigQuery——Serverless 不怕閒置浪費
- 企業級 Data Platform，需要 Data Sharing：Snowflake
- 複雜 ETL + ML pipeline：Databricks（Spark）
不要把分析查詢跑在 production PostgreSQL 上——不管你加多少 read replica，OLAP 查詢的全表掃描終究會搶 OLTP 的 buffer pool 和 CPU。