混合事务与分析处理(hybrid transactional analytical processing, HTAP)技术是一种基于一站式架构同时处理事务请求与查询分析请求的技术. HTAP技术不仅消除了从关系型事务数据库到数据仓库的数据抽取、转换和加载过程, 还支持实时地分析最新事务数据. 然而, 为了同时处理OLTP与OLAP, HTAP系统也需要在系统性能与数据分析新鲜度之间做出取舍, 这主要是因为高并发、短时延的OLTP与带宽密集型、高时延的OLAP访问模式不同且互相干扰. 目前, 主流的HTAP数据库主要以行列共存的方式来支持混合事务与分析处理, 但是由于该类数据库面向不同的业务场景, 所以它们的存储架构与处理技术各有不同. 首先, 全面调研HTAP数据库, 总结它们主要的应用场景与优缺点, 并根据存储架构对它们进行分类、总结与对比. 现有综述工作侧重于基于行/列单格式存储的HTAP数据库以及基于Spark的松耦合HTAP系统, 而这里侧重于行列共存的实时HTAP数据库. 特别地, 凝炼了主流HTAP数据库关键技术, 包括数据组织技术、数据同步技术、查询优化技术、资源调度技术这4个部分. 同时总结分析了HTAP数据库构建技术与评测基准. 最后, 讨论了HTAP技术未来的研究方向与挑战.
Hybrid transactional analytical processing (HTAP) relies on a single system to process the mixed workloads of transactions and analytical queries simultaneously. It not only eliminates the extract-transform-load (ETL) process, but also enables real-time data analysis. Nevertheless, in order to process the mixed workloads of OLTP and OLAP, such systems must balance the trade-off between workload isolation and data freshness. This is mainly because of the interference of highly-concurrent short-lived OLTP workloads and bandwidth-intensive, long-running OLAP workloads. Most existing HTAP databases leverage the best of row store and column store to support HTAP. As there are different requirements for different HTAP applications, HTAP databases have disparate storage strategies and processing techniques. This study comprehensively surveys the HTAP databases. The taxonomy of state-of-the-art HTAP databases is introduced according to their storage strategies and architectures. Then, their pros and cons are summarized and compared. Different from previous works that focus on single-model and spark-based loosely-coupled HTAP systems, real-time HTAP databases with a row-column dual store are focused on. Moreover, a deep dive into their key techniques is accomplished regarding data organization, data synchronization, query optimization, and resource scheduling. The existing HTAP benchmarks are also introduced. Finally, the research challenges and open problems are discussed for HTAP.
随着现代社会中各类大规模实时分析应用的出现, 许多的业务场景需要我们既能处理高并发的事务请求, 又能够对最新数据作实时分析. 传统的数据处理流程是从在线事务处理(on-line transaction processing, OLTP)到数据ETL(extract-transform-load, 抽取-转换-加载)这样的过程, 再到在线分析处理(on-line analytical processing, OLAP)的数据处理流程, 但这样的流程耗时耗力, 并且分析的数据往往已经过时, 不能及时挖掘出有用信息[
传统OLTP/OLAP分离架构与一站式HTAP架构对比
HTAP数据库技术是数据库领域的一个研究热点, 工业界和学术界都在研究相关系统和技术. 2014年, 著名的咨询公司Gartner针对该类场景在报告中首次提出了HTAP的概念[
当前, HTAP数据库技术主要面临4个方面的挑战, 包括: (1) 数据组织问题; (2) 数据同步问题; (3) 查询优化问题; (4) HTAP资源调度问题.
(1) 数据组织问题是关于如何根据以往的HTAP负载适应性地组织数据, 以优化系统的处理性能及降低存储代价. 针对数据组织, 目前主要分为基于主行存储的内存列选择[
(2) 数据同步问题需要将最新的事务数据更新到列存储中, 以保证数据分析的高新鲜度. 但该问题的一个主要难点在于: 如何在保证高新鲜度的同时, 尽量减小数据同步对系统造成的性能影响. 目前的数据同步方法主要基于增量存储进行批量定时更新, 包括基于阈值的同步[
(3) 查询优化问题涉及到: (i) 如何为查询选择存储访问路径(行存或列存); (ii) 如何利用新硬件如异构CPU/GPU处理器进行负载加速; (iii) 如何建立索引高效地支持HTAP. 第(i)个问题的挑战主要在于平衡计划搜索的代价与查询的执行性能, 目前主要有基于规则[
(4) HTAP资源调度问题是指合理地为系统中执行OLTP负载的实例和执行OLAP负载的实例分配CPU、内存等资源, 使得系统性能最大化. 目前, 资源调度方法可分为基于负载执行的调度算法[
➢ Psaroudakis等人[
➢ Sirin等人[
➢ Raza等人[
目前, 针对HTAP的资源调度算法没有同时考虑负载特点和系统行为趋势的特点, 所以无法提前按趋势进行资源调度, 系统性能可能出现抖动. 因此, 未来可考虑基于历史统计信息建模, 通过机器学习技术来进行资源调度, 以提高系统的稳定性并保证数据分析的新鲜度.
本文将系统地对HTAP数据库系统的现有工作进行调研与综述.
● 首先, 根据存储架构的不同, 将主流HTAP数据库的存储架构分为四大类, 包括: (1) 主行存与内存型列存; (2) 分布式行存与列存副本; (3) 单机磁盘型行存与分布式列存; (4) 主列存与增量型行存; 同时, 介绍了每一类的代表性系统, 比较了不同的存储架构在处理OLTP与OLAP负载时的优缺点(见第1节).
● 其次, 详细介绍了HTAP数据库的关键技术, 包括数据组织技术、数据同步技术、查询优化技术、资源调度技术这4个部分(见第2节).
● 同时, 还介绍了面向HTAP数据库的构建技术(见第3节)与评测基准(见第4节), 包括数据生成、执行规则以及评价指标.
● 最后, 本文对HTAP技术的未来研究方向进行展望, 包括自动化内存列选择、面向HTAP的学习型查询优化器、自适应的HTAP资源调度以及面向HTAP的评测基准套件这4个方面(见第5节).
现有综述工作[
https://splicemachine.com/)分别包含了针对事务处理的HBase[
本文主要按照存储策略对HTAP数据库进行分类, 并针对每一类对它们的主要方法进行介绍. 如
HTAP数据库的4类存储架构图
针对每一类系统的存储架构,
面向HTAP数据库的存储架构分类与性能特点比较
存储架构 | 代表性系统 | OLTP | OLAP | 隔离性 | 新鲜度 | ||
性能 | 扩展性 | 性能 | 扩展性 | ||||
主行存与内存型列存 | Oracle[ |
高 | 中 | 高 | 低 | 低 | 高 |
分布式行存与列存副本 | TiDB[ |
中 | 高 | 中 | 高 | 高 | 低 |
单机磁盘型行存与分布式列存 | MySQL Heatwave[ |
中 | 中 | 高 | 高 | 高 | 中 |
主列存与增量型行存 | SAP HANA[ |
中 | 低 | 高 | 中 | 低 | 高 |
第(a)类架构利用内存优化的主行存与内存型列存支持HTAP, 因此OLTP和OLAP的处理性能都很高, 而且OLAP能够快速从增量行存储访问最新数据. 但该类架构基于单机处理混合负载, 因此扩展性与隔离性都不高, 尤其是内存型列存往往不支持持久化, 因此OLAP的扩展性很低. 第(b)类架构基于磁盘型分布式行存储与列存储支持HTAP, 因此扩展性与隔离性都很高, 但是由于分布式系统需要保证数据一致性, 其性能比第(a)类架构处理性能要低. 另外, 由于需要从增量日志中合并读取最新数据, 其新鲜度也相对较低. 第(c)类架构基于分布式内存型列存支持查询分析, 因此OLAP的性能、扩展性、隔离性都很高, 但是由于需要读取事务处理节点的最新缓存数据, 所以新鲜度偏低. 其基于单机磁盘型行存处理事务, 因此性能比第(a)类要低, 且扩展性比第(b)类要低. 第(d)类架构基于内存型列存处理OLAP, 其从增量行存中读取最新数据, 因此分析性能与新鲜度很高, 其列存可以持久化, 因此扩展性比第(a)类要高. 其利用缓存的增量行存储处理事务, 因此OLTP的扩展性与隔离性偏低.
如
DB2数据库在原有行存关系数据库的基础上, 结合BLU内存加速器针对HTAP负载进行优化. 其基于行存的关系数据库支持完整的ACID特性, 并可面向内存优化写操作. BLU是DB2的列存加速器名称, 它通过基于频率的字典压缩、内存优化、SIMD (single-instruction, multiple data, 单指令、多数据)等技术提升分析性能[
图 2(b)中的架构图所示, 该类HTAP数据库以分布式架构支持混合事务与分析处理. 其分布式行存为主存储, 列存为只读副本, 主节点在处理事务时写入日志, 并异步式地向其他节点服务器发送最新日志. 其通过分布式协议进行事务处理. 其中, 有部分节点会被选为列存节点, 负责加速复杂查询. 特别地, 只有行存节点参与事务协议, 列存节点不参与分布式事务投票. 当事务成功提交后, 主节点将最新日志复制到列存节点, 然后, 列存节点将行数据转换成列数据后写入持久化存储. 由于事务和查询分别在行存节点和列存节点上处理, 该类系统具有高度的负载处理隔离性. 另外, 由于完全基于分布式架构, 该类系统面向OLTP和OLAP的扩展性都很高. 然而, 相比于单机的HTAP架构, 基于分布式的架构需要不断通信以保持不同节点间的数据一致性, 因此会产生较大延迟, 所以, 该类架构针对OLTP与OLAP的处理性能不高. 另外, 由于需要通过日志回放的方式同步行存节点与列存节点之间的数据, 其在列存节点上进行数据分析时, 可能有最新数据还未被转换合并到持久化的列存储, 因而其数据分析的新鲜度偏低. 该类系统需要解决的问题是, 在保持高扩展性、高隔离性的同时提高系统的新鲜度与处理性能. 解决该问题的难点在于: 如何高效地合并增量数据, 并使得列存引擎能够快速访问最新数据. 基于分布式行存与列存副本的HTAP数据库包括TiDB[
TiDB基于两阶段提交协议与扩展的Raft协议[
如
以MySQL Heatwave[
如
以SAP HANA[
上述4类HTAP数据库架构各有优缺点, 那么如何选择它们, 取决于用户面对的具体应用场景. 总的来说, 用户可遵循以下原则.
(1) 对于面向高性能、高新鲜度且扩展性要求不高的HTAP应用, 如银行交易与分析系统, 可选择第(a)类架构的系统(同步延迟约为1 ms−100 ms)[
(2) 对于面向高扩展性、可容忍一定的数据同步延迟的HTAP应用, 如大型在线电商交易与分析平台, 可选择第(b)类架构的系统(同步延迟约为100 ms−10 s)[
(3) 对于面向高性能与高扩展性的OLAP、高隔离性的HTAP应用, 如大型物联网系统, 可选择第(c)类架构的系统(同步延迟约为200 ms)[
(4) 对于面向高性能的OLAP、高新鲜度且扩展性要求不高的HTAP应用, 如金融反欺诈系统, 可选择第(d)类架构的系统(同步延迟约为1 ms−10 ms)[
由于行存更适用于事务处理而列存更适用于分析处理, 本文侧重于总结与比较行列共存型HTAP数据库, 还有一些其他类型的HTAP系统没有在
(1) 行存型HTAP系统. 该类系统[
(2) 列存型HTAP系统[
(3) 基于Spark的HTAP系统. 该类系统[
总体来说, HTAP数据库的关键技术, 包括数据组织技术、查询优化技术、数据同步技术、资源调度技术这4个部分.
HTAP关键技术总览与优缺点比较
HTAP技术类别 | 关键技术 | 代表性工作 | 主要优点 | 主要缺点 |
数据组织技术 | 基于主行存的内存列选择 | MySQLHeatwave[ |
事务性能高 | 分析性能低 |
基于负载驱动的行列混合存储 | Refs.[ |
存储代价低 | 系统复杂度高 | |
数据同步技术 | 基于内存增量表与 |
Oracle[ |
性能高 | 扩展性低 |
基于增量日志与持久化列存的数据同步 | TiDB[ |
扩展性高 | 合并代价高 | |
查询优化技术 | 混合行/列存储扫描 | TiDB[ |
分析性能高 | 搜索空间大 |
异构CPU/GPU硬件加速 | RateupDB[ |
分析性能高 | 事务性能低 | |
面向HTAP负载的索引技术 | Refs.[ |
事务性能高 | 内存空间大 | |
资源调度技术 | 基于负载驱动的资源调度 | Refs.[ |
性能高 | 新鲜度低 |
基于新鲜度驱动的资源调度 | Ref.[ |
新鲜度高 | 性能不高 |
由于在HTAP数据库中维护全量同步的行存储与列存储代价太大, 因此需要采取适应性的数据组织技术.该类技术根据负载适应性地组织行列存储, 以使用相对少的存储代价高效地处理混合负载. 已有的关键技术主要分为两大类: (1) 基于主行存的内存列选择[
在HTAP数据库中, 数据同步技术指的是将增量数据高效地转换、合并到列存储的技术. 根据增量存储的类型(内存增量表/增量日志)以及列存储的类型(内存型/磁盘型), 本文将其分为两大类关键技术: (1) 基于内存的增量数据合并[
HTAP数据库的查询优化技术主要涉及到如何为查询选择优化的数据访问路径(行存或列存)、如何利用新硬件进行查询加速以及如何建立索引使得查询高效地访问最新的事务数据. 因此, 本文将其分为3类技术:
(1) 混合行/列存储扫描[
HTAP资源调度需要考虑系统整体性能与数据分析新鲜度这两个重要指标, 根据目前技术所考虑的系统指标, 本文将其分为两类技术: (1) 基于负载驱动的资源调度[
HTAP数据库数据组织的关键技术主要分为两大类: (1) 基于主行存的内存列选择[
内存列选择技术以全量行存数据为基础, 通过选择部分频繁被访问的列数据到内存中, 使得相应查询算子可以通过内存列扫描而被加速处理. 一种直接的选择方法是, 由数据库系统管理员根据具体的应用需求和数据模式手动地指定内存列集合[
基于热力图的方法[
基于热力图的自动化内存列选择技术
基于整型规划的算法[
该类技术[
目前, 基于混合组织的存储方式主要有两大缺点: 首先, 混合组织数据的方式增加了系统在查询处理与优化层面的复杂度, 需要实现许多新的执行规则, 并且以往的传统代价模型也由于混合存储而失效; 其次, 混合存储的事务处理会访问多个不同的列组, 造成多次磁盘I/O.
由于行列共存型HTAP数据库采用行存与列存双存储的方式来并发处理混合负载, 那么如何同步行存与列存之间的事务数据以保持数据分析的新鲜度同时又能保证系统运行的性能是一个关键的挑战. 在HTAP数据库中, 查询分析需要同时扫描列存储与增量存储, 但如果增量存储的数据不断增大, 基于增量存储与列存储扫描的方式其代价较大. 因此, 需要定期地将增量存储数据合并到列存中. 根据增量存储的类型(增量内存表或增量日志)以及列存储的位置(内存或磁盘), 本小节将介绍两类数据同步技术, 包括基于内存增量表与内存型列存的数据同步与基于增量日志与持久化列存的数据同步.
本节介绍3种关键技术: 两阶段迁移的数据同步技术、基于字典排序合并的数据同步技术以及基于阈值驱动的数据同步技术.
1) 两阶段迁移的数据同步技术
两阶段迁移技术[
● 增量存储以附加的形式将更新数据插入到内存表的尾部, 其对于每一条记录分配一个到列主存的RID映射, 该映射能够直接定位其在列存储中的分组与偏移位置, 但还未被合并到列存的尾部数据的RID都是暂时无效的, 它们会被建立B+树索引, 以便在合并时被快速访问;
● 删除表同样基于内存表, 其记录了在列存中被(逻辑上)删除数据的RID. 当列存做扫描时, 也会扫描删除表, 同时, 在列存与删除表中的数据会被跳过.
为了减少扫描增量存储与删除表的代价, 两阶段迁移技术作为后台进程定期地将增量存储的数据迁移到主行存. 如
基于两阶段迁移的数据同步技术
(1) 第1迁移阶段通过扫描增量存储的尾部来获取最新的事务数据, 对于近期(通常1小时内)频繁被更新的数据, 将暂时不会被加入, 因为它们很有可能再次被更新, 加入它们会导致迁移性能的下降. 当被选定元组确定后, 它们被压缩成列组放到内部表中, 所有的新增RID映射被加入到删除表中, 整个第1阶段作为一个事务提交;
(2) 在第2迁移阶段的开始, 行存表的映射还在删除表中, 删除表的数据也还未被迁移, 所以它们对新查询都还是不可见的. 因此, 第2阶段将针对每一行在删除表中的数据进行删除, 并更新行存表的映射, 这样的操作被当作一次短事务. 当这些事务处理完之后, 增量存储的尾部数据被清除, 新数据即对后续查询可见.
2) 基于阈值驱动的数据同步技术
该类技术[
基于阈值驱动的数据同步技术
3) 字典排序合并的数据同步技术
该项技术[
(1) 行存更新与增量列存储合并. 在第1阶段, 根据新增的行数据逐列转换到增量列存储中. 根据新增的列数据, 首先查询在增量列存储中的字典: 如果数据在字典中存在, 则直接将数据添加到数据列; 如果不存在, 则先更新字典, 分配字典索引, 然后添加新数据. 如
基于字典排序合并的数据同步技术
基于字典排序合并的数据同步技术
基于混合行/列扫描的查询优化技术
基于CPU/GPU查询优化技术的架构图
(2) 增量列存储与全量列存储合并. 在第2阶段, 首先将增量列存储中的字典与全量列存储中的字典合并. 通过插入排序, 获得合并后的全量字典, 然后将增量列存储中的数据对应地添加到全量数据中, 全量数据中的数据索引也一起更新. 如
总体来说, 基于内存式增量合并的数据同步技术能够高效、快速地将增量数据合并到主列存储中, 这主要是因为所有同步操作都在内存中进行. 该类技术的缺点是由于内存容量有限, 扩展性不够. 例如, SAP HANA的新增数据只能容纳10万级别的数据.
本小节介绍基于增量日志合并的数据同步技术[
如
HTAP数据库查询优化的关键技术主要有3类: 混合行/列存储扫描[
HTAP数据库查询优化的另一种新技术是混合行/列扫描技术, 即对于一个查询的算子集合, 一部分在行存引擎里执行, 另一部分在列存引擎里执行, 从而达到比纯行存执行或纯列存执行更好的性能效果. 例如: 对于短范围或点查询, 可以利用基于B+树索引的行存引擎执行; 对于多列扫描、复杂聚集, 可以利用列存储通过压缩和SIMD向量执行等技术进行执行, 最后, 查询引擎结合行存与列存的执行结果并返回给前端. 混合行/列扫描技术通常是流水线执行, 比如先行存执行索引查找, 结果输入到列存后进行顺序扫描, 最后输出最终结果. 目前, 许多HTAP数据库已经支持跨行列引擎混合执行查询的操作, 如TiDB[
混合行/列扫描的关键是, 判断一个查询或算子应该针对行存或是针对列存执行. 一种启发式的方法是优先选择内存列执行, 如果有缺省的列在行存中再去行存中继续执行. 这类方法判断流程简单, 且对很多情况都是有效的. 目前, Oracle、SQL Server都支持这种方法. 然而, 该类方法导致先在行存里执行的计划被忽略, 因此获得的执行计划可能不是最优的. 还有一种主要方法是基于代价函数的判断执行, 即分别比较算子在行存执行和列存执行中的代价, 然后决定执行顺序. 代表性系统是TiDB, 其分别基于行存扫描、索引扫描、列存扫描建立代价函数, 然后选择代价最小的执行方式.
基于代价函数的方法[
目前, 数据库里常用的估计方法主要有基于直方图与基于简单抽样的方法[
综上所述, 针对行列混合执行计划优化, 目前的方法主要基于启发式规则, 如优先考虑列扫描, 然后考虑行扫描[
CPU/GPU的异构处理器加速技术也是HTAP数据库查询优化的一项重要技术[
CPU针对事务存储的更新基于多版本并发控制, 对于插入操作, 直接附在存储的尾部, 并初始化事务创建元组的时间戳与删除元组的时间戳. 对于删除操作, 则设置被删除的元组的时间戳, 然后将ID加入到删除表中, 用于后续分析存储同步数据. 对于更新操作, 则变换为一次插入和一次删除旧元组的操作.
随着高性能通用图形计算处理器GPGPU与CUDA、OpenCL等编程框架的出现, 以GPU为核心的查询处理技术迎来了蓬勃发展[
该类技术旨在通过索引技术同时加速事务处理与查询分析, 目前的相关工作不是很多, 主要包括基于路径复制[
HTAP数据库需要同时支持执行OLTP事务与OLAP查询, 但这两种负载之间会存在数据的同步与CPU资源的共享. 已有研究结果显示: 当OLTP事务与OLAP查询同时执行时, 由于数据的同步与它们之间共享资源造成的互相干扰, HTAP数据库的整体性能会下降5倍[
该项技术通过监控当前混合负载的执行情况, 动态地调度系统资源如CPU、共享缓存、内存带宽等[
首先, 对于CPU资源, 可分别针对事务并发度和分析查询并发度来进行动态调度[
其次, 对于共享缓存和内存带宽资源, 也可通过观测负载执行情况动态地进行调整. 例如: 在执行混合负载时, 如果发现OLAP的吞吐量比单独执行时下降过多, 说明OLTP的执行影响到了OLAP的执行, 因此可以通过在
该类技术以给定的新鲜度为阈值, 在不同执行方式中切换[
如
基于新鲜度驱动的资源调度框架
系统可支持3种执行方式, 如
对于具体资源调度来说, 系统默认选择S2分离式执行. 当数据新鲜度小于给定阈值后, 根据具体的服务级别协议(service-level agreement, SLA)[
目前, 针对HTAP的资源调度主要以固定规则为主, 基本方法都是通过观测系统执行混合负载后的性能指标或基于数据分析的新鲜度驱动, 根据预先给定的规则进行资源调度. 例如: 如果系统执行混合负载时, 针对OLTP或者OLAP的吞吐量下降幅度很大, 那么调度算法将分配更多的CPU线程和缓存资源用于执行相应的负载. 然而, 这些调度方法没有对已知负载的特性和系统行为进行建模, 因此无法及时地进行调整, 稳定性很差.
HTAP数据库面向上层应用提供统一的服务接口, 所以与传统数据库的接口类似, 只需提供数据库的服务地址给目标应用程序, 即可对应用的数据进行管理, 包括数据字典的定义、数据的增/删/改/查、混合事务处理与查询处理. 与传统数据库不同, HTAP数据库需要指定主行存数据库中哪些数据需要被抽取并转换为列存储, 以加速分析型查询. 当初始化完成后, 系统便能够结合第2节的关键技术进行自动化的数据组织、查询优化、数据同步以及资源调度. 目前主要有3种列存构建方式: (1) 基于内存列的构建[
该类方法默认在内存中的数据为列式存储, 因此用INMEMORY关键字指定目标数据为列存, 其可支持不同粒度的列存储, 包括表级别与列级别. 此外, 其可根据应用场景需求指定数据的优先级, 例如: 可在(非常重要/高/中/低/无)这5个级别中选择一个优先级, 然后被设定为“非常重要”级别的数据会被马上填充, 而“无”级别的数据只有在被扫描的时候才被填充. 它还支持对数据压缩模式的指定, 例如: 如果数据可能被频繁更新, 可选择无压缩模式; 数据的查询性能如果很重要, 可以选择偏向查询的压缩方式(即兼顾存储空间与压缩率); 数据的存储空间如果有限制, 还可以选择偏向存储空间的压缩(即偏向低压缩率的算法). 具体例子如下(oracle 21c[
ALTER TABLE Vehicle INMEMORY MEMCOMPRESS FOR CAPACITY HIGH PRIORITY NONE;
该语句选定Vehicle表为列存(关键字INMEMORY), 选择偏向存储空间的压缩(关键字MEMCOMPRESS FOR CAPACITY HIGH)以及选择无重要级别的优先级(PRIORITY NONE).
该类方法通过建立名为列存索引(columnstore index)的方式指定列存的构建. 实际上, 列存索引也包含了所有的列数据, 与内存列的构建方式不同, 它还支持持久化的存储方式, 具体例子如下(SQL server 2016[
CREATE TABLE Vehicle (INDEX Vehicle_col COLUMNSTORE) WITH (MEMORY_OPTIMIZED=OFF);
该语句为行存表Vehicle建立了名为Vehicle_col的列存索引(关键字COLUMNSTORE), 并且选择了存储模式为非内存(关键字MEMORY_OPTIMIZED设定为OFF).
该类方法为选定的行存表建立分布式列存副本, 以提升系统的分析性能与可用性, 具体例子为(TiDB[
ALTER TABLE Vehicle SET TIFLASH REPLICA 3;
该语句为行存表Vehicle建立了同名的3份列副本(关键字TIFLASH REPLICA 3), 每个副本可被放置在不同的机器或存储区域. 此外, 它还支持在查询时利用手动HINT指定访问的数据格式, 具体例子如下:
SELECT/*+read_from_storage (TIFLASH [Vehicle])*/from Vehicle;
该查询语句在SELECT后插入手工HINT (关键字read_from_storage (TIFLASH [Vehicle])), 因此, 该查询将使用列存副本进行扫描, 还可以将TIFLASH替换为TIKV后使用行存副本进行扫描.
数据库评测基准(database benchmark)是数据库管理系统必不可少的重要组成部分, 其不仅是测试与衡量数据库系统性能的关键工具, 也是推动数据库新技术不断发展的助推器. 数据库发展近60年来, 工业界和学术界提出并开发出了一大批优秀的数据库评测基准工具. 评测基准对HTAP数据库技术的发展也至关重要, 但目前可用的标准和工具并不多, 现有评测基准主要以结合TPC以往的面向事务处理的基准测试和面向决策支持的基准测试为主, 下面我们具体介绍3个具有代表性的评测基准.
[
CH-benCHmark数据模型
下面, 本小节从数据模型与数据生成、查询负载与执行规则、评测指标这3个方面来介绍评测基准CH- benCHmark.
(1) 数据模型与数据生成
因为TPC-C和TPC-H的数据模型都基于商品零售场景, 且它们的数据表有重合部分, CH-benCHmark的数据模型保留了TPC-C的原有的包括地区表、仓库表、库存表、新订单表等所有9个表, 然后将TPC-H数据模型中的8个表融入进来. 其合并了它们的用户表、订单表、订单线表与产品线表、商品表与零件表, 去掉了TPC-H的产品供应商表(partsupp), 最终, CH-benCHmark的数据模型包含了融合后的12个数据表, 可同时支持OLTP和OLAP的操作. 对于数据生成, TPC-C与TPC-H使用不同的数据生成扩大模型(scaling model), TPC-C基于连续性扩大模型, 即随着系统的运行, 数据不断增加. TPC-H基于固定式扩大模型, 即给定扩大因子(scale factor), 生成的数据库大小是固定的. 为统一数据生成, CH-benCHmark将TPC-H也修改为与TPC-C一致的连续性扩大模型.
(2) 查询负载与执行规则
CH-benCHmark的查询负载也基本沿用了原有的负载操作. 因为TPC-C的部分完全被保留, 所以CH- benCHmark支持原有的5个事务操作, 即针对写的新订单事务、支付事务操作以及针对读的订单状态事务、订单交货事务、库存状态事务. 它们执行时所占的比例分别为44%、44%、4%、4%、4%. 针对分析查询, CH- benCHmark根据数据模型的变动相应地修改了TPC-H的原有22个查询, 除简化了一些算术操作和适应性的主外键连接调整, 基本保留了原有查询的商业语义性和语法结构. 在执行CH-benCHmark时, 有4个参数可以配置. 首先, 因为数据的生成是以数据仓库的个数来进行扩展生成, 可设定数据仓库的个数决定测试数据库的大小. 其次, 可决定执行时工作负载的类型. 可以设定只有OLTP的事务负载, 只有OLAP的查询负载, 或者混合两种负载执行. 对于混合执行的方式, 可以多个流同时执行OLTP和OLAP负载, 每一个流可包含执行所有事务操作, 或者包含所有22个查询. CH-benCHmark还可设置隔离的级别, 比如可设置低隔离级别为读提交, 从而支持快速数据处理. 还可设置更高隔离级别如可重复读. 最后, CH-benCHmark还可指定混合执行时数据的新鲜度. 通过设定时间阈值或者事务的数目, 系统可决定何时将最近数据用于查询处理中.
(3) 评测指标
TPC-C的评测指标主要以事务完成的吞吐量来衡量, 用
公式(5)中, 评价指标
此外, 为了对比在隔离处理HTAP和混合处理HTAP时系统的性能, 可分别执行负载, 然后再来对比系统在处理负载间抢占资源时的性能. 举例来说: 当OLTP为主要参照对象时, 顺序执行混合负载的指标为5.7@ 5084
HTAPBench[
(1) 数据模型与数据生成.
HTAPBench采用与CH-benCHmark一样的数据模型, 即保留所有TPC-C的表和实体关系, 然后融合TPC-H的8张表到TPC-C的数据模型中. HTAPBench的测试数据生成也直接使用原有的数据生成器, 但加入了时间戳用于控制混合负载的执行.
(2) 查询负载与执行规则.
HTAPBench的查询负载分为TPC-C的事务处理负载和TPC-H的报告分析负载两部分. 首先, 给定一个目标吞吐量
然后, 即可开始OLTP的事务数据的导入与执行. 对于OLAP查询, 首先测试需要保证每次的查询动态访问数据的区域, 而不是每次都固定地访问整个数据区域, 这样会造成每次查询之间的性能差异不大. 因此, 其在生成分析查询时, 通过数据密度分析当前数据增加最多的数据区间, 然后通过滑动窗口直接定位到这一区间为查询的目标. 当查询都准备好后, HTAPBench通过客户端均衡器确定需要启动多少工作数目来执行OLAP查询. 客户端均衡器的主要作用是监控当前的OLTP执行的吞吐量与目标吞吐量, 然后决定是否继续增加工作数目#
(3) 评测指标.
HTAPBench提出了一种统一指标来衡量系统在执行HTAP混合负载的性能, 这主要是为了避免分别衡量OLTP与OLAP的处理性能时忽略了OLTP对OLAP的影响. 通过固定OLTP的吞吐量, 提出了指标
其中,
CBTR[
当前, 如何针对行列共存型HTAP数据库进行列存数据管理、查询优化、资源调度以及系统评测, 仍然非常具有挑战性: 首先, 基于内存的列存储虽然能够通过列扫描加速查询, 并且利用压缩技术缩小存储空间, 但内存的容量毕竟有限, 当数据集很大且不断增长时, 还是无法把所有列存数据放入内存; 其次, 由于一个查询计划的算子既可以下推到行存执行, 又可以下推到列存执行, 因此, 针对不同数据访问路径, 如何自动地为查询优化器选择最优执行计划也非常关键; 同时, 为了协同执行OLTP和OLAP负载并保持数据一致性, 如何针对HTAP混合负载进行系统资源调度, 从而既考虑数据的一致性, 又提高系统性能也是一个难点; 最后, 虽然目前存在一些面向HTAP的基准测试, 但它们都存在许多不足, 有很大的改进空间. 总体来讲, HTAP数据库技术包含内存列选择、行列混合查询优化、HTAP资源调度、HTAP评测基准这4个挑战性问题.
深度强化学习将学习问题转化为马尔可夫决策过程, 代理通过试错的方式不断地与环境交互学习一个深度神经网络, 通过最大化与环境交互过程中获得的累计奖励, 从而找到解决问题的最优策略的方法[
针对HTAP的查询优化, 未来可考虑设计学习型算法[
● 首先, 选择最优化的提示集可以被形式化为一个基于上下文的多臂老虎机问题, 其中, 每一个臂是一个候选提示集, 上下文是当前提示集生成的计划集合, 目标是选择最优化的臂来最小化遗憾(regret), 即最优化提示集的计划收益与当前选择提示集的计划收益之差. 因此, 如何设计高效的算法以解决多臂老虎机问题是一个难点.
● 其次, 如何将行列混合算子划分为不相交的集合也是一个具有挑战性的问题, 因为这比之前只考虑行算子的情况更为复杂, 搜索空间更大.
● 最后, 在不实际执行查询的情况下, 如何准确评估查询计划使用提示集后的收益也是一个难点.
给定一个HTAP负载, 在多种资源调度执行方式中选择一种执行方式可以被形式化为一个分类问题, 问题的目标是在一定资源的调度下, 最小化处理混合负载的代价以及数据分析新鲜度小于阈值的时间. 针对这一问题, 需要我们设计轻量级的、自适应负载的算法. 这里有3个关键性挑战: 首先, 负载会持续进入到系统, 并且低并发、高延时的OLAP负载与高并发、低延时的OLTP负载的访问特点各不相同; 其次, 系统在持续调度资源的同时, 还要保证数据分析新鲜度的要求; 最后, 如何考虑更细粒度的资源调度方式也非常具有挑战性. 例如,
未来可以从4个方向改进现有HTAP评测基准: 首先, 未来可基于真实分布的数据集和工作负载建立不同HTAP场景(包括银行、金融、保险、电子商务等)的基准测试, 并考虑新鲜度指标; 其次, 由于TPC-H的数据模型和规模都很小, 查询负载不够丰富, 数据分布也主要以均匀和独立分布为主, 未来可加入更多的倾斜分布和数据关联到TPC-H中[
本综述对近10年的具有代表性的HTAP数据库进行了梳理、总结与分类. 本文重点对行列共存型HTAP数据库的关键技术进行了详细介绍, 同时也介绍了面向HTAP数据库的构建技术与评测基准, 并对HTAP技术的未来研究方向进行了展望. 本文首先对HTAP数据库进行了总体梳理、分类以及特点比较. 我们将HTAP数据库按照存储架构分为四大类, 即: (1) 主行存与内存型列存; (2) 分布式行存与列存副本; (3) 单机磁盘型行存与分布式列存; (4) 主列存与增量型行存. 针对每一类系统的存储架构, 介绍了它们的主要存储策略与处理方法, 并列出了它们的代表性系统, 比较了它们各自处理HTAP负载的优缺点. 本文重点对HTAP数据库的关键技术进行了总结, 包括数据组织技术、查询优化技术、数据同步技术、资源调度技术这4个部分. 对每一类技术, 从处理性能、扩展性、数据新鲜度等方面比较了它们的优缺点. 本文凝炼总结了每一类技术类型下的关键技术, 并对每一种技术进行了详细介绍. 本文也介绍了面向HTAP数据库的构建技术, 包括基于内存列、基于列存索引以及基于分布式列存副本的构建. 本文还回顾了HTAP数据库的评测基准, 包括CH- benCHmark、HTAPBench以及CBTR, 并详细介绍了它们的数据生成、执行规则以及评价指标. 最后, 本文讨论了当前HTAP关键技术的不足, 并展望了未来的研究方向, 包括内存列选择、行列混合查询优化、HTAP资源调度、HTAP评测基准这4个方面.
现代大规模事务处理与实时分析应用场景催生出了HTAP技术. 由于分布式处理、内存技术、行列共存等技术的发展, 使得实现高吞吐量与低延时的HTAP数据库成为了可能. 随着多核处理器、协处理器、GPU等新硬件以及AI算法、云计算的不断发展, HTAP数据库未来有着广阔的发展与应用前景.
本文由国家自然科学基金(61925205, 62072261, 62232009)、华为公司、好未来教育公司给予大力支持.
Özcan F, Tian YY, Tözün P. Hybrid transactional/analytical processing: A survey. In: Salihoglu S, Zhou WC, Chirkova R, Yang J, Suciu D, eds. Proc. of the Int'l Conf. on Management of Data. ACM, 2017. 1771-1775.
Hieber D, Grambow G. Hybrid transactional and analytical processing databases: A systematic literature review. In: Popescu M, Agosto A, Giudici P, Sztandera L, eds. Proc. of the Data Analytics. Nice: IARIA XPS, 2020. 90-98.
Lahiri T, Chavan S, Colgan M, Das D, Ganesh A, Gleeson M, Hase S, Holloway A, Kamp J, Lee TH. Oracle database in-memory: A dual format in-memory database. In: Gehrke J, Lehner W, Shim K, Cha SK, Lohman GM, eds. Proc. of the Int'l Conf. on Data Engineering. Seoul: IEEE, 2015. 1253-1258.
Larson PÅ, Birka A, Hanson EN, Huang W, Nowakiewicz M, Papadimos V. Real-time analytical processing with SQL server. Proc. of the VLDB Endowment, 2015, 8(12): 1740-1751.
Raman V, Attaluri G, Barber R, Chainani N, Kalmuk D, KulandaiSamy V, Leenstra J, Lightstone S, Liu S, Lohman GM. DB2 with BLU acceleration: So much more than just a column store. Proc. of the VLDB Endowment, 2013, 6(11): 1080-1091.
Sikka V, Färber F, Lehner W, Cha SK, Peh T, Bornhövd C. Efficient transaction processing in SAP HANA database: The end of a column store myth. In: Candan KS, Chen Y, Snodgrass RT, Gravano L, Fuxman A, eds. Proc. of the Int'l Conf. on Management of Data. Scottsdale: ACM, 2012. 731-742.
Huang DX, Liu Q, Cui Q,
Yang J, Rae I, Xu J,
MySQL Heatwave. Real-time Analytics for MySQL Database Service. Public Documentation Version 3.0. 2021. 1-20.
Oracle. Database In-Memory Guide. Public Documentation 21c. 2021. 71-88.
Boissier M, Schlosser R, Uflacker M. Hybrid data layouts for tiered HTAP databases with pareto-optimal data placements. In: Proc. of the Int'l Conf. on Data Engineering. Paris: IEEE, 2018. 209-220.
Alagiannis I, Idreos S, Ailamaki A. H2O: A hands-free adaptive store. In: Dyreson CE, Li FF, Ozsu MT, eds. Proc. of the Int'l Conf. on Management of Data. Snowbird: ACM, 2014. 1103-1114.
Athanassoulis M, Bøgh KS, Idreos S. Optimal column layout for hybrid workloads. Proc. of the VLDB Endowment, 2019, 12(13): 2393-2407.
Arulraj J, Pavlo A, Menon P. Bridging the archipelago between row-stores and column-stores for hybrid workloads. In: Ozscan F, Koutrika G, Madden S, eds. Proc. of the Int'l Conf. on Management of Data. San Francisco: ACM, 2016. 583-598.
Abebe M, Lazu H, Daudjee K. Proteus: Autonomous adaptive storage for mixed workloads. In: Bonifati A, Abbadi AE, Barcelo P, eds. Proc. of the Int'l Conf. on Management of Data. ACM, 2022. 1-15.
Appuswamy R, Karpathiotakis M, Porobic D, Ailamaki A. The case for heterogeneous HTAP. In: Proc. of the 8th Biennial Conf. on Innovative Data Systems Research. Chaminade: CIDR, 2017. 1-11.
Lee R, Zhou MH, Li C, Hu SG, Teng JP, Li DY, Zhang XD. The art of balance: A RateupDB experience of building a CPU/GPU hybrid database product. Proc. of the VLDB Endowment, 2021, 14(12): 2999-3013.
Sun YH, Blelloch GE, Lim WS, Pavlo A. On supporting efficient snapshot isolation for hybrid workloads with multi-versioned indexes. Proc. of the VLDB Endowment, 2019, 13(2): 211-225.
Riegger C, Vinçon T, Gottstein R, Petrov I. MV-PBT: Multi-version indexing for large datasets and HTAP workloads. In: Bonifati, Zhou YL, Salles MAV, Bohm A, Olteanu D, eds. Proc. of the Int'l Conf. on Extending Database Technology. Copenhagen: OpenProceedings. org, 2020. 217-228.
Psaroudakis I, Scheuer T, May N, Ailamaki A. Task scheduling for highly concurrent analytical and transactional main-memory workloads. In: Bordawekar R, Lang CA, Gedik B, eds. Proc. of the Int'l Workshop on Accelerating Data Management Systems Using Modern Processor and Storage Architectures. Trento: VLDB, 2013. 36-45.
Sirin U, Dwarkadas S, Ailamaki A. Performance characterization of HTAP workloads. In: Proc. of the Int'l Conf. on Data Engineering. Chania: IEEE, 2021. 1829-1834.
Raza A, Chrysogelos P, Anadiotis AC, Ailamaki A. Adaptive HTAP through elastic resource scheduling. In: Maier D, Pottinger R, Doan AH, Tan WC, Alawini A, Ngo HQ, eds. Proc. of the Int'l Conf. on Management of Data. Portland: ACM, 2020. 2043-2054.
Kemper A, Neumann T. HyPer: A hybrid OLTP & OLAP main memory database system based on virtual memory snapshots. In: Abiteboul S, Bohm K, Koch C, Tan KL, eds. Proc. of the Int'l Conf. on Data Engineering. Hannover: IEEE, 2011. 195-206.
Makreshanski D, Giceva J, Barthels C, Alonso G. BatchDB: Efficient isolated execution of hybrid OLTP+OLAP workloads for interactive applications. In: Salihoglu S, Zhou WC, Chirkova R, Yang J, Suciu D, eds. Proc. of the Int'l Conf. on Management of Data. Chicago: ACM, 2017. 37-50.
Zaharia M, Chowdhury M, Franklin MJ, Shenker S, Stoica I. Spark: Cluster computing with working sets. In: Naham EM, Xu DY, eds. Proc. of the 2nd USENIX Workshop on Hot Topics in Cloud Computing. Boston: USENIX, 2010. 1-7.
Barber R, Garcia-Arellano C, Grosman R,
Mozafari B, Ramnarayan J, Menon S, Mahajan Y, Chakraborty S, Bhanawat H, Bachhav K. SnappyData: A unified cluster for streaming, transactions and interactice analytics. In: Proc. of the 8th Biennial Conf. on Innovative Data Systems Research. Chaminade: CIDR, 2017. 1-8.
Apache HBase. Reference Guide. Pulic Documentation Version 3.0. 2021. 444-455.
Bouzeghoub M, Peralta V. A framework for analysis of data freshness. In: Nauman F, Scannapieco M, eds. Proc. of the Int'l Workshop on Information Quality in Information Systems. Paris: ACM, 2004. 59-67.
Dziedzic A, Wang JJ, Das S, Ding BL, Narasayya VR, Syamala M. Columnstore and B+ tree—Are hybrid physical designs important? In: Das G, Jermaine CM, Bernstein PA, eds. Proc. of the Int'l Conf. on Management of Data. Houston: ACM, 2018. 177-190.
Diaconu C, Freedman C, Ismert E, Larson PA, Mittal P, Stonecipher R, Verma N, Zwilling M. Hekaton: SQL server's memory- optimized OLTP engine. In: Ross KA, Srivastava D, Papadias D, eds. Proc. of the Int'l Conf. on Management of Data. New York: ACM, 2013. 1243-1254.
Lamport L. Paxos made simple. ACM SIGACT News (Distributed Computing Column), 2001, 32(4): 51-58.
Diego O, Ousterhout JK. In search of an understandable consensus algorithm. In: Gibson G, Zeldovich N, eds. Proc. of the USENIX Annual Technical Conf. Philadelphia: USENIX, 2014. 305-319.
Corbett JC, Dean J, Epstein M,
Goel AK, Pound J, Auch N, Bumbulis P, MacLean S. Towards scalable real-time analytics: An architecture for scale-out of OLxP workloads. Proc. of the VLDB Endowment, 2015, 8(12): 1716-1727.3.
Färber F, May N, Lehner W, Große P, Müller I, Rauhe H, Dees J. The SAP HANA database—An architecture overview. IEEE Database Engineering Bulletin, 2012, 35(1): 28-33.
Shen SJ, Chen R, Chen HB, Zang BY. Retrofitting high availability mechanism to tame hybrid transaction/analytical processing. In: Brown AD, Lorch JR, eds. Proc. of the 15th USENIX Symp. on Operating Systems Design and Implementation. Virtual Event: USENIX, 2021. 219-238.
Neumann T, Mühlbauer T, Kemper A. Fast serializable multi-version concurrency control for main-memory database systems. In: Sellis TK, Davison SB, I, eds. Proc. of the Int'l Conf. on Management of Data. Melbourne: ACM, 2015. 677-689.
Grund M, Krüger J, Plattner H, Zeier A, Cudre-Mauroux P, Madden S. Hyrise: A main memory hybrid storage engine. Proc. of the VLDB Endowment, 2010, 4(2): 105-116.
Borthakur D. HDFS architecture guide. Hadoop Apache Project, 2008. 1-14.
Vohra D. Apache Parquet. Practical Hadoop Ecosystem. Berkeley: Springer, 2016. 325-335.
Pei W, Li ZH, Pan W. Survey of key technologies in GPU database system. Ruan Jian Xue Bao/Journal of Software, 2021, 32(3): 859-885 (in Chinese with English abstract). http://www.jos.org.cn/1000-9825/6175.htm [doi: 10.13328/j.cnki.jos.006175]
裴威, 李战怀, 潘巍. GPU数据库核心技术综述. 软件学报, 2021, 32(3): 859-885. http://www.jos.org.cn/1000-9825/6175.htm [doi: 10.13328/j.cnki.jos.006175].
Gallet B, Gowanlock M. Heterogeneous CPU-GPU epsilon grid joins: Static and dynamic work partitioning strategies. Data Science and Engineering, 2021, 6(1): 39-62.
Psaroudakis I, Wolf F, May N, Neumann T, Böhm A, Ailamaki A, Sattler KU. Scaling up mixed workloads: A battle of data freshness, flexibility, and scheduling. In: Nambiar R, Posess M, eds. Proc. of the Technology Conf. on Performance Evaluation and Benchmarking. Hangzhou: Sprinder, 2014. 97-112.
Cole R, Funke F, Giakoumakis L, Guy W, Kemper A, Krompass S, Kuno H, Nambiar R, Neumann T, Poess M. The mixed workload CH-benCHmark. In: Graefe. G, Salem K, eds. Proc. of the 4th Int'l Workshop on Testing Database Systems. Athen: ACM, 2011. 1-6.
Coelho F, Paulo J, Vilaça R, Pereira J, Oliveira R. HTAPBench: Hybrid transactional and analytical processing benchmark. In: Binder W, Cortellessa V, Koziolek A, Smirni E, Poess M, eds. Proc. of the 8th ACM/SPEC on Int'l Conf. on Performance Engineering. ACM, 2017. 293-304.
Bog A, Plattner H, Zeier A. A mixed transaction processing and operational reporting benchmark. Information Systems Frontiers, 2011, 13(3): 321-335.
Bog A, Sachs K, Plattner H. Interactive performance monitoring of a composite OLTP and OLAP workload. In: Candan KS, Chen Y, Snodgrass RT, Gravano L, Fuxman A, eds. Proc. of the 2012 ACM SIGMOD Int'l Conf. on Management of Data. Scottsdale: ACM, 2012. 645-648.
Chai MK, Fan J, Du XY. Learnable database systems: Challenges and opportunities. Ruan Jian Xue Bao/Journal of Software, 2020, 31(3): 806-830 (in Chinese with English abstract). http://www.jos.org.cn/1000-9825/5908.htm [doi: 10.13328/j.cnki.jos.005908]
柴茗珂, 范举, 杜小勇. 学习式数据库系统: 挑战与机遇. 软件学报, 2020, 31(3): 806-830. http://www.jos.org.cn/1000-9825/5908.htm [doi: 10.13328/j.cnki.jos.005908].
Li GL, Zhou XH. Survey of data management techniques for supporting artificial intelligence. Ruan Jian Xue Bao/Journal of Software, 2021, 32(1): 21-40 (in Chinese with English abstract). http://www.jos.org.cn/1000-9825/6121.htm [doi: 10.13328/j.cnki. jos.006121]
李国良, 周煊赫. 面向AI的数据管理技术综述. 软件学报, 2021, 32(1): 21-40. http://www.jos.org.cn/1000-9825/6121.htm [doi: 10.13328/j.cnki.jos.006121].
Li GL, Zhou XH, Li SF, Gao B. Qtune: A query-aware database tuning system with deep reinforcement learning. Proc. of the VLDB Endowment, 2019, 12(12): 2118-2130.
Zhang J, Liu Y, Zhou K, Li GL, Xiao ZL, Cheng B, Xing JS, Wang YT, Cheng TH, Liu L, Ran MW, Li ZK. An end-to-end automatic cloud database tuning system using deep reinforcement learning. In: Bonce PA, Manegold S, Ailamaki A, Deshpande A, Kraska T, eds. Proc. of the Int'l Conf. on Management of Data. Amasterdam: ACM, 2019. 415-432.
Yu X, Li GL, Chai CL, Tang N. Reinforcement learning with tree-LSTM for join order selection. In: Proc. of the Int'l Conf. on Data Engineering. Dallas: IEEE, 2020. 1297-1308.
Yuan HT, Li GL, Feng L, Sun J, Han Y. Automatic view generation with deep learning and reinforcement learning. In: Proc. of the Int'l Conf. on Data Engineering. Dallas: IEEE, 2020. 1501-1512.
Boissier M. Robust and budget-constrained encoding configurations for in-memory database systems. Proc. of the VLDB Endowment, 2021, 15(4): 780-793.
Li GL, Zhou XH, Cao L. AI meets database: AI4DB and DB4AI. In: Li GL, Li ZH, Idreos S, Srivastava, eds. Proc. of the Int'l Conf. on Management of Data. Virtual Event: ACM, 2021. 2859-2866.
Li GL, Zhou XH. Machine learning for data management: A system view. In: Proc. of the Int'l Conf. on Data Engineering. Virtual Event: IEEE, 2022. 1-4.
Zhou XH, Chai CL, Li GL, Sun J. Database meets artificial intelligence: A survey. IEEE Trans. on Knowledge Data Engineering, 2022, 34(3): 1096-1116.
Li GL, Zhou XH, Sun J, Yu X, Han Y, Jin LY, Li WB, Wang TQ, Li SF. openGauss: An autonomous database system. Proc. of the VLDB Endowment, 2021, 14(12): 3028-3041.
Marcus R, Negi P, Mao HZ, Tatbul N, Alizadeh M, Kraska T. Bao: Making learned query optimization practical. In: Li GL, Li ZH, Idreos S, Srivastava, eds. Proc. of the Int'l Conf. on Management of Data. Virtual Event: ACM, 2021. 1275-1288.
Marcus R, Negi P, Mao HZ, Zhang C, Alizadeh M, Kraska T, Papaemmanouil O, Tatbul N. Neo: A learned query optimizer. Proc. of the VLDB Endowment, 2019, 12(11): 1705-1718.
Lan H, Bao ZF, Peng YW. A survey on advancing the DBMS query optimizer: Cardinality estimation, cost model, and plan enumeration. Data Science and Engineering, 2021, 6(1): 86-101.
Boncz P, Anatiotis AC, Kläbe S. JCC-H: Adding join crossing correlations with skew to TPC-H. In: Nambiar R, Poess M, eds. Proc. of the Technology Conf. on Performance Evaluation and Benchmarking. Munich: Springer, 2017. 103-119.
Leis V, Gubichev A, Mirchev A, Boncz P, Kemper A, Neumann T. How good are query optimizers, really? Proc. of the VLDB Endowment, 2015, 9(3): 204-215.