T
traeai
登录
返回首页
Databricks

湖仓架构如何实现 Postgres 写入性能提升 5 倍

8.5Score
湖仓架构如何实现 Postgres 写入性能提升 5 倍

TL;DR · AI 摘要

Lakebase 架构通过优化写入路径和并行处理，使 Postgres 写入性能提升 5 倍。

核心要点

  • Lakebase 使用 Delta Lake 格式实现事务性写入，减少锁竞争。
  • 架构支持批量与流式数据的统一处理，提升吞吐量达 5 倍。
  • Databricks 平台结合 AI 和 BI 功能，进一步增强数据库性能。

结构提纲

按章节快速跳转。

  1. §引言

    介绍 Lakebase 架构如何提升 Postgres 写入性能。

  2. ·核心机制

    Delta Lake 格式优化写入路径，减少锁竞争。

  3. ·统一处理

    批处理与流式数据的整合提升吞吐量。

  4. ·平台优势

    Databricks 平台结合 AI 和 BI 提升整体性能。

思维导图

用一张图看清主题之间的关系。

查看大纲文本（无障碍 / 无 JS 友好）
  • Lakebase Architecture
    • Core Mechanism
      • Delta Lake Format
    • Unified Processing
      • Batch & Streaming Data
    • Platform Features
      • AI & BI Integration

金句 / Highlights

值得收藏与分享的关键句。

#Databricks#Postgres#湖仓#数据库
打开原文

湖仓架构如何实现 Postgres 写入速度提升 5 倍 | Databricks 博客

跳转到主要内容

[![图片 1](blob:http://localhost/c3d26385bd032c882a09c45135533626)](http://www.databricks.com/)

[![图片 2](blob:http://localhost/c3d26385bd032c882a09c45135533626)](http://www.databricks.com/)

  • 为什么选择 Databricks
  • * 探索
  • 客户
  • 合作伙伴
  • 产品
  • * Databricks 平台
  • 集成与数据
  • 定价
  • 开源
  • 解决方案
  • * 面向行业的 Databricks
  • 跨行业解决方案
  • 迁移与部署
  • 解决方案加速器
  • 资源
  • 学习
  • 活动
  • 博客与播客
  • 获取帮助
  • 深入研究
  • 关于
  • 公司
  • 职业机会
  • 媒体
  • 安全与信任
  • DATA + AI 峰会 ![图片 3: Data+ai summit promo 6月15日至18日 | 旧金山 加入全球最大的数据、应用和 AI 盛会。注册](http://www.databricks.com/dataaisummit?itm_source=www&itm_category=home&itm_page=home&itm_location=navigation&itm_component=navigation&itm_offer=dataaisummit)
  1. 所有博客
  2. / 工程

目录

目录

目录

工程 2026年5月7日

湖库架构如何实现 Postgres 写入速度提升 5 倍

解决托管 Postgres 的结构性性能瓶颈

作者：David Wein 和 Vlad Lazar

摘要

  • Lakebase 现在为写密集型 OLTP 工作负载提供高达 5 倍的吞吐量提升，这是高规模 Postgres 应用程序的常见痛点。
  • 湖库架构使我们能够将关键的崩溃恢复任务从计算层卸载到分布式存储。
  • 生产采样显示，在 32 vCPU 计算上写入吞吐量提高了 4.5 倍，WAL 流量减少了 94%，同时将读尾延迟降低了 2 倍，且不牺牲持久性。

在lakebase中，计算和存储是按设计分离的。虽然这种分离最初是为了实现操作灵活性，包括扩展、分支和即时恢复，但它也解锁了巨大的性能前沿。

通过解耦这些层，我们可以以传统单体 Postgres 部署无法实现的方式，将工作从您的 Postgres 计算卸载到我们的分布式存储。在本文中，我们将探讨如何利用这一架构优势消除 Postgres 存在十年之久的瓶颈。

**传统 Postgres 持久性的隐藏成本**

为了理解我们在托管 Postgres 性能方面如何实现 5 倍的改进，我们需要看看传统 Postgres 是如何处理持久性的。

每个 Postgres 写操作首先会进入预写日志（因此得名“预写”）。为了限制崩溃恢复时间，Postgres 还会通过检查点定期将脏页刷新到磁盘。恢复过程通过从磁盘加载页面并重做自页面写入以来修改该页面的 WAL 记录来完成。然而，如果系统在页面写入磁盘时崩溃，磁盘上的页面可能会被“撕裂”，恢复将在一个损坏的页面上进行重做。因此，在检查点之后对任何页面的第一次写入时，Postgres 必须记录整个 8 KB 的完整页面图像（即“完整页面写入”或“FPW”），以确保它在一个正确的基线页面上执行重做。在写密集型工作负载下，这种 FPI 开销可能会使 WAL 卷增加多达 15 倍，并成为许多工作负载中写路径的主要成本。

**湖仓架构解决方案：消除撕裂页面的风险**

在湖仓架构中，计算是无状态的。它不依赖于本地数据目录。相反，它将 WAL 流式传输到基于 Paxos 的安全守护程序集群。

由于没有本地磁盘页面可以撕裂，FPW 设计要防止的故障模式根本不存在。然而，简单地关闭 FPW 会产生一个次级问题：读取性能。如果没有日志中的那些周期性完整页面图像，存储层将不得不回放无限长的小增量链以重建页面以响应读请求。原本有界的 O(检查点频率) 回放变成了无界的链，导致读延迟和资源消耗激增。

**创新：将图像生成推送到分布式存储**

我们通过将智能从计算节点转移到存储层来解决这个问题。我们称之为图像生成推送。

当 Postgres 计算从存储请求页面时，页面服务器（Lakebase 分布式存储系统的一个组件）通过找到该页面的最新物化图像并在此基础上重放任何 WAL 增量来重建页面。计算曾经嵌入 WAL 中的完整页面图像充当了增量链中的周期性重置点，自然地保持了链的合理界限并加快了读取速度。对于更深入的机制探讨，请参阅深入解析 Neon 存储引擎。

禁用完整页面写入后，这些重置点消失了。如果没有分布式存储系统中的额外智能，频繁更新的页面可能会积累一个没有中间图像的长小增量链。结果将是读延迟和资源消耗的不可接受的增加，因为页面服务器需要回放整个链来响应读请求，从而增加延迟和资源消耗。

为了避免这个问题，我们将图像生成的责任从计算的 WAL 流推送到存储层，从而在消除计算上的 WAL 开销的同时保留存储的有界读行为。现在，当页面累积的增量记录超过配置的阈值而没有中间图像时，页面服务器会生成完整的页面图像。这是一种更自然的方法，因为生成新图像的决策基于页面的实际更改次数，而不是与 Postgres 检查点过程无关的因素。

这是为什么这对性能显著更好的原因：

  1. 网络效率： 计算仅发送紧凑的增量，即实际的更改，这在我们的基准测试中导致了94% 的流量减少。
  2. 可扩展性： 工作从单个 Postgres 写入者转移到独立可扩展的分布式存储层。项目分支的图像生成现在在多个页面服务器之间共享。
  3. 最佳读取： 图像生成的时间现在基于页面的实际更改，而不是与 Postgres 检查点过程无关的因素。

**量化影响：从实验室到生产**

我们使用 HammerDB TPROC-C（一种基于 TPC-C 的 OLTP 基准测试）对该优化进行了基准测试，并在现实世界的生产工作负载中验证了结果。

**1. 无服务器计算扩展**

吞吐量以每分钟新订单数（NOPM）衡量。收益随着计算实例大小的增加而显著提升：

计算规模 | 之前 (NOPM) | 之后 (NOPM) | 吞吐量提升 --- | --- | --- | --- 4-vCPU | 78,876 | 94,891 | 20% 16-vCPU | 95,832 | 269,189 | 2.8x 32-vCPU | 95,686 | 439,300 | 4.5x+

Image 4: image_106

展开

在 32 vCPU 的计算环境中，改进超过了 450%。

在计算上生成完整页面图像时，每个事务平均生成 58Kb 的 WAL。通过将图像生成推送到存储层，这一数字下降到不到 4Kb——减少了 94%。吞吐量的提升直接与此相关：更少的 WAL 意味着写路径上的竞争减少、消耗的网络带宽减少以及存储层需要处理的工作减少。

Image 5: image_107

展开

通过消除 Postgres 的 FPW 瓶颈，我们允许吞吐量随计算资源线性扩展。这是单体 Postgres 在高写负载下难以实现的。

**2. 现实世界生产验证**

在一个高知名度的 56 vCPU 生产项目中，启用图像推送功能将稳定状态下的 WAL 生成量从 30 MB/s 减少到仅 1 MB/s。

Image 6: image_108

展开

生产客户 WAL 速率：（越低越好）

这一容量的减少直接对应于每日高峰期间事务吞吐量的增加。

这不仅帮助了写操作。通过优化增量链，每次读取必须应用的 WAL 记录数量显著减少。我们观察到 p99 读取延迟降低了 30% 到 50%，p50 读取延迟降低了约 30%。

Image 7: image_109

展开

生产客户吞吐量：（越高越好）

从区域层面来看，在启用优化后，我们观察到计算生成的 WAL 总量最多减少了 4 倍。存储引擎读取的 P99 延迟最多提高了 3 倍，并且变得更加稳定。

Image 8: image_110

展开

区域 WAL 吞吐率：（越低越好）

**3. 湖库同步表**

对于数据密集型的同步表，影响是立竿见影的。一位客户通过启用图像下推功能，将写入吞吐量从每秒 17k 行提升到了 62k 行，增幅达到了 3 倍。

**无缝部署：无中断的性能提升**

自 3 月下旬以来，我们已将这一优化推广到整个集群。目前，全球所有湖库无服务器和 Neon 数据库均已激活该功能。

此更改通过我们的控制平面和存储系统应用到正在运行的计算节点上，系统自动协调了过渡过程。这是通过现有的 Postgres XLOG_FPW_CHANGE WAL 记录机制实现的，因此无需重启或中断客户的操作。

**托管 Postgres 性能的下一步是什么？**

湖库架构旨在提供灵活性，但其核心目标是性能优化。全页写入下推只是系统性努力的一部分，旨在挖掘存储与计算分离带来的好处。

正如我们引入了零停机修补的缓存预热，我们将继续将繁重的任务从您的事务中移除，并转移到我们可扩展的后台存储堆栈中。Postgres 写入税正式成为过去式。

获取最新文章

订阅我们的博客，获取最新的文章直接发送到您的邮箱。

注册

*

工作邮箱

*

国家 国家*

点击“订阅”即表示我同意接收 Databricks 的通信，并同意 Databricks 根据其隐私政策处理我的个人数据。

订阅

查看所有博客

Image 9: databricks logo

为什么选择 Databricks

探索

客户

合作伙伴

为什么选择 Databricks

探索

客户

合作伙伴

产品

Databricks 平台

定价

开源

集成与数据

产品

Databricks 平台

定价

开源

集成与数据

解决方案

Databricks 行业解决方案

跨行业解决方案

数据迁移

专业服务

解决方案加速器

资源

文档

客户支持

社区

学习

活动

博客和播客

资源

文档

客户支持

社区

学习

活动

博客和播客

关于

公司

职业发展

新闻

安全与信任

关于

公司

职业发展

新闻

安全与信任

图片 11：Databricks 标志

Databricks Inc.

160 Spear Street, 15th Floor

San Francisco, CA 94105

1-866-330-0121

  • [](https://www.linkedin.com/company/databricks)
  • [](https://www.facebook.com/pages/Databricks/560203607379694)
  • [](https://twitter.com/databricks)
  • [](https://www.databricks.com/feed)
  • [](https://www.glassdoor.com/Overview/Working-at-Databricks-EI_IE954734.11,21.htm)
  • [](https://www.youtube.com/@Databricks)
图片 13

查看职业机会

在 Databricks

  • [](https://www.linkedin.com/company/databricks)
  • [](https://www.facebook.com/pages/Databricks/560203607379694)
  • [](https://twitter.com/databricks)
  • [](https://www.databricks.com/feed)
  • [](https://www.glassdoor.com/Overview/Working-at-Databricks-EI_IE954734.11,21.htm)
  • [](https://www.youtube.com/@Databricks)

© Databricks 2026. 保留所有权利。Apache、Apache Spark、Spark、Spark 标志、Apache Iceberg、Iceberg 和 Apache Iceberg 标志是 Apache Software Foundation 的商标。

我们重视您的隐私

Databricks 使用 Cookie 和类似技术来增强网站导航、分析网站使用情况、个性化内容和广告，具体详见我们的 Cookie 声明。要禁用非必要的 Cookie，请点击“拒绝全部”。您也可以通过点击“管理偏好”来管理您的 Cookie 设置。

管理偏好

拒绝全部 接受全部

图片 16：Databricks 公司标志

隐私偏好中心

已尊重退出偏好信号

隐私偏好中心

  • ### 您的隐私
  • ### 必需 Cookie
  • ### 性能 Cookie
  • ### 功能性 Cookie
  • ### 定向 Cookie
  • ### TOTHR

#### 您的隐私

当您访问任何网站时，它可能会在您的浏览器上存储或检索信息，通常以 Cookie 的形式。这些信息可能与您、您的偏好或您的设备有关，主要用于使网站按您期望的方式运行。这些信息通常不会直接识别您，但可以为您提供更个性化的网络体验。由于我们尊重您的隐私权，您可以选择不允许某些类型的 Cookie。单击不同的类别标题以了解更多信息并更改我们的默认设置。但是，阻止某些类型的 Cookie 可能会影响您对网站的体验以及我们能够提供的服务。

#### 退出销售、共享和定向广告

根据您的位置，您可能有权退出“出售”或“共享”您的个人信息或将您的个人信息用于在线“定向广告”的处理。您可以通过在此处禁用可选 Cookie 来基于 Cookie 和类似标识符退出。要基于其他标识符（例如您的电子邮件地址）退出，请在我们的 隐私请求中心 提交请求。

更多信息

#### 必需 Cookie

始终启用

这些 Cookie 对于网站的功能至关重要，无法在我们的系统中关闭。它们协助实现基本的网站功能，例如设置您的隐私偏好、登录或填写表单。您可以将浏览器设置为阻止或提醒您注意这些 Cookie，但网站的某些部分将不再工作。

#### 性能 Cookie

  • [x] 性能 Cookie

这些 Cookie 允许我们统计访问次数和流量来源，以便我们可以衡量和改进网站的性能。它们帮助我们了解哪些页面最受欢迎和最不受欢迎，并查看访客如何浏览网站。

#### 功能性 Cookie

  • [x] 功能性 Cookie

这些 Cookie 使网站能够提供增强的功能和个性化服务。它们可能由我们或添加到我们页面中的第三方提供商设置。如果您不允许这些 Cookie，那么其中部分或全部服务可能无法正常运行。

#### 定向 Cookie

  • [x] 定向 Cookie

这些 Cookie 可能通过我们的网站由我们的广告合作伙伴设置。它们可能被这些公司用于构建您的兴趣档案，并在其他网站上向您展示相关的广告。如果您不允许这些 Cookie，您将体验到较少的定向广告。

#### TOTHR

  • [x] TOTHR

Cookie 列表

同意 法律依据 兴趣

  • [x] 复选框 标签 标签
  • [x] 复选框 标签 标签
  • [x] 复选框 标签 标签

清除

  • - [x] 复选框 标签 标签

应用 取消

确认我的选择

允许全部

图片 17: Onetrust 提供支持
图片 19

图片 20图片 21

图片 22

AI 可能会生成不准确的信息，请核实重要内容