当前位置：首页 > news >正文

从单体架构到 LTAP：数据库存储革新，实现无限存储与实时数据分析

news 2026/7/4 20:44:03

从单体架构到 LTAP：数据库存储层革新，实现无限存储与实时数据分析

几乎所有传统数据库都将预写日志（WAL）和数据文件存于同一台机器的磁盘上，这正是数据丢失风险、昂贵的读副本和高可用克隆，以及分析查询拖累事务处理的根本原因。Lakebase 通过将日志和数据文件外部化为独立的云服务（SafeKeeper 和 PageServer），使 Postgres 计算无状态，实现了无限存储、弹性计算、持久写入、更简单的高可用性和即时分支，且不会显著增加延迟。LTAP 更进一步，以开放的列式格式存储运营数据，Postgres 和湖仓（Lakehouse）引擎均可读取，从而使分析能够基于事务刚刚写入的新鲜数据运行，无需变更数据捕获（CDC）管道、无需第二份副本，也不会降低事务工作负载的速度。与试图在一个引擎中统一两种工作负载的混合事务分析处理（HTAP）不同，LTAP 在存储层实现统一，并为每个任务保留最适合的引擎。

16 年前的抉择

16 年前，作者在加州大学伯克利分校攻读博士学位时，导师建议其专注于分析领域，称联机事务处理（OLTP）数据库已是解决的问题。作者听从建议，参与了后来成为 Apache Spark 的研究项目，之后创立了 Databricks。在构建 Databricks 过程中，作者发现 OLTP 数据库远非已解决问题，由此催生了 Lakebase。

单体数据库架构的痛点

当今世界上运行的绝大多数数据库都是单体架构，包括 MySQL、Postgres 和经典的 Oracle。以 Postgres 为例，磁盘上最重要的是预写日志（WAL）和数据文件。提交事务时，数据库先将更改描述追加到 WAL 中，日志条目持久写入后事务视为提交，之后异步更新数据文件。WAL 让写入更快且安全，数据文件让读取更快。但单体架构带来诸多挑战，如配置错误和节点故障导致的数据丢失、扩展读取和高可用性需要物理克隆、分析与事务性流量相互竞争等，这些问题都源于 WAL 和数据文件存储在同一台机器内。

Lakebase 架构的优势

如果重新设计 OLTP 数据库，可从现代云的组件入手。Neon 团队奠定了 Lakebase 的基础，核心思路是让 Postgres 计算实例无状态，通过将 WAL 和数据文件外部化为独立服务实现。WAL 转变为 SafeKeeper，通过基于 Paxos 的网络复制保证提交事务的持久性，不会增加写入延迟，且 SafeKeeper 和 PageServer 的组合可实现 5 倍更高的写入吞吐量和 2 倍更低的读取延迟。数据文件转变为 PageServer，可视为底层对象存储的写通缓存，通过多层缓存隔离和最小化读取延迟，能获得解耦的、几乎无限的存储优势。Lakebase 架构还带来仍然是 Postgres、无限存储、无服务器弹性计算、持久写入和零数据丢失、更简单的高可用性、即时分支克隆和恢复等优势。

LTAP：事务和分析共享一份数据

LTAP 解决了数据两份副本的问题，关键思想是在存储层统一事务和分析两个世界。PageServer 将 Postgres 数据从行格式转换为 Parquet 的列式布局，保留 Postgres 语义，包括类型系统和多版本控制。列式数据压缩效果好，可减少网络数据传输量和存储成本。分析查询时，先向 Postgres 请求当前的日志序列号（LSN），从对象存储读取绝大多数数据，从 PageServer 获取未具体化的最新更改并合并，可获得一致、完全最新的数据读取，且不影响 Postgres 的事务性工作负载。对于非常小的表，不转换为列式格式。LTAP 无需选择表，自动处理所有表，避免了 CDC 或“镜像”的问题。与 HTAP 相比，LTAP 在存储层实现统一，避免了 HTAP 功能集不完整、缺乏生态系统、缺乏性能隔离等问题。