DeepSeek对《停止嵌套数据库系统》文章的总结

原文地址

这篇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 的数据库系统。