简单分析openGauss的MOT功能

以前对数据库原理不太了解的时候觉得只要有足够大的内存，能把数据库放到内存里去缓存，那么数据库就和内存数据库性能差不多了。后来随着对数据库原理的了解，发现这个想法是比较肤浅的。因为每次访问延时与磁盘访问延时的巨大差异，导致了内存数据库和磁盘数据库之间存在巨大的差异，仅仅依靠在内存中读取数据是不够的。有人基于PostgreSQL，利用INTEL AEP 傲腾非易失性内存，把傲腾内存做成文件系统，然后把数据库完全存储在海量的傲腾内存中，对比NVME SSD的性能，发现并无太大的提升。这是因为磁盘数据库引擎使用的是比较缓慢的文件IO接口，而内存访问使用memcpy等更为高效的接口。日本NTT的Takashi Menjo的团队HACK了PG的源代码，将数据库访问接口改为内存接口后，同样在AEP的测试环境中，发现PG数据库的性能获得了较大的提升，这个案例我以前的文章中介绍过。

我以前也没有了解过openGauss 内存存储引擎MOT相关的信息，从这种openGauss的架构图上我们可以看出，在数据库存储引擎层存在两种存储引擎，一种是基于磁盘的存储引擎，另外一种是内存优化存储引擎。这两种存储引擎都产生WAL，使用统一的WAL机制和WAL设备进行持久化。

内存数据库的持久化和磁盘数据库的持久化是有巨大的差异的，WAL是内存数据库持久化目前最好的方法。使用统一的WAL，这说明内存优化存储引擎似乎不仅仅是作为缓冲存在的，是一种全功能的内存存储引擎。不过从另外一方面，openGauss的MOT的实现是用插件的方式的，并不是集成在核心代码中，是不是完全融合的双引擎，在这里要打一个问号了。

不过MOT是一个集成服务器引擎，不是单独的服务器引擎。因此创建MOT表只需要指定是FOREIGN TABLE，而不需要输入SERVER。不过我们在创建MOT表的时候还是遇到了一些麻烦，当增量检查点开启的时候，不支持创建MOT表。

关闭增量CHECKPOINT后，建表语句成功完成了。我们来看看MOT表能否和普通的磁盘表做关联查询，从官方的手册上看似乎是不行的。不过我还是有点不死心，因为这个功能对于应用来说太关键了。

我们创建一张磁盘表，然后做一个JOIN操作，很遗憾，系统明确的告诉我，不支持跨存储引擎的查询。如果不支持跨引擎的多表关联，就说明MOT引擎还是外挂引擎，并且和磁盘数据库引擎的融合还没有做的很好。目前的MOT和2.1版本一样，都是1.0版本的BETA版本，希望正式版本发布的时候，能够解决这个问题。因为如果不能让磁盘表和内存表做JOIN，那么MOT的作用就小多了。

另外让开发人员不爽的MOT表的限制是，MOT目前只支持乐观锁。似乎在官方文档中说MOT的默认锁模式是乐观锁。我们来做一个测试。

首先我们创建一张简单的表，然后插入两条记录，再执行一个update操作。然后在另外一个会话中也执行UPDATE语句。

这条语句并没有像普通行锁一样出现等待，直接成功了。我们先提交这个事务。然后再回到第一个会话中去做提交。

先提交的成功，后提交的失败，并且自动被回滚，这是乐观锁的典型特征。我们再来看看官方文档的说明，十分明确的告诉我们，MOT只支持乐观锁。

至于性能方面，我就没必要一一测试了，如果一个内存引擎的表读写性能和磁盘库差不多，那么也就没必要拿出来了。某些标榜内存数据库如何快的文章，实际上是无脑的，内存库的设计目的和磁盘库是完全不同的，其主要性能差异不仅仅来自于主存储使用磁盘还是内存。

普通的行锁对于磁盘库来说已经够高效了，不过对于内存数据库引擎来说，还是太慢了，因此内存数据库引擎总是要通过降低行锁的成本来进一步提高内存库的访问性能。就像REDIS宁可选择单线程，也不愿意在内存访问时通过锁机制来串行化某些并发操作，就是这个原因。选择乐观锁这种开销比较小的锁是一种经过各种妥协后的选择。如果我们的应用要像使用磁盘库那样去使用内存库，肯定要牺牲掉不少内存库的性能方面的特征，因此我们的应用也必然要根据内存库的特点去进行优化，从而获得我们所预期的性能。

如果说乐观锁、不能跨引擎JOIN我们还可以通过应用适配来解决的话，不支持增量检查点就是一个更为严重的问题了。这将严重影响openGauss的MOT应用场景。为了少量高性能的数据访问需求牺牲主引擎（磁盘引擎）的检查点性能，对于大多数高并发高性能要求的数据库场景所不能接受的。如果关闭增量检查点，哪怕我们的磁盘数据库使用超高性能的NVME SSD存储介质，也不能保证检查点会对我们的某些应用造成不确定的性能影响。

从这个角度来说，openGauss的MOT在实用性方面就打了很大的折扣了。这是因为MOT引擎还是使用了FDW框架来实现，但是WAL已经完全融合了。这种融合的优势和缺陷并存。WAL的融合为双引擎的进一步融合提供了基础，而另一方面因为磁盘引擎和内存引擎的巨大的差异，导致WAL的融合要做好还需要更多的时间，我想MOT 2.0发布后，这方面应该会有比较大的改进吧。