原文地址
这篇cedardb发表的文章题为《停止嵌套数据库系统》，作者 Christian Winter 批评了近年来在事务型数据库（如 PostgreSQL）中嵌套分析型数据库（如 DuckDB、ClickHouse）的趋势，认为这种做法虽然表面上能提升分析性能，但实际上存在诸多局限，并不能真正实现 HTAP（混合事务/分析处理）系统的效果。
以下是文章的主要观点总结：
1.嵌套数据库系统的工作原理
- 以
pg_duckdb为例，它允许在 PostgreSQL 中嵌入 DuckDB 引擎，将分析查询交给 DuckDB 执行，而数据扫描仍由 PostgreSQL 完成。 - DuckDB 本身是为嵌入式场景设计的，支持 PostgreSQL 语法，具有优秀的查询优化器与分析算法。
2.嵌套系统的优势
- 分析查询性能优于 PostgreSQL，尤其是在复杂查询、并行处理和内存利用方面。
- 可以访问 PostgreSQL 不支持的功能，如直接查询远程 Parquet 文件。
3.嵌套系统的局限性
- 扫描性能瓶颈：数据扫描仍依赖 PostgreSQL，无法使用列式存储或高级扫描优化技术。
- 系统复杂度增加：需要同时维护两个并非为协同工作设计的系统。
- 功能不兼容：某些查询可能因函数、排序规则或比较方式的差异而产生不一致的结果。
- 性能提升有限：目前
pg_duckdb和pg_clickhouse在 TPC-H 测试中并未稳定优于纯 PostgreSQL。
4.嵌套系统 vs ETL
- 对于偶尔进行的分析查询（如月度报表），嵌套系统可作为临时解决方案，避免建立完整的 ETL 流程。
- 但对于持续分析需求，专门的 HTAP 或分析型系统更具优势。
- 某些方案（如
pg_clickhouse）本质上仍是“外部数据包装器”，仍需自行构建数据同步管道。
5.这是真正的 HTAP 吗？
- 作者认为不是。真正的 HTAP 需要系统在保证事务一致性的同时，优化从扫描到结果的全流程。
- 嵌套系统无法解决扫描瓶颈，且无法在分析查询中提供与事务相同的一致性保证。
6.真正 HTAP 系统的构建要素
- 作者以 CedarDB 为例，说明真正的 HTAP 系统需要：
- 同时支持点查询和分析扫描的存储布局
- 乐观同步数据结构以减少读写冲突
- 乐观快照隔离以支持长查询不阻塞写入
- 调度器平衡写入与读取的优先级
7.结论
- 嵌套数据库系统是一种“藏污纳垢”式的临时方案，不能从根本上解决分析性能与事务一致性并存的挑战。
- 如果真正需要 HTAP 能力，应选择专为 HTAP 设计的系统，而非简单嵌套现有引擎。
文章态度：作者对“嵌套数据库”持批判态度，认为这是一种技术上的妥协，而非真正的解决方案，并呼吁开发者选择真正支持 HTAP 的数据库系统。
