-
先引用一段
原文: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