POSTGRESQL PG 数据库到底烂不烂的后续

不熟悉问题是怎么回事的同学可以参考，上周发送的文字，为什么叫后续，因为真的有后续。

此时事件3：28AM，本来不想写了，但不写睡不着，所以......

先说一下事件的大致经过，此前一位同事的工作与数据库经常打交道，个人认为不是每个程序员对数据库，甚至对如何处理数据都有较深的理解，这位同学可能也是历经了多年的被“数据库”的折磨，导致了情绪上的脱缰野马，或者说消极对待。

因为每次出现一些业务上的问题，的口头禅就是 PG 很烂，我十分理解他说的很烂，他是真的说PG很烂，当然也有一部分的多年积累的情绪。一直我是处于理解的状态，这只能说明他对数据库本身不理解，或对数据处理的方式不清晰。

此次的Fight的导火索，是因为上传大量的UPDATE导致的，上传的速度如同数据库压测一样，CPU ，磁盘等均报警，IOPS 已经达到上限，每秒上传数据的速度在100MB -80MB 之间。PG的活跃连接数已经在120每秒以上了，（长连接）在目前的硬件的情况下，这已经是硬件匹配POSTGRESQL 13 能达到的效果了。同时我们还有数据的消费端，通过逻辑复制的方式对数据库中的表进行大量的传输到其他数据处理机构，数据WAL 也在数据库中大量堆积，截止正在写这篇文字的时候，数据库还在持续的后报警ING。

我们此间对他对数据库的所作所为，已经告知这样的上传速度，已经引起数据库的不稳定，和磁盘的暴涨，短短的几个小时我们两次添加磁盘空间，没有一个T 但几百G是有的，并且因为这位同学对数据库或者硬件的不了解，导致他认为他没有问题，随即爆发冲突。

然后这位同学，又在大群里面散播了一句，数据库不给力。此时堆积在我心里的情绪已经无法控制，因为大群里面有领导，数据库不给力这几个字，如果深入领导的内心，那么我们这个TEAM 估计 8辈子也翻不了身，熟可忍熟不能忍。

首先，我晓之以理，将数据库的网络访问量已经接近每秒80MB-100MB 的问题，截图并告知他，同时磁盘的读写IOPS 也接近整体的极限的问题，也做了说明并告知，数据库不是不给力，是使用的方式太有问题。

后面两个人，直接从技术问题，变为了轻量级的 criticism，最终那一定是惊动了领导，导致问题的激化。

本着任何问题都从自己的角度，批评与自我批评，先说说自己的问题

1 首先我们并没有协商或商定，针对数据库突发性的写入承受的规则，并且因为业务的原因，这样的突发性的写入，并不是一个常态，所以我们并未对此进行高度的重视，并且和开发部门进行互动，去真正的解决问题。

2 程序员对硬件和数据库的一无所知，或者看似幼稚的看法，也是我们的责任，没有持续性的进行数据库方面的知识的散播或持续性的输出，后面我们要做的是对数据库进行标准化，多大的硬件匹配多大的数据写入量，进行明确的规范和指标化。

3 进行快速的稳定数据库的方式方法，如在发现在对数据库进行压测试的数据库使用，我们可以快速的降低风险，并且进行技术性的处理。

反过来，对方的问题我也从我的角度来谈谈看法，

1 从架构的层面输入到数据库的数据量，应该进行评估或者限制，数据库不是文本文件，无限制被快速的塞入无法控制的数据，没有任何限制，一个成熟的架构师或者程序员是不会干这样愚蠢的事情。

2 从架构的角度，数据库成为众矢之的，高强度的依赖一个数据库产品，并无节制的滥用，是导致一个数据库出现“很烂” 的诱因，架构本身就是要从，有限的硬件资源 和 基础数据产品中，进行调配合理的使用，而不是无脑的添加前段的程序进程，而对后端的数据库不进行任何的考虑，最终压垮数据库。

3 硬件是资源是一定的，数据库的原理是固定的，能调整的是什么，数据流量，控制数据流，你是用其他缓存数据库承接也好，或者用MQ 承接也好，都好，但不能让数据库本身，作为一个孤岛，去裸奔在承受无限制控制的数据流。在我印象里面如果是架构师，应该不会设计出这样的产品，如我最近刚学到的漏斗算法。

4 方案单一化的问题，在处理数据的层面，方案单一，多年没有更新相关的数据使用的方案，并且进行推动改变，数据库成为问题的核心，数据库变成了，数据承接和数据传输，数据存储的三者的核心，核心功能集中化，也是导致数据库变成众矢之的 的成因。

数据库的问题不是单一的数据库的问题，他与架构的设计是脱离不了关系的，终究数据库，他只是一个数据处理，数据存储的单位，并不是一个能解决所有问题的万金油。

本着解决问题只能从自己下手，后续我们会进行

1 我们针对PG 的数据库，能在什么数据量下，承受多大的并发，进行多大的TPS ，指标化。（我们在做，已经通过 sysbench进行多个硬件配置下的测试，以及多种并发，多种表数据量的压力测试并获得了数据），后续我们一定要补上这个短板。

2 加大 PG 宣传的粒度，部分普通的程序员，其实对数据库是一无所知的，在经过多年对其的了解，数据库在一些程序员的心里，基本上没有什么概念，或者就是一个SQL 散发器，或者数据存储器。 作为IT 系统里面的三大系统，操作系统，数据库系统，编译系统，数据库系统的复杂度，可想而知，我个人认为，程序人员对数据库应该抱有，敬畏之心，而不是将自己的设计的不足导致的问题，发泄到数据库上，这是毫无道理的。

3 PG 在高并发进行UPDATE 的短板，也要自我认识，没有完美的数据库，只有识货的使用者，DB 需要彻底了解使用者的需求，并给出合理的使用PG数据库的方法，甚至可以改变高速数据输入的方法。

4 提高自己的情商，情绪失控一定不是一件好事情，工作就是工作，不要把工作上升到情绪的宣泄，做好自己，说问题，说两句，到第三句还不能解决问题，应该私下去沟通问题，大范围的文字“沟通” ，只能上升沟通的成本和问题难以解决的程度。并且这样的沟通的方式，没有什么胜利者，都是失败者。

5 提高自己的技术能力，用更风趣和幽默的方式来解决问题，做一个DB 人员，情商也需要提高，程序最终的数据流向，只能是数据库，而问题的爆发也大都在数据库，所以发现问题，解决问题，化解问题，经常进行PG 的使用分析和量化以及总结，并经常进行问题的公示，也是一个逐步降低问题爆发的方法。

但不变的是，PG 很棒，他从来不烂！