知识卡片

联合数据库与分拆数据库:统一读取与统一写入两条路径

结构图卡

内容

如果没有任何单一存储格式或数据模型能满足所有访问模式,把不同存储处理工具组合成一个有凝聚力的系统有两条路径。联合数据库(也叫多态存储)为各种底层存储引擎和处理方法提供统一的查询接口——PostgreSQL的外部数据包装器就是这种模式:需要专用能力的应用仍可直接访问底层引擎,想跨系统组合数据的用户则走联合接口,这条路径延续了单一集成系统的关系型传统,接口优雅但实现复杂,解决的是跨系统的只读查询问题。分拆数据库则反过来解决同步写入的问题:单个数据库里创建一致的索引是内置功能,而组合多个存储系统后,需要确保所有数据变更都可靠地到达所有正确位置(哪怕出现故障)——数据库内置的次级索引、复制日志、物化视图这些功能,与用批处理和流处理构建的衍生数据系统本质上是同一类东西,分拆的思路正是通过变更数据捕获和事件日志,把数据库内置的索引维护功能拆解成能跨不同技术、以同步写入方式协同工作的独立组件,遵循的是Unix”小工具做好一件事、靠统一低层API通信、用高层语言组合”的传统。作者认为同步写入到多个存储系统是比联合只读查询更困难的工程问题,因此把重心放在了分拆这一侧。

结构图

flowchart TD
    A[组合多种存储处理工具] --> B[联合数据库: 统一读取]
    A --> C[分拆数据库: 统一写入]
    B --> D[统一查询接口跨底层引擎,如PostgreSQL外部数据包装器]
    C --> E[基于CDC与事件日志,把索引维护拆成跨技术的可靠写入组件]
    D -.关系型传统,实现复杂但优雅.-> F[解决跨系统只读查询]
    E -.Unix传统,小工具+统一接口+高层组合.-> G[解决跨系统同步写入,更困难的工程问题]

参考来源

- 位置:《数据密集型应用系统设计》第十二章《数据系统的未来》"联合数据库:统一读取""分拆数据库:统一写入""开展分拆工作"(源文件:_epub-src/ch12_split_001.html) - 结论依据:原文分别定义联合数据库(统一查询接口,解决只读查询)与分拆数据库(基于CDC/事件日志的跨系统可靠写入,遵循Unix传统),并明确说明作者认为同步写入是更困难的工程问题,直接支撑本卡片的结构图与解释。 - 原始内容:可以为各种各样的底层存储引擎和处理方法提供一个统一的查询接口……联合只读查询需要将一个数据模型映射到另一个数据模型……而我认为同步写入到几个存储系统是更困难的工程问题。