10 Things I Hate About PostgreSQL
2021-06-21 10:30 abce 阅读(182) 评论(0) 编辑 收藏 举报
原文地址： https://rbranson.medium.com/10-things-i-hate-about-postgresql-20dbab8c2791
1.Disastrous XID Wraparound.
XID的wraparound是灾难性的。该问题导致过很多长时间停机的故障，长达数天。
PostgreSQL的MVCC事务语义依赖于能够比较事务ID (XID)号:行版本的插入XID大于当前事务的XID就表示是“将来的”，并且不应该对当前事务可见。XID即transaction id。在一个postgresql cluster中，xid的长度是受限制的(32位)。如果长时间运行，超过了40亿个，就会发生事务id的wraparound：xid计数器会重新回到0计数，这样就会出现事务明明是之前老的事务，却一下子变成了"将来的"事务，也就意味着变成了不可见的了。一句话，发生了灾难性的数据丢失。(实际上数据还是在那里，只是对你不可见了)为了避免这个问题，在每发生20亿个事务后，就至少需要对每个数据库中的所有表执行vacuum操作。
定期对表vacuum可以解决这个问题的原因是，vacuum会将行标记为frozen状态，表示这些行是很久之前的事务插入的，从而可以对当前事务和以后的事务可见。常规xids的比较是使用对2的32次方进行取模的算法，这样就有20亿个xid是“旧的”、20亿个xid是“新的”；换个方法说，就是xid空间是循环的、没有端点。postgresql保留了一个特殊的xid，FrozenTransactionId，这个特殊id不会遵守常规xid的比较规则，FrozenTransactionId被认为比任一常规xid都“旧”。被标记为frozen状态的行的xid被认作FrozenTransactionId，这样这些行就会出现在所有常规事务的“过去”，无论这些行记录存在多久的时间，都不用担心wraparound问题。
在postgresql 9.4之前，freeze是通过使用FrozenTransactionId替换行的插入xid实现的，在行的xmin系统列中是可见的。新版本中，只是设置一个标志位，保留行原来的xmin。从9.4之前版本升级过来的，可能还会看到xmin等于FrozenTransactionId的行。
2.Failover Will Probably Lose Data.
failover会有数据丢失的风险。
如果运行的主库突然出现故障，普通的流复制几乎肯定会丢失已经提交的数据。可能有人会说，这就是异步复制的代价，你可以不使用异步复制呀。postgresql支持同步复制
PostgreSQL支持使用仲裁提交的同步复制以实现容错持久性，但是它有一个更严的性能影响，这使得它的应用实现更加复杂。等待不会使用系统资源，但是持续持有事务锁，直到传输被确认。结果就是，不谨慎地使用同步复制会降低性能，因为会增加响应时间和更高的竞争。
3.Inefficient Replication That Spreads Corruption.
流复制是目前使用最多的复制机制。属于物理复制的一种，复制的是磁盘上二进制数据的变化。
每次需要通过写操作修改磁盘上的数据页（4KB）时，哪怕是只修改一个字节，也要将根据请求的修改进行编辑的整个页的副本写入预写日志（WAL）。物理流复制利用现有的WAL基础框架作为流到副本的更改日志。
使用物理复制，大的索引构建会创建大量WAL条目，从而很容易成为流复制的瓶颈。
页粒度的读-修改-复制过程可能会导致主机上由硬件引起的数据损坏，更容易传播到副本，我本人在生产环境中见过好几次这种情况。
这与逻辑复制相反，逻辑复制仅复制逻辑数据更改。至少从理论上讲，大的索引构建只会导致在网络上复制单个命令。尽管PostgreSQL已经支持逻辑复制已有相当长的一段时间了，但是大多数部署都使用物理流复制，因为它更健壮，支持范围更广并且更易于使用。
4.MVCC Garbage Frequently Painful.
和大多数主流数据库一样，PostgreSQL使用多版本并发控制(MVCC)来实现并发事务。但是，它的特定实现经常会带来关于垃圾行版本及其清理(vacuum)的操作难题。一般来说，INSERT和update操作会创建任何修改行的新副本(或“行版本”)，将旧版本留在磁盘上，直到它们可以被清除。
虽然这种情况在过去几年稳步改善，但它是一个复杂的系统，对于第一次处理这个问题的人来说，它有点像一个黑盒子。 例如，了解Heap-Only Tuples (HOT)以及它何时起作用，对于大量就地更新的工作负载(比如在一行中维护一致的计数器列)可能是决定成败的因素。 默认的autovacuum设置在大多数情况下都是有效的，但是有时也会不起作用。
相比之下，MySQL和Oracle使用redo和undo日志。它们不需要类似的后台垃圾收集进程。它们所做的权衡主要是增加事务提交和回滚操作的延迟。
5.Process-Per-Connection = Pain at Scale.
PostgreSQL为每一个连接fork一个进程，而大多数其他数据库使用更高效的连接并发模型。这就造成了相对困难的调优问题，因为在一个相对较低的阈值下，增加更多的连接会降低性能，而较高的阈值(难以估计，高度依赖于工作负载)则会导致性能急剧下降。
使用连接池程序的当然可以解决问题，但是引入额外的体系会增加结构复杂性。在一个特别大的部署中，我最终不得不添加第二个pgbouncer层。 一层运行在应用服务器上，另一层运行在数据库服务器上。它总共为大约100万个客户端进程聚合了连接。这时候对于调优工作来说，大概只有40%的技术含量，剩下大概要花40%的蛮力，还需要10%的碰运气了。
进程的可伸缩性在每一个主要版本中都在不断提高，但是最终，与MySQL中使用的“thread-per-connection”这样的架构相比，这种架构的性能有一些硬性限制。
6.Primary Key Index is a Space Hog.
PostgreSQL中的表有一个主键索引，使用单独的heap进行存储。其他数据库将这些集成在一起，或者支持“索引组织表”。在这种设计中，主键查找过程直接获取行数据，而不需要通过二级返回(secondary fetch)获取完整的行，也不需要额外的CPU和I/O。
PostgreSQL中的CLUSTER命令根据索引重新组织表以提高性能，但对于大多数真实的OLTP情况并不是真的有效。它在排他锁下重写整个表，阻塞任何读或写操作。PostgreSQL不为新数据维护clustered layout，因此必须定期运行此操作。因此，只有当你能够定期长时间使数据库离线时，它才真正有用。
但更关键的是，索引组织的表节省了空间，因为索引不需要行数据的单独副本。对于主要由主键覆盖的小行表，例如连接表，这可以很容易地将表的存储占用减少一半。
CREATE TABLE likes ( object_type INTEGER NOT NULL, object_id BIGINT NOT NULL GENERATED ALWAYS AS IDENTITY, user_id BIGINT NOT NULL, created_at TIMESTAMP WITH TIME ZONE NOT NULL, PRIMARY KEY ( object_type, object_id, user_id ) );
PostgreSQL将维护一个与基表存储分离的主键索引。 这个索引将包含每一行的object_type、object_id和user_id列的完整副本。每行28个字节中有20个(~70%)将被重复。如果PostgreSQL支持索引组织表，它就不会消耗所有额外的空间。
7.Major Version Upgrades Can Require Downtime.
一些大版本升级需要数小时的停机时间来转换大型数据库的数据。使用典型的流复制机制，不可能通过升级副本和故障转移来优雅地完成这一任务。 磁盘上的二进制格式在大版本之间是不兼容的，因此主副本之间的有线协议实际上也是不兼容的。
希望逻辑复制最终完全取代流复制，这将提供在线滚动升级策略。当我从事大规模水平扩展部署时，我们在定制基础设施上进行了大量工程性投资，使用另一个基于触发器的复制系统(也用于分片迁移)完成这些升级，而不需要停机。
8.Somewhat Cumbersome Replication Setup.
相对而言,MySQL的out-of-the-box的复制是更麻烦,但相比一些NoSQL存储如MongoDB和Redis,或一些cluster-oriented复制系统(比如MySQL组复制和Galera集群,从易用性和sharp-edge-avoidance的角度来看,设置复制在PostgreSQL还有很多需要改进。虽然从理论上讲，逻辑复制为第三方解决方案提供了更大的灵活性来掩盖这些缺陷，但到目前为止，使用逻辑复制代替流复制还存在一些相当大的问题。
9.Ridiculous No-Planner-Hints Dogma.
计划器提示(planner hints)允许指导查询计划器使用其本身不会使用的查询策略。在计划器提示看起来是一种高效灵活的编译器的争论中，PostgreSQL开发团队多年来一直拒绝支持查询计划器提示。
我理解他们，主要是防止用户使用查询提示来解决问题，而那些问题应该通过编写恰当的查询来解决。然而，当你看到生产数据库由于突然的、意想不到的查询计划变化而完全崩溃时，这种哲学似乎是太过武断了。
在许多这种情况下，给计划器一个提示可以在分分钟内解决问题，为工程团队节省数小时或数天的时间。虽然有一些间接的变通方法涉及禁用某些查询计划器策略，但它们是有风险的，在任何类型的时间压力下绝对不应该使用。
10.No Block Compression.
MySQL的InnoDB的页压缩通常会减少一半的存储空间，并且从性能的角度来看是不受影响的。PostgreSQL会自动压缩较大的值，但这对于在关系数据库中存储数据的最常见方式没有用处。对于大多数RDBMS中，一行通常只有几百个字节或更少，这意味着压缩只有在跨多行或多个块应用时才真正有效。
Postgres 的页面(page)大小是固定的 8k，同一行的数据必须在同一个页面内，但是 Postgres 需要支持变长的数据类型(如 varchar)，是可能超过 8k 的。解决方案是所谓的
对于PostgreSQL的核心数据结构来说，块压缩确实很难实现，但是MySQL的InnoDB存储引擎所采用的“打孔(hole punch)”策略在实践中似乎工作得很好，尽管也有一些缺点。
感兴趣的可以参考文章：
http://mysql.taobao.org/monthly/2016/02/01/
http://mysql.taobao.org/monthly/2015/08/01/
PostgreSQL中唯一广泛使用的通用块压缩设置利用了ZFS，它似乎对很有效。ZFS现在在Linux中已经是生产级的了，但无疑也带来了一些管理开销，而这些开销对于XFS或ext4这样的“开箱即用”文件系统来说是不存在的。
最后
你可能仍然应该使用 PostgreSQL 而不是其他东西来存储你最喜欢的数据。一般来说，我建议从PostgreSQL开始，然后尝试找出为什么它不适用于你的用例。
PostgreSQL 非常成熟，设计精良，功能丰富，并且对于绝大多数用例都非常高效。它还不受占主导地位的企业赞助商的阻碍，包括出色的文档，并拥有专业、包容的社区。
好消息是，通过使用诸如 Heroku PostgreSQL、Compose PostgreSQL、Amazon RDS for PostgreSQL 或 Google Cloud SQL for PostgreSQL 之类的托管数据库服务，可以减轻或消除由本文中提出的许多问题引起的痛苦。
我很自豪地说，我已经在 PostgreSQL 之上构建软件将近 20 年了，尽管存在缺陷，但我仍然是坚定的拥护者。鉴于我多年来见证了其令人难以置信的开发团队所取得的进展，我可以说大多数（如果不是全部）这些问题都将在适当的时候得到解决。
