OpenAI：将PostgreSQL伸缩至新阶段

老冯云数 · 公众号 · 科技创业科技自媒体 · 2025-05-19 08:35

主要观点总结

本文介绍了OpenAI在PGConf.Dev 2025全球开发者大会上的PostgreSQL实践分享，包括其在海量读负载下的伸缩实践、面临的挑战、解决措施、提出的问题及特性需求等。文章还提到了老冯对此的评论和答疑。

关键观点总结

关键观点1: OpenAI在PostgreSQL上的实践

OpenAI分享了其在PostgreSQL数据库上的最佳实践，展示了在使用一写多读的未分片架构下，PostgreSQL如何在海量读负载下伸缩自如。并分享了在实践中遇到的挑战和采取的解决措施。

关键观点2: 问题和特性需求

Bohan Zhang提出了一些问题和特性需求，包括禁用索引、可观测性、模式变更记录、监控视图语义和PostgreSQL默认参数的优化建议等。老冯对这些需求进行了解答，并提出了一些解决方案和建议。

关键观点3: 老冯的评论和答疑

老冯评论了OpenAI的分享内容，并对Bohan Zhang提出的问题进行了解答。他还分享了自己在PostgreSQL方面的经验和解决方案，包括使用Pigsty监控系统来管理PostgreSQL集群等。

正文

请到「今天看啥」查看全文

第二项是在查询层面进行优化。因为长事务会阻止垃圾回收并消耗资源，因此他们使用 timeout 配置来避免 Idle in Transaction 长事务，并设置会话，语句，客户端层面的超时。同时，还把一些多路 JOIN 的查询（比如一次 Join 12 个表）给优化掉了。分享中还特别提到使用 ORM 容易导致低效的查询，应当慎用。

治理单点问题

主库是一个单点，如果挂了就没法写入了。与之对应，我们有许多只读从库，一个挂了应用还可以读其他的。实际上许多关键请求是只读的，所以即使主库挂了，它们也可以继续从主库上读取。

此外，我们低优先级请求与高优先级请求也进行了区分，对于那些高优先级的请求，OpenAI 分配了专用的只读从库，避免它们被低优先级的请求影响

模式管理

第四项是只允许在此集群上进行轻量的模式变更。这意味着：

• 新建表，或者把新的负载丢上来是不允许的 • 可以新增或移除列（设置5秒超时），任何需要重写整表的操作都是不允许的。 • 可以创建/移除索引，但必须使用 CONTURRENTLY。

另一个提及的问题是运行中持续出现的长查询（>1s）会一直阻塞模式变更，最终导致模式变更失败。解决这个问题的措施是让应用把这些慢查询优化掉或者移走。

结果

• 将 Azure 上的 PostgreSQL 伸缩至百万 QPS（整个集群读+写），支撑了 OpenAI 的关键服务 • 在不增加复制延迟的前提下新增了几十个从库（约 40） • 将只读从库部署至不同的地理区域并保持低延迟 • 过去9个月内只有一起与 PostgreSQL 有关的零级事故 • 仍然为未来增长保留了足够的空间