从一篇论文开始聊聊数据库的HTAP(1)

从一篇论文开始聊聊数据库的HTAP(1) 引言

首先说明一下，这个话题有点长，有可能一次讨论不完，老白尽可能简练的讨论这个问题，不过按照老白的写作能力，大概需要3-4次连载完。因为本周老白一直在出差中，所以更新可能会不太及时，大家谅解。

最近这几年数据库领域有一个十分热门的词汇，就是H
TAP
。如果你家的数据库不是H
TAP
数据库，都不好意思拿出来和别人见面。对于H
TAP
数据库这个概念老白是一头雾水的。在20年前，我在给客户做oracle数据库培训的时候，就会提到H
TAP
负载，O
LTP
负载和O
LAP
负载是天然不同的两种不同的负载。O
LTP
负载是日常的交易型工作负载，其特点是高并发和小事务，S
QL
语句一般都相对简单，不过并发访问量很大，数据修改的量很大；O
LAP
负载是一种低并发，少修改，复杂查询的工作负载，一些S
QL
可能需要进行大规模的数据扫描，多表关联，统计分析等操作。实际上O
LTP
模式下和O
LAP
模式下的数据库访问负载的不同，对于数据存储的结构也有不同的要求。
OLTP
高并发数据写入需要使用行存储模式才会比较高效，而O
LAP
的分析型操作，使用列存储比较高效。几年前一个做M
PP OLAP
数据库的厂商拿出一些测试结果说秒杀O
RACLE
的时候我也只能笑笑了，不同的存储引擎，对于不同的工作负载，是无法对等比较的。一般来说在O
LTP
环境下的
ORACLE
数据库，顶多可以支撑一些批处理的负载，而很难把一个O
LTP
数据库当成数据仓库来使用。因此在传统的数据库架构中，O
LTP->ODS->ETL->
数据仓库->数据集市这种架构比较流行。O
LAP
的工作还是交给比较擅长的列数据库来处理。想要在“行式存储”的数据库中直接支持复杂的O
LAP
分析是十分困难的。


支持H
TAP
负载的数据库的目的是在普通的O
LTP
数据库基础上支持
OLAP
工作负载，从而实现实时数据仓库的目标。H
TAP
这个词汇是2014年Gartner发明的，含义为一种新兴的应用架构，支持混合的O
LTP/OLAP
负载。



这两年H
TAP
数据库这个词已经被国内的数据库厂商用滥了，实际上就是我们最为熟悉的Oracle数据库也是支持H
TAP
负载的，虽然Oracle从来没有声明自己是HTAP数据库。在Oracle

12
C
开始支持的I
N-MEMORY DATABASE
技术可以支持在内存中建立某些数据的列式缓冲，从而支持类似O
LAP
的工作负载。在Gatner的H
TAP
定义中，提出了在应用负载中实现H
TAP
的两种主要方法：在内存中计算或者异构副本，Oracle的
IN-MEMORY DATABASE
是采用了第一种方法，在内存中建立异构的数据副本。



而
PINGCAP
的T
IDB
似乎采用了第二种方法，在T
IDB 4.0
开始引入了一个新的存储引擎
TiFlash
。TiFlash使用了ClickHouse的向量化计算引擎，从而提高分析类应用的性能。



以前的T
IDB
是采用基于L
SM-TREE
的
TiKV
存储引擎的，技术
LSM-TREE
这个词，这将是最近这几期老白文章中的核心，这是一种目前在分布式数据库中较为流行的存储引擎。作为一种L
SM-TREE
的存储引擎，TiKV对于高并发的写入支持特别好，但是有个缺点，对于大规模的读操作实际上支持是不够的，无论如何优化TiKV引擎，在支持O
LAP
场景的时候仍然有些力不从心。TiSpark的引入实际上是一种无奈的选择，使用内存引擎来解决这个问题并没有从根本上解决LSM-TREE对OLAP的支持能力不足的问题。不过在TiDB

4.0以后，这个问题得到了比较好的解决。解决方案就是TiFlash的引入。其原理可以用简单的方法来说明一下，就是当主引擎的数据写入TiKV后，TiDB会异步的生成一个TiFlash的副本，这个副本是适合
OLAP
工作负载的。TiDB和TiSpark计算引擎可以智能化的选择TiKV副本或者TiFlash副本用于不同的工作负载，甚至混合使用这两种副本，以达到最佳的S
QL
执行效果。

之所以老白今天用了较大的篇幅来谈TiDB的TiKV和TiFlash，是因为这种H
TAP
工作负载的实现方式，和老白这期要介绍的这篇论文的技术路线是类似的。这篇文章的题目为《
Real-Time LSM-Trees for HTAP Workloads
》，这篇2021年1月17日发表的论文被收录在
arxiv
论文数据库里（
arXiv:2101.06801v1
）。

要想真正理解这篇论文，可能需要读者先了解什么是L
SM-TREE
，今天的篇幅可能讲不到论文的正文了，所以我们利用最后的篇幅来讲讲L
SM-TREE
这个预备知识。作为近年来最为热门的数据库存储引擎之一的L
SM-TREE
，可能大多数搞数据库的都听说过，不过可能不一定会去认真深究L
SM-TREE
是怎么回事。实际上L
SM-TREE
是影响我们这个世界的谷歌三大论文中的BigTable中提出的，L
SM-TREE
是
Log Structured Merge Tree
的简称，维基百科的描述如下图。



维基百科对L
SM-TREE
的定义是一种对于高性能写入十分有效的数据结构，在实际实现上，L
SM-TREE
基于谷歌的著名的五分钟理论，也就是说如果某个数据每5分钟至少被访问一次，那么这个数据最好存放在内存里。



L
SM-TREE
的数据在C
0
阶段是存储在内存中的S
STABLE
中的，这些S
STABLE
按照一定大小的S
EGMENT
存储在内存中，当一个S
EGMENTS
写满后进入锁定状态，新数据将被写在新的S
EMGENTS
中，而锁定状态的S
EGMENT
经过M
ERGE
后会被写入磁盘进行持久化。



大家可能也看出来了，这种S
STABLE
写入的时候是不管老数据的，只管把最新的数据写入S
STABLE
，然后当一个S
EGMENT
写满后整体刷盘，这样的架构对于大并发的数据写入操作比传统的以H
EAP/BTREE
的模式要快得多。

L
SM-TREE
和数据库又是什么关系呢？我们借用互联网上的一张图来解释一下。



数据库一般包括sql引擎和存储引擎两部分。存储引擎可能把数据存放在持久化存储设备（比如硬盘）上，或者易失性的内存里（比如内存数据库）。在数据库发展的这些年里，存储引擎一直是B-
TREE
结构占主导地位。随着这些年分布式数据库的发展，谷歌论文BigTable中的L
SM-TREE
成为一种存储引擎的新宠。下面的图同样来自于互联网，列出了两大阵营中的主要数据库产品。



我们可以看到，大多数的传统数据库或者非分布式数据库都采用了
B-TREE
结构的存储，表的数据存储在堆结构的数据块中，索引使用B
-TREE
结构。而一些新型的分布式数据库都采用L
SM TREE
存储结构。

基于B
-TREE
结构的存储引擎具有较好的事务处理能力，但是对于大规模的数据写入性能与L
SM-TREE
相比有巨大的差距。因为L
SM-TREE
采用内存缓冲+大批量顺序写入的方式，对于高写入的场景具有极高的性能。特别是在更适合顺序访问的
SSD
盘
。
L
SM-TREE还
很
适合于分层存储，其中可以利用具有不同性能/成本特性的不同类型的存储，例如RAM，SSD，HDD和远程文件存储（例如AWS S3）。
不过L
SM TREE
也存在自身的不足，在大吞吐量读的场景下，L
SM-TREE
需要消耗更多的I
O
，另外为了保证L
SM-TREE
的性能，需要进行比较和合并操作，这个操作相当消耗C
PU
和I
O
资源。

基于上述的原理，L
SM-TREE
是一种十分适合于大型写入场景的存储引擎，不过由于S
STABLE
的M
ERGE
的需要，会更加消耗C
PU
和I
O
资源。不过随着计算机的计算能力与I
O
能力的极大提升，这种存储引擎对于现代的计算机系统来说，算是十分适合的。

为了更好的学习这篇论文，我们今天用了两千多字来介绍L
SM-TREE
存储引擎，不过上面关于L
SM-TREE
的介绍仅仅是科普的级别，如果大家有兴趣的话，可以去网上找几篇文章认真学习学习。