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

从单体架构到 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 功能集不完整、缺乏生态系统、缺乏性能隔离等问题。结语去年提出 Lakebase 架构时就知道它将实现多种优势。LTAP 想法后来产生解决了基于最新事务数据进行分析的问题。未来几个月解决 LTAP 小问题并推出该功能后Lakebase 表将以高性能用于分析该架构还有很多优化机会值得期待。