1.1.1  openGauss的U STORE 与 Z HEAP 有区别吗

当 openGauss推出U STORE 存储引擎的时候，就不止一个朋友说高斯的 U STORE 是基于开源项目 Z HEAP 开发的。以前没怎么研究，所以也不方便发表意见。正好这几天在研究高斯 U STORE ，顺便也找了些 Z HEAP 的资料看了看。 Z HEAP 这个项目目前似乎已处于停滞状态，这个原本计划 P G 15 时合并到 P G 主版本的项目很可能会夭折。项目的最后更新时间时 2021年6月，支持的P G 版本为 P G 13 。 Z HEAP 是一个开源项目，因此大家如果有兴趣去测试一下，可以去 https://www.cybertec-postgresql.com/en/postgresql-zheap-current-status/ 下载，目前这个项目由 C YBERTEC 公司维护。

说实在的数据库十分复杂，如果从表象上去判断两个数据库是否同源实际上是很难判断的。我一般会从一些基础数据结构和存储引擎来分析二者是否同源。数据库的存储结构是最为底层的，每个字段都可以找到存在的理由，因此通过存储结构，特别是页结构来判断数据库底层代码的亲缘关系是十分有效的办法。前阵子很多人和我讨论达梦数据库是不是购买了 Oracle   9i的代码，我可以十分肯定的回答，答案是否定的。因为从达梦的 BLOCK 结构来看，和 Oracle是完全不同的，如果说相似，达梦的B LOCK 结构和 I NNODB 的 P AGE 结构有点类似，比较凑巧的是，达梦和 I NNODB 都采用了 B TREE 表，而不是 Oracle的H EAP 表。如果说达梦的早期版本参考过 M YSQL 的 I NNODB ，可能还有点可能性，买 Oracle   9 i 的代码那就是无稽之谈了。提出这个问题的人可能感叹于达梦和 Oracle在使用方法上的相似性，不过这种相似性，是达梦公司二十多年来不断的模仿，积累的结果，绝不是简单的偷了人家的代码。实际上我敢十分肯定的说这句话还源于这些年我和达梦研发团队的几次直接交流，我们两个团队交流的时候，达梦的研发人员总是在和我们探讨某项功能Oracle是如何实现的，他们有什么可借鉴之处。如果他们拿到了Oracle  9i 的代码，这些问题就没必要和我们一起来研究了。

回到正题，高斯的 U STORE 是抄袭了 E DB 的 Z HEAP 项目吗？我们也还是从底层的存储结构上来看。其实昨天我写了一篇关于 U STORE 的文章，指出 U STORE 的块结构完全模仿了 O RACLE, 甚至在一些代码的注释里，把事务槽 T D 称为 O RACLE 的术语 I TL 。从这一点上，我更详细研发人员充分借鉴了 Oracle的设计思想。而Z HEAP 项目的 P AGE 结构是完全不同的。

Z HEAP 的事务槽并没有模仿 Oracle，放在P AGEHEADER 后面，数据前面，而是放在块尾， ZHEAP 默认有 4个事务槽，这一点和U STORE 类似。放在尾部就有一个问题，无法扩展。和 U STORE 的设计相同的是， Z HEAP 的事务槽也要等某个 UNDO RECORD 失效后才能释放，因此扩展事务槽是必须的。而放在尾部无法扩展的问题如何解决呢？ Z HEAP 想到了 T PD 扩展， T PD 页是一种没有数据只有事务槽的页，如果不够用了，最后一个 S LOT 里就指向了一个 T PD 页。

这种设计避免了因为 S LOT 不足而产生长时间的等待，不过查找 T PD 信息依然是有成本的。 U STORE 的设计是 TD 最大可以扩展到 100个，超过100个就会产生等待，甚至S LEEP ，而 Z HEAP 的设计是永远不需要 S LEEP ，不过超过 4个S LOT ，性能就会有问题。 Oracle的设计似乎更好一些，把I TL 的历史信息放入 U NDO 中，这样事务一旦提交，不用管 U NDO RETENTION 就可以重新占用 I TL 了。当然 ITL 写入 U NDO 依然会产生开销，和 Z HEAP 的 T PD 页访问类似。一种折中的方案是结合 U STORE 和 Z HEAP 的算法，最后一条 T D 记录里指向 yige  TPD 页，这样既保持了常态化状态下的性能，又确保了一旦出现极端的情况，出现事务槽争用也有解决方法。

从 T UPLE 头结构上，也可以看出 U STORE 和 Z HEAP 的不同， Z HEAP 的设计还是尽可能要和 P G 原生代码保持兼容，而从 U STORE 的设计上处处透着高斯今后要完全用 U STORE 替代 A STORE 的想法。其实到这里我也不需要再过多的分析这个问题了。 Z HEAP 和 U STORE 是两种完全不同的设计和实现，也许 U STORE 设计时参考了一些 Z HEAP 的思想，不过最终 U STORE 采用了抄袭 Oracle的方案。

原本我想测试下 U STORE 和 A STORE 的性能。不过当前的 U STORE 版本还是 B ETA 版，性能并没有某些网文吹嘘的那么好，甚至再我的测试环境中， U STORE 和 A STORE 比，性能是惨不忍睹的。实际上， EDP 前几年公布 Z HEAP 的测试结果时，只是用了存储容量的比较，并没有发布性能比较的结果。而再 C YBERTECH 网站上更是指出，一个新的存储引擎，没有多年的优化以及大量用户的测试，再加以优化改进，是不可能在性能上超过 PG 现有的存储引擎的。

不过我们还是针对 U STORE 做了一些测试，当 I NIT_TD 使用默认的 4时，我们测出来的T PMC 指标为 95954   neworder。总的T PMC 为 21.3万。

而 INIT_TD= 32时，为newoerder为10.8万，总tpmc为24万。设置合理的事务槽数量，对高并发的T PMC 测试场景还是有效的。

不过和使用 ASTORE 相比， T PMC 差距还是很大。差不多少了 50%。

      最后我们来看看存储容量。使用 ASTORE ，数据装在后， BMSQL_ORDER_LINE 表大小为 1447 MB 。

压测结束时，这张表的大小为 4643 MB 。增加了 3倍多。

如果我们使用 U STORE ，采用 I NIT_TD=64, 压测开始前， B MSQL_ORDER_LINE 是 1361 MB 。

压测结束时，表的大小是 3950 MB ，大约是 2倍多，空间节约了一些，不过似乎没有那么明显。这和场景有关，对于U PDATE 为主的场景，情况会有不同。

今天我简单的分析了一下目前 PG 的两个 U STORE 实现，这也是广大 P GER 期望的功能，如果 P G 能够解决 A STORE 带来的问题，将会完美的多。不过一个数据库产品，底层存储引擎对稳定性与性能影响极大。要想做好 U STORE 也并非易事，这是伤筋动骨的改造。我们也希望高斯的 U STORE 能够成功。