主要观点总结
文章讨论了PostgreSQL的伸缩性问题，并介绍了OpenAI使用的PostgreSQL巨无霸集群。文章还详细解释了传统PostgreSQL TCP流复制的缺陷以及为什么需要引入组播。作者对组播进行了概念解释，并通过图示比较了TCP单播和IP组播在资源消耗上的差异。文章还探讨了PostgreSQL社区为什么没有实现组播，并介绍了网络层双向组播（PIM-Bidirectional Multicast）在PostgreSQL主备复制场景中的应用前景。此外，文章还提及了Databricks收购开源数据库引擎初创公司Neon的消息，并讨论了不同数据库解决方案的优劣。
关键观点总结
关键观点1: OpenAI大量使用PostgreSQL，并且是一个40+从库的巨无霸架构。
使用最高可用规格的服务器硬件，总的读写QPS为100万左右。
关键观点2: 传统PostgreSQL TCP流复制的缺陷。
一个主库可以拖多个从库，但通信数量的增多导致网络带宽资源消耗更大，整体网络环境的复杂度更高。因此从9.2开始支持级联复制，减少主库的资源开销。
关键观点3: 组播的概念及其在PostgreSQL复制中的应用前景。
组播可以在网络中多点分发数据，实现更高效、更低延迟的多副本同步。通过对比TCP单播和IP组播的资源消耗差异，突显组播的优势。但是实现组播需要解决一系列问题，如错误恢复机制、组播路由协议配置等。
关键观点4: Databricks收购开源数据库引擎初创公司Neon的影响和数据库解决方案的优劣讨论。
Databricks需要补齐“事务库”这块短板以维持其在下一代AI数据平台的竞争力。文章还讨论了不同数据库解决方案的优劣，包括组播方式与共享存储等方案的对比。
文章预览
前言 今天看到冯董发了一篇 OpenAI：将PostgreSQL伸缩至新阶段 ，其中提到了 OpenAI 大量使用了 PostgreSQL，并且是一个 40+ 从库的巨无霸架构！ 在聊天提问的时候，老冯了解到 OpenAI 使用的是 Azure 上的托管 PostgreSQL，使用最高可用规格的服务器硬件，从库数量达到 40+，包括一些异地副本，这套巨无霸集群总的读写 QPS 为 100 万左右。 看到这段话的时候，颇有感触，一下子又让我回想起了前阵子在群里分享的组播了，来自于 IITM Pravartak 的 Balaji Venkat 分享了一篇 Experimental approach towards Replication performance optimization in Postgres 的议题，介绍了传统 PostgreSQL TCP 流复制的缺陷，以及为何需要在 PostgreSQL 中引入组播？组播又能带来怎样的优势？这么好为何社区没有去实现这个组播？让我们随着作者的思路一探究竟。 何为组播 像我们平时熟悉一点的，TCP 的点对点
………………………………
