OpenAI 将 PostgreSQL 扩展至 8 亿用户的技术实践

一、新闻概述

1. 标题

Scaling PostgreSQL to power 800 million ChatGPT users（将 PostgreSQL 扩展至支持 8 亿 ChatGPT 用户）

2. 发布时间

2025 年 12 月 12 日

3. 来源

OpenAI 官方博客

4. 作者

Bohan Zhang，OpenAI 技术团队成员

二、核心内容

1. 事件摘要

A. 主要内容

OpenAI 详细介绍了如何通过单一主节点 Azure PostgreSQL 实例和近 50 个跨多地域的只读副本，将 PostgreSQL 扩展至支持每秒数百万次查询，服务于 8 亿用户。

B. 核心亮点

  • 单主节点架构支持 8 亿用户规模
  • 每秒处理数百万次查询（QPS）
  • 跨地域部署近 50 个只读副本
  • 实现个位数毫秒级 p99 延迟
  • 达到 99.999% 可用性（五个九）

2. 关键信息

A. 规模数据

  • 用户数量：8 亿
  • 查询量：每秒数百万次
  • 副本数量：近 50 个只读副本
  • 负载增长：过去一年增长超过 10 倍

B. 技术指标

  • p99 延迟：个位数毫秒级
  • 可用性：99.999%（五个九）
  • 复制延迟：接近零
  • SEV-0 事故：过去 12 个月仅 1 次

C. 涉及技术

  • Azure PostgreSQL Flexible Server
  • PgBouncer 连接池
  • 级联复制（Cascading Replication）
  • 缓存层与缓存锁定机制

3. 背景介绍

A. PostgreSQL 简介

PostgreSQL 是由加州大学伯克利分校科学家创建的开源关系数据库系统，以其可靠性和功能丰富著称。

B. OpenAI 的使用场景

PostgreSQL 是 OpenAI 核心产品（如 ChatGPT 和 API）的关键数据系统，承载了大量读密集型工作负载。

三、详细报道

1. 主要内容

A. 架构设计

OpenAI 采用了单主节点多副本的架构：

  • 1 个主节点（Primary）处理所有写入
  • 近 50 个只读副本（Read Replicas）分布在全球多个地域
  • 使用 PgBouncer 作为连接池代理层
  • 实施多层级速率限制

B. 扩展策略

读扩展：

  • 将读请求尽可能卸载到只读副本
  • 跨地域部署副本以降低延迟
  • 使用缓存层减少数据库读压力

写扩展：

  • 将可分片的写密集型工作负载迁移到分片系统（如 Azure Cosmos DB）
  • 优化应用逻辑减少不必要的写入
  • 引入延迟写入以平滑流量峰值

C. 技术改进

  • 优化查询性能，避免复杂的多表连接
  • 实施工作负载隔离，防止"吵闹邻居"问题
  • 部署 PgBouncer 降低连接建立时间（从 50ms 降至 5ms）
  • 实现缓存锁定机制防止缓存未命中风暴

2. 技术细节

A. 系统架构

graph TB
    Client[客户端] --> Proxy[代理层/PgBouncer]
    Proxy --> Primary[主节点/Primary]
    Proxy --> Replica1[副本1/美国]
    Proxy --> Replica2[副本2/欧洲]
    Proxy --> Replica3[副本3/亚洲]
    Proxy --> ReplicaN[副本N/其他区域]
    Primary -->|WAL流复制| Replica1
    Primary -->|WAL流复制| Replica2
    Primary -->|WAL流复制| Replica3
    Primary -->|WAL流复制| ReplicaN
    Cache[缓存层] -.读请求.-> Client

mermaid

B. MVCC 挑战

PostgreSQL 的多版本并发控制（MVCC）实现使其在写密集型工作负载下效率较低：

  • 更新操作会复制整行创建新版本
  • 导致写放大和读放大
  • 引发表和索引膨胀
  • 增加自动清理（autovacuum）调优复杂度

C. 性能指标

  • 连接建立延迟：从 50ms 降至 5ms（使用 PgBouncer）
  • p99 客户端延迟：保持在个位数毫秒级
  • 复制延迟：接近零
  • 可用性：99.999%

D. 复制架构演进

当前架构：主节点向所有副本流式传输 WAL 日志

未来计划：级联复制

graph LR
    Primary[主节点] -->|WAL| Intermediate[中间副本]
    Intermediate -->|WAL| Replica1[下游副本1]
    Intermediate -->|WAL| Replica2[下游副本2]
    Intermediate -->|WAL| ReplicaN[下游副本N]

mermaid

3. 数据与事实

A. 扩展历程

  • 过去一年 PostgreSQL 负载增长超过 10 倍
  • 从少量副本扩展到近 50 个副本
  • 从 ChatGPT 发布时的基础设施问题到现在的稳定运行

B. 事故记录

  • 过去 12 个月仅发生 1 次 SEV-0 级别 PostgreSQL 事故
  • 该事故发生在 ChatGPT ImageGen 病毒式发布期间
  • 一周内超过 1 亿新用户注册，写入流量激增 10 倍以上

四、影响分析

1. 行业影响

A. 技术认知突破

OpenAI 的实践证明，PostgreSQL 可以扩展到支持比之前认为的更大的读密集型工作负载。这挑战了业界对单主节点 PostgreSQL 架构扩展性的传统认知。

B. 架构设计启示

  • 单主节点架构在大量优化下可支撑大规模读密集型工作负载
  • 分片不是唯一选择，也不应该是首选方案
  • 垂直扩展与水平扩展结合的重要性

C. PostgreSQL 生态影响

  • 证明 PostgreSQL 在大规模生产环境中的可靠性
  • 为其他企业提供可参考的扩展实践
  • 推动 PostgreSQL 云服务商（如 Azure）改进服务

2. 用户影响

A. 现有用户

  • 享受低延迟和高可用性的服务
  • 系统稳定性显著提升，SEV-0 事故极少

B. 潜在用户

  • 展示了 PostgreSQL 在大规模场景下的可行性
  • 为计划采用 PostgreSQL 的企业提供信心

C. 迁移成本

  • OpenAI 选择不进行 PostgreSQL 分片，避免了复杂的迁移工作
  • 证明在正确优化下，现有架构仍有足够的增长空间

3. 技术趋势

A. 数据库发展方向

  • 传统关系数据库仍在大规模场景中保持竞争力
  • 优化比架构重构更有效
  • 混合架构（关系数据库 + 分片系统）成为趋势

B. 云数据库服务

  • Azure PostgreSQL Flexible Server 证明其可扩展性
  • 云服务商与用户的深度合作价值
  • 级联复制等新特性的重要性

五、关键技术挑战与解决方案

1. 写扩展限制

挑战

单主节点架构无法横向扩展写入，写入峰值可能快速压垮主节点。

解决方案

  • 将可分片的写密集型工作负载迁移到 Azure Cosmos DB
  • 优化应用逻辑减少冗余写入
  • 在适当场景引入延迟写入平滑流量峰值
  • 字段回填时实施严格速率限制

2. 昂贵查询

挑战

某些查询（如连接 12 个表的查询）会消耗大量 CPU，导致服务降级。

解决方案

  • 持续优化查询，避免 OLTP 反模式
  • 将复杂连接逻辑拆分并移至应用层
  • 审查 ORM 生成的 SQL
  • 配置超时参数（如 idle_in_transaction_session_timeout）

3. 单点故障

挑战

主节点故障会影响整个服务。

解决方案

  • 将关键读请求卸载到副本，确保主节点故障时仍可服务
  • 主节点运行在 HA 模式，配备热备副本
  • 每个地域部署多个副本，确保单副本故障不影响区域服务

4. 吵闹邻居问题

挑战

某些请求消耗不成比例的资源，影响其他工作负载。

解决方案

  • 工作负载隔离到专用实例
  • 按优先级分层路由（高优先级和低优先级）
  • 不同产品和服务使用独立实例

5. 连接管理

挑战

Azure PostgreSQL 实例最大连接限制为 5000，容易出现连接耗尽。

解决方案

  • 部署 PgBouncer 作为连接池代理
  • 使用事务池模式高效复用连接
  • 将代理、客户端和副本部署在同一区域以降低网络开销
  • 仔细配置空闲超时等参数

6. 缓存未命中风暴

挑战

缓存命中率突然下降时，大量请求直接击中数据库。

解决方案

  • 实施缓存锁定（和租约）机制
  • 同一缓存键未命中时，仅一个请求从数据库获取数据
  • 其他请求等待缓存更新，避免全部访问数据库

7. WAL 复制压力

挑战

随着副本数量增加，主节点需要向更多实例流式传输 WAL，增加网络带宽和 CPU 压力。

解决方案

  • 与 Azure PostgreSQL 团队合作开发级联复制功能
  • 中间副本向下游副本中继 WAL
  • 可扩展到超过 100 个副本而不压垮主节点

8. 流量峰值

挑战

特定端点的流量峰值、昂贵查询激增或重试风暴可能耗尽关键资源。

解决方案

  • 在应用、连接池、代理和查询多层实施速率限制
  • 避免过短的重试间隔
  • 在 ORM 层支持速率限制
  • 必要时完全阻止特定查询摘要（有针对性的负载丢弃）

9. 模式变更风险

挑战

即使小的模式变更（如更改列类型）也可能触发全表重写。

解决方案

  • 仅允许轻量级模式变更
  • 对模式变更执行严格的 5 秒超时
  • 允许并发创建和删除索引
  • 新表必须使用分片系统（如 Azure Cosmos DB）

六、经验总结

1. 成功经验

A. 充分的优化空间

PostgreSQL 在正确优化下可支撑远超预期的规模。

B. 架构选择的重要性

分片不是银弹，单主节点架构在大量优化下仍有足够的增长空间。

C. 云服务商合作的价值

与 Azure PostgreSQL 团队的深度合作推动了关键功能的开发。

2. 需要关注的问题

A. MVCC 的写效率

PostgreSQL 的 MVCC 实现在写密集型工作负载下效率较低。

B. 复制架构的扩展性

传统 WAL 复制架构在副本数量增加时面临扩展瓶颈。

C. 运维复杂度

随着优化措施的增加，系统复杂度也相应提升。

3. 未来计划

A. 持续迁移写密集型工作负载

继续将剩余的写密集型工作负载迁移到分片系统。

B. 级联复制

与 Azure 合作实现级联复制，以支持更多副本。

C. 探索其他扩展方案

包括分片 PostgreSQL 或其他分布式系统。

七、相关链接

1. 官方公告

2. 技术文档

3. 相关技术

参考资料

  1. Scaling PostgreSQL to power 800 million ChatGPT users - OpenAI Blog
最后修改：2026 年 01 月 23 日
© 允许规范转载
如果觉得我的文章对你有用，请随意赞赏