PG到底能扛多大？亿级流量、PB级数据的底层真相

关注

原创 2026-08-03 08:51:24 209 阅读 AI 写同款· GEO 优化 ›

数据库选型实战指南：从数据形态到扩展路径的决策树 数据库选型本质是面向数据生命周期的技术预判，而非功能罗列。它始于对数据形态确定性、读写负载分布、一致性颗粒度和扩展物理约束的四维拆解；核心在于匹配业务真实访问模式——如时间序列需顺序写优化，多跳关联依赖图遍历效率，强模式演进要求Schema灵活，跨地域低延迟读写则考验分布式事务能力。技术价值体现在降低运维复杂度、减少开发心智负担、缩短故障定位链路；典型场景覆盖IoT遥测、金融风控、SaaS多租户、实时热搜与内容聚合。本文基于生产环境12项硬指标实测，聚焦数据库选型与NoSQL vs SQL落地边界。阅读详情

一、活动概况

2026年7月15日（周三）19:00–20:30，由中国PG分会、IvorySQL社区与TechTalk技术交流社区联合主办的「三十而立・全球时刻——PG 30周年系列直播」第四期圆满举行。本期主题为 “PG到底能扛多大？——亿级用户、PB级数据的架构真相” 。

原定主持人尚雷因身体不适未能出席，由尹海文代班主持。原定嘉宾林春因临时有紧急会议未能上线，实际参与讨论的为唐成与刘智龙两位老师。三位老师围绕大规模PG生产环境的架构真相、性能边界与运维实践，展开了坦诚而深入的对话。

二、嘉宾阵容

尹海文（代班主持） ：Oracle ACE Pro、PostgreSQL ACE，IvorySQL专家顾问委员，10年数据库行业经验。
唐成：中启乘数科技创始人及CTO，《PostgreSQL修炼之道：从小工到专家》作者，从业20余年。
刘智龙：平安科技PG数据库专家，10年运维经验，公众号“最后的DBA”主理人。

三、直播内容回顾

板块一：单机能扛多大？——从OpenAI的8亿用户说起

本期直播以OpenAI用“1主+50从”架构支撑8亿用户的行业热点为切入点。讨论首先围绕单机PG的真实负载能力展开——在真实生产环境中，单机PG可以承载80TB级别的数据量，配合高性能NVMe存储，高峰期每秒写入WAL日志可达GB级别，系统依然能够稳定运行。但从事务ID消耗的角度来看，单机PG的写入TPS上限大约在3000左右，按21亿事务ID计算，一周多就会消耗殆尽，必须面对事务ID回卷的风险。如果硬件配置足够强（如内存1TB以上），TPS也能扛到1万级别，但本质上仍然绕不开回卷问题。

关于OpenAI的案例，讨论中达成了几点共识：OpenAI的成功建立在读多写少的业务模型之上，写操作几乎可以忽略不计；他们使用了微软云896 vCPU、32TB内存的顶配虚拟机，单台月租金高达17.5万美元；最关键的是，OpenAI对业务SQL做了深度优化，而非使用大量多表关联的复杂查询，这才让单主多从的架构成为可能。但大多数行业（金融、互联网）的读写比通常只有2:8，远达不到1:50，盲目复制OpenAI的架构风险极大，且存在主从延迟导致的查询冲突问题，需要根据业务的时效性要求对查询进行分流。

板块二：什么时候必须分布式？——PG扩展方案的真实边界

关于“何时拆数据”，讨论给出了非常务实的建议。

核心观点是不要过早做分库分表。业务还没发展起来就拆分，等到业务真正爆发时，其实硬件投入已经不再是主要矛盾。有真实案例显示，某企业按地市拆库后，最大的一个地市仍然有80TB数据，之所以不再往下拆，是因为业务里有大量复杂的SQL，拆分的应用改造成本太高，最终选择用硬件硬扛。

拆分的优先级应该是先拆业务（分库），再考虑拆表（分片） 。按业务线做逻辑拆库（微服务化），比引入分布式中间件要稳妥得多。分布式方案引入以后，运维成本明显高很多，与集中式PG完全不是一个量级——不要在一个稳定的底座上去添加不稳定的因素。在分布式方案中，Citus是目前PG生态中相对成熟的方案，但引入时机和代价仍然需要审慎评估。

此外，硬件与人力成本的权衡也是一个重要变量。在中国市场，很多传统客户倾向于用硬件堆砌来规避应用改造的人力成本；但随着内存等硬件价格上涨，通过代码优化和架构调整来替代硬件堆砌的趋势正在显现。

板块三：大规模PG最怕什么？——MVCC、膨胀与autovacuum

这是整场直播信息密度最高的板块。

MVCC与垃圾回收是核心议题。讨论指出，Auto Vacuum的调优不能一刀切——大表需要调整vacuum_cost_delay等参数，默认值往往不够用。长事务必须体系化治理，它不仅是元组回收的障碍，更是很多系统性问题的根源。如果元组的生成速度持续快于回收速度，表就会不停膨胀，监控必须到位，并针对性地调整参数、索引个数，或考虑冷热分离。

大表与索引维护是另一个棘手问题。几百GB的表加上几百GB的索引，跑一次VACUUM就要几个小时。如果表在设计之初没有做成分区表，后期维护会极其痛苦。有极端案例显示，一张将近1TB的大表，跑一次VACUUM耗时整整7天。因此，在建表初期就应该识别出可能急剧增长的表并采用分区表策略，避免后期陷入无法在线维护的困境。同时，频繁更新的字段上建立索引会导致严重的写放大和阻塞，索引策略需要审慎设计。

坏块与物理复制陷阱也是一个容易被忽视的风险。物理复制可能将主库的坏块或索引不一致问题同步到备库，切换后仍然报错。更麻烦的是，损坏的块在物理层面看起来可能是旧版本的正常块，不会直接报错，但查询时就会发现表和索引对不上。这种情况下业务不能停，只能通过在线重建索引等方式逐个修复。

板块四：真实案例复盘——那些差点让业务挂掉的事

讨论中分享了两个令人印象深刻的真实故障案例。

第一个案例是逻辑复制溢出文件爆炸。某个 PG 库的溢出文件数量达到上千万个，操作系统扫描这些文件时直接卡住，导致数据库切换后第二个节点也挂了，高可用彻底失效。没有备库可切，只能现场研究问题根因，手工清理操作系统文件才把库拉起来。这个案例的教训是：当高可用已经失效时，你必须真正理解问题才能恢复业务。

第二个案例是插件过度使用带来的隐患。很多生产库里塞了太多插件——超过10个插件就会显著增加不稳定性和维护难度。插件之间可能存在加载顺序冲突，有些插件声称自己必须最后一个加载，但当十几个插件都这么说时，没人能真正管理这个顺序。更严重的是，部分热门插件存在维护停滞的风险，一旦社区大版本升级，兼容性断裂会给运维带来极大痛苦。选型建议很明确：不需要的插件就别装，装了就要做好长期维护的准备。生产环境应仅使用成熟、活跃度高且经过验证的基础插件。