PG12之独立引擎

• 先引用一段

原文：http://blog.itpub.net/31556440/viewspace-2667228/

独立存储引擎

就实际来说，MySQL早些年的MyISAM，实现质量并不好，不支持事务，表级别的读写锁。但因为存储引擎独立接口，MySQL等到了InnoDB，InnoDB实现了全套事务存储引擎，且现在已完全取代了MyISAM的地位。

而PG本身就实现了事务存储引擎，这个独立存储引擎的需求虽然很多年前早已规划，但实际上拆分出来正经去做，才是这个迭代的事情。

目前，PG单独处理了数据存储，索引存储的接口，第三方可以直接实现对应的接口和数据结构，就可以让PG利用到新增的存储引擎。

在社区里，已经有两个非常重要的存储引擎产生--虽然距离生成环境尚且还有一段距离，但这两个存储引擎都解决了PG本身存在多年的痼疾，未来可期。

两个非常重要的存储引擎，就是EDB的 zheap（开发中），以及Greenplum团队共享的 zedstore （开发中 ）存储引擎。

首先，说一说zheap。

PostgreSQL的存储实现中，其中dirty的一部分，vacuum，在实际生产环境中，成了一个每个运维都必须面对的问题。在zheap中，通过引入undo日志，zheap试图同时解决vacuum问题，以及32位事务id导致的vacuum freeze（事务ID回卷）问题。

在zheap中，并没有对heap（后文以此代称“pg”原生存储引擎）的索引，执行计划等进行处理，而只是单纯处理了其数据存储部分，也就是把undo从数据文件剥离出来成为undo日志。

目前其实现是：undo日志一直向前写（类似WAL日志），单独的purge进程从undo日志最老的日志开始回收，数据变更会保留在undo日志的数据指针，方便需要查询“老”数据的情况。这么一来，就可以避免数据文件的膨胀，以及vacuum的全表扫描的代价了。

而zedstore则代表了不同的方向： OLAP。

greenplum所处理的，就是MPP数据仓库，而在数据仓库来说，通常扫描一个表特定几列的情况，会远多于需要同时扫所有列的情况，因此zedstore设计目的，就是一个列存数据库。

zedstore的实现中，每个条目，都有一个名为tid的虚拟主键，表的某一列或者某几列，就保存在使用tid作为主键的B树索引中。通过支持tid到多列的索引，也相当于实现了“行列混合存储”。

zedstore另外一个重要的实现，就是压缩。zedstore数据存储的时候，是只压缩数据，不压缩数据块元数据的，这么搞虽然牺牲了一定比例的压缩比（考虑到数据块头的大小，未必有多大代价）。但得到的好处就是显而易见了：数据块以压缩的形态存储在共享池中，由用户会话解压缩各自所需的数据--作为对比的MySQL InnoDB压缩，就是整个数据块级别的压缩，于是共享池里面，就得同时保存数据块的压缩与未压缩版本，平白消耗了宝贵的内存。

  

https://www.modb.pro/doc/1314  --pg12

https://myslide.cn/slides/21593  -- PostgreSQL 11 与 12 用户最关心的特性解读 德哥

https://github.com/EnterpriseDB/zheap