【列存引擎内核】ClickHouse 与 DuckDB 选型决策

前两篇 DuckDB 专题（架构（第 11 篇）、Pipeline（第 12 篇））与 ClickHouse 主系列（MergeTree、Distributed、运维）放在一起，读者自然问：同一 OLAP 问题该用谁？

本文给 决策树与组合架构，不做「谁快 10 倍」类结论——WRITING_GUIDE 要求性能判断须实测或引用；此处两者工作负载差异太大，虚构数字无意义。

一、问题 framing：不是替代关系

flowchart TB
  Q[分析需求]
  Q -->|远程多用户 PB 级| CH[ClickHouse 集群]
  Q -->|进程内 TB 级| DUCK[DuckDB]
  Q -->|PG 库内加速| PGD[pg_duckdb]
  Q -->|湖仓 Parquet 探查| DUCK
  CH --> PG[(PostgreSQL CDC)]
  DUCK --> PG

二、五维对比矩阵

2.1 部署与接入

2.2 数据规模与持久化

Refer Merge（第 06 篇） vs DuckDB checkpoint。

2.3 并发与 QPS

不列 QPS 数字——须用业务 query mix 压测。

2.4 SQL 与生态

2.5 运维与故障域

三、决策树（文字版）

START
├─ 是否需要独立 SQL 服务供多团队/BI 远程访问？
│   ├─ 是 → 倾向 ClickHouse（或 Trino/StarRocks 等，本文边界外）
│   └─ 否 → 继续
├─ 数据是否已在 Parquet/CSV 文件 / S3，仅偶尔分析？
│   ├─ 是 → 倾向 DuckDB（read_parquet/httpfs）
│   └─ 否 → 继续
├─ 持续 ingest > 单机磁盘 IO 或需副本 HA？
│   ├─ 是 → ClickHouse ReplicatedMergeTree + Distributed
│   └─ 否 → 继续
├─ 是否必须嵌在 Python/R 进程且无运维？
│   ├─ 是 → DuckDB
│   └─ 否 → 继续
├─ 是否已有 PostgreSQL 且只想加速 ANALYTICAL 查询？
│   ├─ 是 → 评估 pg_duckdb vs CH 外表副本
│   └─ 否 → 按团队技能 CH/DuckDB 二选一
END

四、组合架构模式

4.1 PG + ClickHouse 分析副本

• OLTP 在 PG（postgresql-kernel）；
• CDC / 批量导出到 CH MergeTree；
• 复杂聚合、日志级 scan 走 CH。

DuckDB 不承担中心仓，除非规模小。

4.2 PG + pg_duckdb

• 同一实例，分析查询路由 DuckDB 执行；
• 适合 数据量中小、不想运维第二套集群；
• 与 CH 副本相比：少网络 hop，多 PG 资源争用。

4.3 DuckDB 边缘 + ClickHouse 中心

• 边缘设备 DuckDB 预聚合；
• 周期性 upload 汇总行到 CH Distributed；
• IoT / 门店场景。

4.4 数据科学 DuckDB + 生产 CH

• 分析师本地 DuckDB 拉 Parquet sample；
• 生产 truth 在 CH——避免直连生产大 scan。

五、与 PostgreSQL 生态位

PG B-Tree 索引语义 与 CH 排序键（第 07 篇） 不同——迁 schema 时勿照搬 PRIMARY KEY 含义。

六、与 LSM / 行存边界

LSM 系列 写优化 ingest（Kafka → CH 也常并存）；DuckDB 不取代 Kafka consumer 集群。行存 InnoDB/PG 做源库，列存做 读优化副本——铁三角见 系列 index。

七、成本维度（非 benchmark）

八、何时两者都用

合法且常见：

1. CH 生产仓 + DuckDB 本地复现 bug（拉 sample Parquet）；
2. CH 存全量 + DuckDB 做 ML feature export；
3. 不同团队技能栈——数据平台 CH，研究 DuckDB。

避免：双写全量 无同步机制——必不一致。

九、反模式

十、评估清单（POC 设计）

POC 应 固定 query mix 与数据规模，记录：

1. 环境：CPU、RAM、磁盘、版本号；
2. 负载：并发、insert batch size、SELECT 比例；
3. 指标：p50/p95 延迟、吞吐、磁盘、失败率；
4. 运维：备份、升级、故障注入（杀进程、断网）；
5. 结论：业务 SLA 是否满足——不输出跨团队通用排名。

十一、学术坐标：选型旁的论文地图（非排名）

决策树回答「部署形态」；下表回答「文献里各自优化什么」——不能用来宣称谁更快。

11.1 争论：统一引擎 vs 双栈

• 统一引擎：一个系统扛 OLTP+OLAP 或「一个 OLAP 打天下」——HTAP / 湖仓路线见 db-frontier/12、lakehouse。
• 双栈（本系列默认工程判断）：PG/行存 OLTP + CH 服务分析 + DuckDB 本地探查——与 C-Store「读写存储分离」精神一致，但是 产品边界分离，不是单进程 WS/RS。

无顶会结论要求所有组织选同一栈；POC 须固定 query mix（第十节）。

11.2 开放问题

1. pg_duckdb 是否侵蚀「独立 CH 集群」的中小规模市场？ 可检验：同一报表在 PG 扩展 vs CH 副本的运维人天与 SLA（入口：pg_duckdb 文档；本篇决策树）。
2. 湖上 DuckDB / CH 谁更适合作为 Iceberg 交互层？ 见 query-engine / lakehouse；本篇不展开。
3. 向量化引擎是否应统一 morsel API？ 研究侧开放；生产以各项目 release 为准。

十二、小结

• 服务化、大规模、高 ingest、副本 HA → ClickHouse 主系列能力栈；
• 嵌入、文件分析、联邦探查、轻运维 → DuckDB；
• PG 内分析 → pg_duckdb vs CH 副本按规模与组织分工。

无银弹；组合架构多于单选。论文坐标（C-Store / X100 / morsel / Kersten）解释 为何分工，不替代 POC。

附录 A、场景叙事（无性能数字）

A.1 中心化日志平台

特征：PB 级、数千 QPS ingest、多团队 SQL、副本 HA。
选型：ClickHouse ReplicatedMergeTree + Distributed + Kafka MV（第 10 篇）。
DuckDB 位置：分析师本地 sample Parquet，不扛生产 ingest。

A.2 电商 PG 库内报表

特征：单 PG 实例、<1TB 分析表、无专职 CH 运维。
选型：pg_duckdb 或 periodic export + DuckDB notebook。
何时升级到 CH：PG CPU/IO 被分析打满、需独立 SLA。

A.3 数据科学笔记本

特征：S3 Parquet、单用户、交互探索。
选型：DuckDB read_parquet / httpfs。
CH 仅在需共享 dashboard 服务时叠加。

A.4 边缘门店汇总

特征：断网、本地聚合、周期性 upload。
选型：门店 DuckDB 预聚合；中心 ClickHouse 收汇总行。
注意 upload batch 避免中心 too many parts。

A.5 合规数据不出 VPC

特征：敏感数据、禁止第三方 SaaS 分析。
两者均可自建；CH 集群运维更重，DuckDB 嵌入应用更轻——按 运维编制 而非技术绝对优劣。

A.6 HTAP 幻想警示

特征：期望一套系统 OLTP+实时大屏。
现实：PG/Citus OLTP + CH 副本仍主流；DuckDB 不替代 PG 事务；CH 不做行级事务。

附录 B、团队技能矩阵

附录 C、迁移路径

PG → CH：CDC（Debezium）或批量 COPY → MergeTree；排序键 redesign（第 07 篇）。
CH → DuckDB：FORMAT Parquet 导出 → read_parquet；丢失 Distributed/副本，仅便携分析。
DuckDB → CH：EXPORT DATABASE / Parquet 中间格式 → CH INSERT；须重设 PARTITION/ORDER BY。

附录 D、合规与驻留

两者均可 on-prem。DuckDB 数据在单文件易拷贝——权限与磁盘加密由宿主应用负责。CH 集群需 RBAC、network isolation、backup 策略（监控 第 14 篇）。

附录 E、FAQ

Q：MotherDuck / ClickHouse Cloud？
托管控制面不在本系列；选型看数据驻留与合同，不评内部实现。
Q：Trino/StarRocks？
联邦或替代 OLAP——超出本系列；CH vs DuckDB 聚焦 MergeTree vs 嵌入 DuckDB。
Q：只用 Parquet lake 呢？
DuckDB 探查 + CH Serving 层是常见 lakehouse 分工。

附录 F、检查清单（POC 出口）

• 峰值 ingest 与 batch 规范 written
• 核心 query p95 在本环境有数（非本文）
• parts/merge 72h 稳定（CH）
• 故障注入：杀单节点 / OOM 查询（CH）
• DuckDB spill 路径磁盘足够
• 运维 on-call 范围明确

附录 G、角色 RACI 示例

R=负责 A=批准 C=协商 I=知会——组织模板，非技术结论。

附录 H、许可证与合规

ClickHouse Apache 2.0；DuckDB MIT——一般企业友好；法务仍审 third-party。数据驻留取决于部署位置非许可证。

附录 I、多租户隔离

CH：database + row policy + network。DuckDB：每租户单文件或单进程——隔离强但运维 multiplication。

附录 J、版本升级策略

CH 滚动升级 LTS track；DuckDB 随应用发版 pin 版本—— regression test on export/import。

附录 K、Skills 培训路径

CH：MergeTree parts + Distributed + system 表（本系列）。DuckDB：SQL + Python + Parquet。PG DBA 转 CH 先纠正索引/事务心智。

附录 L、When both in same company

平台组 CH；研究组 DuckDB；规范 Parquet 作为交换格式 避免双写 truth。

附录 M、Anti-pattern 补充

附录 N、Open table format 未来

Iceberg/Delta 表上 DuckDB/Trino/CH 外表——lakehouse 选型超出本系列 core，但 Serving 层 仍常 CH。

附录 · 深度补充（系列交叉索引）

深度 1

第 13 章与系列其它篇章的交叉：读路径见 第 05 篇；merge 见 第 06 篇；索引见 第 07 篇；副本见 第 08 篇；Distributed 见 第 09 篇；监控见 第 14 篇；故障见 第 15 篇；配置见 第 16 篇。 实施任何 setting 变更前，在 staging 用 system.parts / query_log 建立 24h 基线，变更后再对比——避免无证据调参。

深度 2

第 13 章与系列其它篇章的交叉：读路径见 第 05 篇；merge 见 第 06 篇；索引见 第 07 篇；副本见 第 08 篇；Distributed 见 第 09 篇；监控见 第 14 篇；故障见 第 15 篇；配置见 第 16 篇。 实施任何 setting 变更前，在 staging 用 system.parts / query_log 建立 24h 基线，变更后再对比——避免无证据调参。

深度 3

第 13 章与系列其它篇章的交叉：读路径见 第 05 篇；merge 见 第 06 篇；索引见 第 07 篇；副本见 第 08 篇；Distributed 见 第 09 篇；监控见 第 14 篇；故障见 第 15 篇；配置见 第 16 篇。 实施任何 setting 变更前，在 staging 用 system.parts / query_log 建立 24h 基线，变更后再对比——避免无证据调参。

深度 4

第 13 章与系列其它篇章的交叉：读路径见 第 05 篇；merge 见 第 06 篇；索引见 第 07 篇；副本见 第 08 篇；Distributed 见 第 09 篇；监控见 第 14 篇；故障见 第 15 篇；配置见 第 16 篇。 实施任何 setting 变更前，在 staging 用 system.parts / query_log 建立 24h 基线，变更后再对比——避免无证据调参。

深度 5

第 13 章与系列其它篇章的交叉：读路径见 第 05 篇；merge 见 第 06 篇；索引见 第 07 篇；副本见 第 08 篇；Distributed 见 第 09 篇；监控见 第 14 篇；故障见 第 15 篇；配置见 第 16 篇。 实施任何 setting 变更前，在 staging 用 system.parts / query_log 建立 24h 基线，变更后再对比——避免无证据调参。

深度 6

第 13 章与系列其它篇章的交叉：读路径见 第 05 篇；merge 见 第 06 篇；索引见 第 07 篇；副本见 第 08 篇；Distributed 见 第 09 篇；监控见 第 14 篇；故障见 第 15 篇；配置见 第 16 篇。 实施任何 setting 变更前，在 staging 用 system.parts / query_log 建立 24h 基线，变更后再对比——避免无证据调参。

深度 7

第 13 章与系列其它篇章的交叉：读路径见 第 05 篇；merge 见 第 06 篇；索引见 第 07 篇；副本见 第 08 篇；Distributed 见 第 09 篇；监控见 第 14 篇；故障见 第 15 篇；配置见 第 16 篇。 实施任何 setting 变更前，在 staging 用 system.parts / query_log 建立 24h 基线，变更后再对比——避免无证据调参。

深度 8

第 13 章与系列其它篇章的交叉：读路径见 第 05 篇；merge 见 第 06 篇；索引见 第 07 篇；副本见 第 08 篇；Distributed 见 第 09 篇；监控见 第 14 篇；故障见 第 15 篇；配置见 第 16 篇。 实施任何 setting 变更前，在 staging 用 system.parts / query_log 建立 24h 基线，变更后再对比——避免无证据调参。

深度 9

第 13 章与系列其它篇章的交叉：读路径见 第 05 篇；merge 见 第 06 篇；索引见 第 07 篇；副本见 第 08 篇；Distributed 见 第 09 篇；监控见 第 14 篇；故障见 第 15 篇；配置见 第 16 篇。 实施任何 setting 变更前，在 staging 用 system.parts / query_log 建立 24h 基线，变更后再对比——避免无证据调参。

深度 10

第 13 章与系列其它篇章的交叉：读路径见 第 05 篇；merge 见 第 06 篇；索引见 第 07 篇；副本见 第 08 篇；Distributed 见 第 09 篇；监控见 第 14 篇；故障见 第 15 篇；配置见 第 16 篇。 实施任何 setting 变更前，在 staging 用 system.parts / query_log 建立 24h 基线，变更后再对比——避免无证据调参。

深度 11

第 13 章与系列其它篇章的交叉：读路径见 第 05 篇；merge 见 第 06 篇；索引见 第 07 篇；副本见 第 08 篇；Distributed 见 第 09 篇；监控见 第 14 篇；故障见 第 15 篇；配置见 第 16 篇。 实施任何 setting 变更前，在 staging 用 system.parts / query_log 建立 24h 基线，变更后再对比——避免无证据调参。

深度 12

第 13 章与系列其它篇章的交叉：读路径见 第 05 篇；merge 见 第 06 篇；索引见 第 07 篇；副本见 第 08 篇；Distributed 见 第 09 篇；监控见 第 14 篇；故障见 第 15 篇；配置见 第 16 篇。 实施任何 setting 变更前，在 staging 用 system.parts / query_log 建立 24h 基线，变更后再对比——避免无证据调参。

深度 13

第 13 章与系列其它篇章的交叉：读路径见 第 05 篇；merge 见 第 06 篇；索引见 第 07 篇；副本见 第 08 篇；Distributed 见 第 09 篇；监控见 第 14 篇；故障见 第 15 篇；配置见 第 16 篇。 实施任何 setting 变更前，在 staging 用 system.parts / query_log 建立 24h 基线，变更后再对比——避免无证据调参。

深度 14

第 13 章与系列其它篇章的交叉：读路径见 第 05 篇；merge 见 第 06 篇；索引见 第 07 篇；副本见 第 08 篇；Distributed 见 第 09 篇；监控见 第 14 篇；故障见 第 15 篇；配置见 第 16 篇。 实施任何 setting 变更前，在 staging 用 system.parts / query_log 建立 24h 基线，变更后再对比——避免无证据调参。

深度 15

第 13 章与系列其它篇章的交叉：读路径见 第 05 篇；merge 见 第 06 篇；索引见 第 07 篇；副本见 第 08 篇；Distributed 见 第 09 篇；监控见 第 14 篇；故障见 第 15 篇；配置见 第 16 篇。 实施任何 setting 变更前，在 staging 用 system.parts / query_log 建立 24h 基线，变更后再对比——避免无证据调参。

深度 16

第 13 章与系列其它篇章的交叉：读路径见 第 05 篇；merge 见 第 06 篇；索引见 第 07 篇；副本见 第 08 篇；Distributed 见 第 09 篇；监控见 第 14 篇；故障见 第 15 篇；配置见 第 16 篇。 实施任何 setting 变更前，在 staging 用 system.parts / query_log 建立 24h 基线，变更后再对比——避免无证据调参。

深度 17

第 13 章与系列其它篇章的交叉：读路径见 第 05 篇；merge 见 第 06 篇；索引见 第 07 篇；副本见 第 08 篇；Distributed 见 第 09 篇；监控见 第 14 篇；故障见 第 15 篇；配置见 第 16 篇。 实施任何 setting 变更前，在 staging 用 system.parts / query_log 建立 24h 基线，变更后再对比——避免无证据调参。

深度 18

第 13 章与系列其它篇章的交叉：读路径见 第 05 篇；merge 见 第 06 篇；索引见 第 07 篇；副本见 第 08 篇；Distributed 见 第 09 篇；监控见 第 14 篇；故障见 第 15 篇；配置见 第 16 篇。 实施任何 setting 变更前，在 staging 用 system.parts / query_log 建立 24h 基线，变更后再对比——避免无证据调参。

深度 19

第 13 章与系列其它篇章的交叉：读路径见 第 05 篇；merge 见 第 06 篇；索引见 第 07 篇；副本见 第 08 篇；Distributed 见 第 09 篇；监控见 第 14 篇；故障见 第 15 篇；配置见 第 16 篇。 实施任何 setting 变更前，在 staging 用 system.parts / query_log 建立 24h 基线，变更后再对比——避免无证据调参。

深度 20

第 13 章与系列其它篇章的交叉：读路径见 第 05 篇；merge 见 第 06 篇；索引见 第 07 篇；副本见 第 08 篇；Distributed 见 第 09 篇；监控见 第 14 篇；故障见 第 15 篇；配置见 第 16 篇。 实施任何 setting 变更前，在 staging 用 system.parts / query_log 建立 24h 基线，变更后再对比——避免无证据调参。

深度 21

第 13 章与系列其它篇章的交叉：读路径见 第 05 篇；merge 见 第 06 篇；索引见 第 07 篇；副本见 第 08 篇；Distributed 见 第 09 篇；监控见 第 14 篇；故障见 第 15 篇；配置见 第 16 篇。 实施任何 setting 变更前，在 staging 用 system.parts / query_log 建立 24h 基线，变更后再对比——避免无证据调参。

深度 22

第 13 章与系列其它篇章的交叉：读路径见 第 05 篇；merge 见 第 06 篇；索引见 第 07 篇；副本见 第 08 篇；Distributed 见 第 09 篇；监控见 第 14 篇；故障见 第 15 篇；配置见 第 16 篇。 实施任何 setting 变更前，在 staging 用 system.parts / query_log 建立 24h 基线，变更后再对比——避免无证据调参。

深度 23

第 13 章与系列其它篇章的交叉：读路径见 第 05 篇；merge 见 第 06 篇；索引见 第 07 篇；副本见 第 08 篇；Distributed 见 第 09 篇；监控见 第 14 篇；故障见 第 15 篇；配置见 第 16 篇。 实施任何 setting 变更前，在 staging 用 system.parts / query_log 建立 24h 基线，变更后再对比——避免无证据调参。

深度 24

第 13 章与系列其它篇章的交叉：读路径见 第 05 篇；merge 见 第 06 篇；索引见 第 07 篇；副本见 第 08 篇；Distributed 见 第 09 篇；监控见 第 14 篇；故障见 第 15 篇；配置见 第 16 篇。 实施任何 setting 变更前，在 staging 用 system.parts / query_log 建立 24h 基线，变更后再对比——避免无证据调参。

附录 · 工程深化索引

深化 1：规模：十亿行集群

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 2：并发：数百查询

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 3：嵌入：进程内分析

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 4：联邦：pg_duckdb

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 5：运维：parts 与 merge

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 6：成本：云托管

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 7：延迟：点查 vs 扫描

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 8：更新：mutation 代价

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 9：副本：Keeper 协调

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 10：安全：网络暴露面

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 11：生态：BI 连接

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 12：SQL 方言差异

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 13：时序：Gorilla 编码

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 14：地理：分布式 JOIN

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 15：日志：Kafka ingest

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 16：数据科学：Python API

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 17：HTAP 边界

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 18：SQLite 替代

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 19：ClickHouse Cloud

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 20：MotherDuck

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 21：决策树：先问部署形态

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 22：决策树：再问并发

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 23：决策树：最后问联邦

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 24：混合架构：CH 仓 + DuckDB 探索

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 25：不排名原则

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 26：规模：十亿行集群

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 27：并发：数百查询

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 28：嵌入：进程内分析

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 29：联邦：pg_duckdb

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 30：运维：parts 与 merge

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 31：成本：云托管

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 32：延迟：点查 vs 扫描

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 33：更新：mutation 代价

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 34：副本：Keeper 协调

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 35：安全：网络暴露面

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 36：生态：BI 连接

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 37：SQL 方言差异

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

深化 38：时序：Gorilla 编码

flowchart LR
  Q[查询/写入] --> P[parts 状态]
  P --> M[merge 后台]
  M --> MON[system.merges]
  MON --> CFG[配置调优]

上一篇：DuckDB Pipeline

下一篇：监控与系统表

参考资料

核心论文

1. Stonebraker et al., C-Store, VLDB 2005（列存架构坐标；A 级）。
2. Boncz et al., MonetDB/X100, CIDR 2005（向量化坐标；A 级）。
3. Leis et al., Morsel-Driven Parallelism, SIGMOD 2014（DuckDB 并行坐标；A 级）。
4. Kersten et al., Compiled and Vectorized Queries, PVLDB 2018（执行争论；A 级）。

规范 / 源码 / 文档

5. ClickHouse Documentation, 24.x — 部署与用例（A 级）。
6. DuckDB Documentation, 1.x — 嵌入与扩展（A 级）。
7. pg_duckdb 项目文档 — 联邦边界（B 级）。
8. 本系列 PLAN 研究台账；第 01、04、12 篇。