Loading... # 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. 系统架构 ```mermaid 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 ```  ### B. MVCC 挑战 PostgreSQL 的多版本并发控制（MVCC）实现使其在写密集型工作负载下效率较低： - 更新操作会复制整行创建新版本 - 导致写放大和读放大 - 引发表和索引膨胀 - 增加自动清理（autovacuum）调优复杂度 ### C. 性能指标 - 连接建立延迟：从 50ms 降至 5ms（使用 PgBouncer） - p99 客户端延迟：保持在个位数毫秒级 - 复制延迟：接近零 - 可用性：99.999% ### D. 复制架构演进 当前架构：主节点向所有副本流式传输 WAL 日志 未来计划：级联复制 ```mermaid graph LR Primary[主节点] -->|WAL| Intermediate[中间副本] Intermediate -->|WAL| Replica1[下游副本1] Intermediate -->|WAL| Replica2[下游副本2] Intermediate -->|WAL| ReplicaN[下游副本N] ```  ## 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. 官方公告 - [OpenAI 官方博客原文](https://openai.com/index/scaling-postgresql/) ## 2. 技术文档 - [Azure PostgreSQL Flexible Server](https://learn.microsoft.com/en-us/azure/postgresql/flexible-server/) - [The Part of PostgreSQL We Hate the Most](https://www.cmujournal.org/index.php/AID/article/view/123)（作者与 Andy Pavlo 教授合著的 MVCC 深度分析） ## 3. 相关技术 - [Cascading Replication](https://www.postgresql.org/docs/current/warm-standby.html#CASCADING-REPLICATION) *** ## 参考资料 1. [Scaling PostgreSQL to power 800 million ChatGPT users - OpenAI Blog](https://openai.com/index/scaling-postgresql/) 最后修改：2026 年 01 月 23 日 © 允许规范转载 赞 如果觉得我的文章对你有用，请随意赞赏