OpenAI详细介绍了自己是如何对PostgreSQL进行优化改造，从而使其能够每秒处理数百万条查询请求，以支持ChatGPT及其API平台为全球数亿用户提供服务的。这一案例充分说明了：在写入操作密集的工作负载下，单一主节点的PostgreSQL系统在达到何种程度之前仍能继续正常运行；同时也强调了为实现低延迟、全球范围内的高可用性服务，在设计上需要做出哪些权衡，以及在运营层面需要采取哪些措施。
在过去的一年中，PostgreSQL所承受的负载增加了十倍以上。为此，OpenAI与Azure合作，对Azure Database for PostgreSQL进行了优化改造，使得该系统能够在保持单一主节点架构的同时，为8亿ChatGPT用户提供服务，并确保系统具有足够的处理能力。这些优化措施涵盖了应用程序层和数据库层，包括扩大实例规模、优化查询逻辑，以及通过添加读复制副本来提升系统的扩展性。通过应用程序层面的调优，系统减少了冗余的写入操作；而对于那些需要大量写入操作的场景，则将它们引导到像Azure Cosmos DB这样的分布式系统中，而将PostgreSQL主要用于那些需要强一致性的关系型数据处理任务中。
在Azure Database for PostgreSQL环境中，这个主节点PostgreSQL实例得到了近50个地理分布式的读复制副本的支持。读操作请求会被分散到这些复制副本上进行处理，从而确保系统的延迟时间能控制在低两位数的毫秒范围内；而写操作则仍然集中在这个主节点上进行，同时也会采取一些措施来避免给系统带来不必要的负担。通过延迟写入机制以及应用程序层面的优化，进一步减轻了主节点的压力，从而确保了系统在全球范围内的流量高峰期间仍能保持稳定的性能。
PostgreSQL的级联复制机制（来源：OpenAI官方博客文章）
随着流量规模的不断扩大，一系列运营挑战也随之出现了。例如缓存未命中现象频发、由对象关系映射工具生成的多表连接操作会导致系统性能下降，而全服务范围内的重试机制也会引发故障。为了解决这些问题，OpenAI将部分计算任务移到了应用程序层，对闲置或运行时间过长的交易设置了更严格的超时限制，并优化了查询结构，以减少这些操作对自动清理数据库进程的干扰。
降低写入操作的负担是解决问题的关键策略。由于在大量数据更新的情况下，PostgreSQL的多版本并发控制机制会导致CPU和存储资源的消耗增加，因此OpenAI通过将那些可以分片处理的操作任务转移到分布式系统中，对数据回写操作和大规模数据更新设置了速率限制，并严格执行一系列运营规范，从而有效避免了系统出现过载的情况。
在一篇LinkedIn帖子中，微软企业副总裁Shireesh Thota指出：
每种数据库的优化方式都不尽相同，因此需要进行适当的调整才能使其在大规模应用环境中正常运行。
连接池机制和工作负载隔离也是至关重要的。在事务池模式下，PostgreSQL的连接限制由PgBouncer来管理，这样能够减少连接建立所需的延迟，并避免客户端连接数出现骤增的情况。对于关键工作负载和非关键工作负载，也会进行分离处理，从而避免在高需求时段出现相互干扰的现象。
Kubernetes部署中运行着多个PgBouncer容器（来源：OpenAI博客文章）
读复制操作也会带来可扩展性方面的限制。当副本数量增加时，主节点必须将WAL日志发送给所有副本，这会增加CPU的使用量和网络开销。OpenAI正在尝试采用级联复制机制，让中间级的副本负责传递WAL日志，从而减轻主节点的负担，同时为未来的系统扩展留出空间。通过这些策略，PostgreSQL能够在地理分布广泛的区域内承载规模巨大、以读操作为主的人工智能应用；而对于写操作密集型的任务，则由分片系统来处理，以确保系统的稳定性和性能。
OpenAI表示，他们仍在继续探索各种方法，以进一步提升PostgreSQL的可扩展性。这些方法包括采用分片技术进行部署，或者尝试其他分布式系统架构，从而在保证数据一致性的同时，应对不断增长的全球流量以及日益多样化的应用场景需求。