1 使用内存增量更新的单机事务处理
Standalone Transaction Processing with In-Memory Delta Update
关键技术点:
- 通过 MVCC 协议进行单机事务处理
- 通过内存增量更新进行 insert/delete/update 操作
相关数据库:Oracle、SQL Server、SAP HANA 和 StoneDB 等。
Standalone TP for insert/delete/update operations
上面这张图介绍了单机事务处理执行 insert/delete/operations 操作的一个逻辑过程,总体上是借助 MVCC+logging,它依赖于 MVCC 协议和日志记录技术来处理事务。具体来说,每个插入首先写入日志和行存储,然后附加到内存中的增量存储。更新创建具有新生命周期的行的新版本,即开始时间戳和结束时间戳,即旧版本在删除位图中被标记为删除行。因此,事务处理是高效的,因为 DML 操作是在内存中执行的。请注意,某些方法可能会将数据写入行存储 或增量行存储 ,并且它们可能仅在事务提交时写入日志。
一般有三种方式来实现内存增量存储,分别是:Heaptable (堆表)、Index organized table(索引组织表) 和 L1 cache(一级缓存),具体区别如下表:
Three implementations for an in-memory delta store
三者主要的区别在于插入(insertion)速度、查询(lookup)速度和容量(capacity)大小上。
2 使用日志回放的分布式事务处理
Distributed Transaction Processing with Log Replay
关键技术点:
- Two-Phase Commit (2PC)`+Paxos 用于分布式 TP 和数据复制
- 使用 Log replay (日志回放) 更新行存储和列存储
相关数据库:F1 Lightning
注:这里有稍有不同的分布式 TP 方案,就是采用主从复制(Master-slave replication)的方式实现 HTAP,比如 Singlestore。
Master node handles the transactions, then replicate the logs to slave nodes
如上图所示,这种主从复制的方式下,主节点处理事务,然后将日志复制到从节点再做分析。
另外就是通过 2PC+Raft+logging,它依赖于分布式架构。
Modified Raft Protocol for TP and AP nodes
它通过分布式事务处理提供了高可扩展性。ACID 事务在分布式节点上使用两阶段提交 (2PC) 协议、基于 Raft 的共识算法和预写日志 (WAL) 技术进行处理。特别是 leader 节点接收到 SQL 引擎的请求,然后在本地追加日志,异步发送日志给 follower 节点。如果大多数节点(即法定人数)成功附加日志,则领导者提交请求并在本地应用它。与第一种内存增量更新的方式相比,这种基于日志的方式由于分布式事务处理效率较低。
3 对比
最后我们将提到事务处理技术做一个对比:
Comparisons of TP techniques in HTAP Databases
二、查询分析技术(OLAP)
对于 HTAP 数据库,OLAP 负载使用面向列的技术执行,例如压缩数据上的聚合和单指令多数据 (SIMD) 指令。这里介绍两大类型和三种方式:
1 内存增量遍历 + 单机列扫描
Standalone Columnar Scan with In-Memory Delta Traversing
关键技术点:
- 单指令多数据 (SIMD),向量化处理
- 内存增量遍历(In-Memory Delta Traversing) 相关数据库:Oracle、SQL Server
举几个例子:
在(a)里,我们查询订单表中名称为 JASON 的花了多少钱,那么基于 SIMD 的查询方式,是可以通过 CPU 把数据 Load 到寄存器中,只需要一个 CPU 执行的周期,就可以同时去扫描查到满足条件的两个数据。
如果基于传统的火山模型,用的是一种迭代模型,就需要访问四行数据,而基于这种列存的方式,只要访问一次就可以得到结果。
同样的,还可以通过这种方式做基于 Bloom Filter 的向量化连接,也可以提高查询分析的效率。
在增量表中获取可见值,并跳过删除表中的陈旧数据
除此之外,我们在做列存扫描的同时要去扫描一些可见的增量数据来实现实时数据的分析,也去扫描删除表中是否有过期的数据,最终达到数据是新鲜的。