从一篇论文开始聊聊数据库的HTAP 3

从一篇论文开始聊聊数据库的HTAP（3） 从中可以学到什么?

实现基于数据生命周期的异构存储，从而使用OLTP/OLAP的混合负载，最关键的部分是设计数据的Design Space。如下图，在不同的Design Space里，数据的组织形式是不同的。

在左侧，数据是以行的方式存储的，适合于OLTP工作负载。由缺省的LSM-Tree存储引擎存储。右边，是一个完全按列存储的，适用于OLAP的存储格式。中间是一种混合设计，其中Level-0面向行，Level 1和2使用CG（列组）的不同组合，并且Level-3用于纯列式存储。此设计可能适用于混合或HTAP工作负载，其列组配置取决于数据生命周期中的访问模式。下面我们跳过较为枯燥的学术分析部分，直接看基于数据生命周期的实时LSM-TREE存储引擎的最终效果。测试用例用使用了Q1-Q5五个用例，其中Q1是插入，每秒1万条数据，Q5是update，每秒100条，Q2-Q4是四个查询的场景。Q2是典型的OLTP查询（点查询），Q2A返回30个属性，Q2B返回其中的一半属性（16-30）,Q3/Q4为OLAP类的分析。

基于该算法的存储引擎与其他的数据库进行比较的结果如下：

其中LASER就是基于该算法的实时LSM-TREE引擎，可以看出其延时比传统的行数据库PostgreSQL低5倍，比纯列数据库MonetDb高出两个数量级。不过这个比较还不够客观，因为这个测试是用这两种数据库与不带事务控制的Rocksdb进行对比的，不具备可比性。不过从性能上还是看出了基于LSM-TREE的存储引擎在HTAP场景中的潜力。这篇论文虽然没有描述一个完整的RDBMS系统，也没有给出在LSM-TREE上实现MVCC并发控制的方法，基于对开源的Rocksdb的改造，可以很容易实现论文中所说的算法。
其实老白写这个系列的目的并不是解析这篇论文，并通过这个算法去构建一个基于LSM-TREE的具有HTAP场景支持的存储引擎，而仅仅是从中窥探到一些HTAP数据库工作负载的实现方式。如果我们从中看懂了对HTAP工作负载的支持，数据库有哪些实现方法，那么我们就可以去分辨身边的号称分布式HTAP数据库的真伪了。虽然很多数据库都号称支持HTAP的工作负载，但是实际上真正支持HTAP负载的数据库系统的开发难度还是很大的。Oracle和IBM都在行存储数据库中增加了列式的附加副本，从而在OLTP数据库中支持一些有限的、临时性的OLAP应用负载。实现这种异构复制的成本还是比较高的，Oracle只是在内存中实现这种列式副本，也主要出于降低成本的考虑。
实际上在C
AP
原则的控制下，高并发写的O
LTP
场景单机版数据库具有最低的开销，只要服务器的容量足够，烟囱式的结构肯定具有最小的强事务一致性成本开销。
分布式数据库因为分布式事务的存在，不可避免的会增加锁的开销成本。
解决该问题的方法是应用上采用一致性的分区方式，让某个数据的大部分的写操作尽可能能按照分区分别处理，从而尽可能减少分区之间的数据交互。
另外一种手段是采用两阶段提交的乐观锁，从而避免在每行数据修改发生时产生锁等待。
强一致性的锁的开销是分布式事务中最影响效率的因素，我们曾经做过一个测试，对于并发写入的场景，如果开启乐观锁控制，在一个8节点的分布式数据库集群上，大约每秒写入的数据量为53万，如果关闭乐观锁的控制，写入量提高了4倍。
如果使用悲观锁，可能情况更为糟糕，因为当时测试的数据库产品并不支持悲观锁，所以我们手头没有这方面的数据。
从这里我们也可以看出并发控制带来的成本。

另外一方面要说的是，任何好处都是需要代价的。
在数据库领域，也没有像永动机一样的不需要能量支撑的永恒运动，对某一方面的性能提升往往都是要牺牲另一方面来实现的。
对于O
LTP
和O
LAP
这两个截然不同的工作负载，到目前为止还没有什么技术手段能够在不付出任何代价的情况下就获得全面的支持。
行式存储引擎天然就对O
LAP
不够友好，而列式存储引擎天然就无法很好的支撑O
LTP
工作负载。
如果有人告诉你，我的一个基于M
YSQL

PROXY
的分库分表的数据库是一个H
TAP
数据库，既可以支撑高并发的数据写入，又能够支持复杂的分析场景，那么你可以直接不予采信。
L
SM-TREE
高并发写入的支持也并不是没有代价的。
数据写入的时候确实只需要生成W
AL
并落盘，并将数据写入内存中的S
ST
就可以了，提交的性能几乎等同于W
AL
写盘的性能。
不过当S
ST
写满后，最终还是要落盘的，而盘的性能与内存是有巨大的差距的，因此当内存写满后，写负载仍然没有下降，那么写的性能就不是写入内存的性能，而是接近于S
ST
写入物理盘的性能了。
为了实现超高的写入性能，我们必须选择性能较好的存储介质，使用S
SD
盘甚至N
VME
的S
SD
盘可能成为我们的必然选择。
L
SM-TREE
的这种特性也并不是没有代价的，在实现M
VCC
并发控制以及提供一致性读的时候，这种多层次的树状结构效率是很低的，因此我们必须进行c
ompare-and-merge
工作，从而合并数据，提高一致性读取的性能。
这种合并并不是没有代价的，需要很高的磁盘I
O
性能和C
PU
资源来支撑。
这也是基于L
SM-TREE
的存储引擎需要较高的C
PU
配置的主要原因。
另外如果我们需要采用基于生命周期的异构存储或者生成一个支持O
LAP
的异构副本同样不是免费的，需要额外的I
O
与C
PU
资源来支撑。
现在已经有一些数据库已经在考虑使用G
PU
来做这些工作，从而节约C
PU
的资源了。
现在计算机的CPU/io等的技术发展都十分快，在十年前我们还在感慨，计算机的发展这么快，是不是很快会出现计算资源过于充足了。事实上看，这种担忧是毫无根据的。很快就会有新的技术会更为充分的利用计算机的资源。因此我们在设计数据库产品的时候，是不是也应该较为超前的做一些设计，也许你的产品成熟的时候，计算资源的问题就已经足够了。想起老白大学里的毕业设计，当时最大的软盘是1.44M的，普通人都还在使用360K的单密磁盘。我们为了把一个6000个常用汉字的语音库放到一张软盘上，花了几年的时间去压缩优化，希望至少能够存储在一张1.44M的软盘上。当我们的产品比较成熟的时候，10M到20M的硬盘已经比较普及了，我们解决的这个问题除了发表了几篇学术论文外变得一文不值，对硬件发展认知的缺失让我们做了几年的无用功。在信息技术高速发展和多样化发展的今天，能够充分利用充足的计算资源与高性能存储设备替代传统HDD这样的技术发展方向去设计自己的产品，也是一种创新。这也是老白觉得在分布式数据库领域LSM-TREE存储引擎将会越来越流行的主要原因。现在在MYSQL上已经有了几款基于LSM-TREE的开源存储引擎了，有兴趣的朋友可以去研究研究。
谈到后面似乎问题更复杂了，数据库的研发人员要去研究硬件的发展了。不过仔细想想实际上也不矛盾，要让你的数据库跑的更好，充分的考虑其运行的硬件环境与操作系统环境是必须的。一个不懂硬件和操作系统的数据库开发团队，似乎也干不好数据库开发这活吧。