POSTGRESQL 好垃圾 与 回复

如同没有十全十美的人，一个产品哪里有十全十美的，不怕有缺点，就怕没认知。那么如果从“处女座” 挑剔的角度来看POSTGRESQL 那么到底怎么能从“鸡蛋里面”挑挑骨头，让PG 下不来台。

攻击---问题1 ：多版本控制方式垃圾

众所周知，postgresql 的MVCC多版本控制以及事务回滚段，并非用 ORACLE ，MYSQL的集中式的方式来进行解决，而是通过在每个表中的每行通过保存多个行版本来解决，导致一个表会存储很多行版本的数据，最终导致表膨胀。同时一个update 相当于 insert ,delete操作，那么对同一行数据进行频繁的更新，表的空间使用会相对于其他数据库使用的更多，而这还没有结束，随之带来的还要进行VACUUM，AutoVacuum 等为了一个设计的问题，而带来的更多的问题。同时表在修改后，行的顺序无法在物理存储中进行存储，range方式提取数据是软肋， 垃圾 垃圾 垃圾

反击---答：说的好，数据库的设计中有一个名词，空间换时间，当年MYSQL的 purge 单线程导致UNDO 空间回收的问题，不也被吐槽。后来变成多线程来进行purge undo 来进行空间的回收，目前看也是OK的。Postgresql 在MVCC 以及UNDO的设计中并未采用，其他数据库的undo空间集中化的设计，可不能光看糟糕的一面， 好处也得说说， 由于每个表中存在一个行的多个版本的信息，数据的回滚的速度要比集中化的undo空间设计的数据库回滚的速度要快。同时vacuum 的设计与undo 集中化表空间的purge 线程的功能是一致的，不一致的是由集中化变为分散化。

反过来update 变为insert的方式，实际上可以提高数据的写入的速度，不需要在寻址到原来的位置进行数据的改变，而是直接在新的位置来进行数据的插入，数据写入的速度是优势。

系统的演进和迭代都是需要经过时间的， POSTGRESQL 可以设计出针对频繁更新的表的附加功能，将高频度更改的数据在缓存中多驻留通过算法定期的合并结果，最后将数据已较低的频率刷入磁盘即可，而不是将所有的更改的过程都刷新到磁盘，这样可以减少磁盘空间的浪费，降低vacuum的工作量，从另一个角度不设置UNDO 表空间，POSTGRESQL UNDO的限制就是你磁盘的容量，避免由于UNDO表空间设置的问题导致的数据库运行中的问题。

攻击--问题2 ：垃圾的POSTGRESQL 高可用丢数据

POSTGRESQL 高可用无论是REPMGR 或者 Patroni 或者其他的方式，都回避不了一件事，在数据库异步复制的时候，突发主机硬件故障，或者系统故障，事务在主节点上commited 后数据未传到从库，然后数据就丢失了。

反击--答：嗯，是的。那我们放眼看看那些数据库做到了在硬件以及系统故障后，异步数据复制，数据不丢失的。是ORACLE DG ,ADG ，还是MYSQL 的主从复制（就算加上半同步），或者你把MYSQL 8 的 INNODB CLUSTER加上， 或者 SQL SERVER Always on . 哪个能保证上面的问题100%解决。

任何不提成本的要求，都是耍流氓。POSTGRESQL 如果在保证使用同步复制的情况下，并且网络和硬件条件都稳定可靠的情况下，同步复制是可以解决高可用数据库切换数据丢失的可能。在同等条件下，其他的数据库也未必在某些特定条件下和同等的技术下，不丢失数据，凭什么要求POSTGRESQL 就是万能的。并且POSTGRESQL复制提供了方式可以不丢失数据，只不过你付出的成本要高一些，哪里有要马跑，还不给吃草的道理。如果实在是要这样，那可以进行硬件底层数据同步的方式。另外到目前没有任何一个公司敢允诺，整体的系统稳定性以及数据不丢失可以达到100%。

啊什么有这样说的，恭喜你遇到骗子了。

另外POSTGRESQL 从PG10 就支持全同步多节点中任意从节点同步以及数量的设置。

synchronous_standby_names = 'ANY 2 (s1, s2, s3)'

这和MYSQL的半同步复制的至少有一个数据库与主同步的设置有一样的效果。

攻击---问题 3 ：垃圾的full page ，一种很笨的保证数据CRASH 后的安全性的方法。

POSTGRESQL 通过FULL PAGE 写入WAL日志的方法简直太烂了，日志中要包含数据，还8KB，如果还有数据库的复制replicaiton，不光对磁盘I/O有压力，还对网络有压力。

反击---答：ORACLE 是怎么处理数据半页写的问题？？？？

MYSQL 也是通过DW 的方式来完成的，那么PG 通过在日志中写入FULL PAGE 数据页的方法有问题吗，同时也不是每个日志段都要写，仅在CHECKPOINT 后面的第一个页面写数据页， 性能有影响，但数据安全和数据性能之间的哪个更重要，如果真的是性能狂热分子，你上SSD 不好吗，所有性能问题让软件来解决，这不也是一种耍流氓吗？同时从软件的角度降低CHECKPOINT的频率也可以降低FULL PAGE对数据库性能的影响。

攻击---问题 4 ：POSTGRESQL VARCHAR CHAR, TEXT 数据大小写敏感，这怎么用，MSYQL ,ORACLE ，SQL SERVER 都不敏感，就你敏感，太垃圾。

反击---答：南方人吃甜豆花， 北方人吃咸豆腐脑，这是选择问题，不是对错的问题。输入什么，能查出什么这不是正确的吗，写大写，用小写去查也能查出来，这不是更有问题。当然POSTGRESQL 通过CITEXT extension可以解决这个问题，也可以大小写不敏感，PG文本大小写不敏感解决方案有，严谨的态度有，那倒是想反问，如果我就想我输入的是大写，就只能输入大写查，输入小写就不能查出，其他的数据库有这个功能的设置吗？

此篇纯属娱乐，请勿当真，如有雷同，纯属有意，周一上班笑一笑

终归一句话，没有十全十美的完美方案，只有理智的选择和鉴别。