StoneDB 读、写操作的执行过程
StoneDB 是一款兼容 MySQL 的开源 HTAP 数据库。StoneDB 的整体架构分为三层,分别是应用层、服务层和存储引擎层。应用层主要负责客户端的连接管理和权限验证;服务层提供了 SQL 接口、查询缓存、解析器、优化器、执行器等组件;Tianmu 引擎所在的存储引擎层是 StoneDB 的核心,数据的组织和压缩、以及基于知识网格的查询优化均是在 Tianmu 引擎实现。
本文主要为大家介绍 StoneDB 的读操作、写操作执行过程,方便大家了解引擎架构、内部逻辑和各个功能模块。
Tianmu 引擎架构
1.Tianmu 存储引擎在 Server 组件中的位置
2.Tianmu 引擎架构图
3.Tianmu 引擎各个模块介绍
Tianmu Parser
解析客户端传来的 SQL ,进行关键字提取、解析,生成解析树。解析的词包括 select、update、delete、or、group by 等,对不支持的语法会向客户端抛出异常:ERROR:You have an error in your SQL syntax.
比如,执行如下语句:
select * from user where userId =1234;
在分析器中就通过语义规则器将 select、from、where 这些关键词提取和匹配出来, MySQL 会自动判断关键词和非关键词,将用户的匹配字段和自定义语句识别出来。这个阶段也会做一些校验,比如校验当前数据库是否存在 user 表,同时假如 user 表中不存在 userId 这个字段同样会报错:unknown column in field list.
解析入口:
parse_sql()
Tianmu Optimizer
对于来自客户端的请求,首先由查询优化器进行基于知识网格的优化,产生执行计划后再交给执行引擎去处理。基于知识网格中的信息进行粗糙集(Rough Set)构建,并确定此次请求所需使用到的数据包。
优化入口:
optimize_select()
Insert Buffer
InnoDB 的 insert buffer 是为辅助索引的插入做的优化设计,而 Tianmu 的 insert buffer 是为整张表的插入做的优化设计。当向表插入数据时,数据先暂存到 Tianmu 的 insert buffer,然后再从 insert buffer 批量刷新到磁盘,从系统的表现来看是吞吐量提高了。如果不经过 insert buffer,而是直接写入磁盘,由于 Tianmu 不支持事务,只能一行接着一行往磁盘写入,系统的吞吐量是不高的,插入效率固然不高。Tianmu 的 insert buffer 由变量 stonedb_insert_delayed 控制,默认为 on 表示开启。
插入缓存入口:
Engine::insert_buffer
Knowledge Grid Manager
Tianmu 引擎利用知识网格架构来对查询优化器、计划执行和压缩算法等提供支持。知识网格是 Tianmu 引擎进行快速数据查询的关键,在查询计划分析与构建过程中,通过知识网格可以消除或大量减少需要解压的数据块,降低 IO 消耗,提高查询响应时间和网络利用率。对于大部分统计/聚合性查询,Tianmu 引擎往往只需要使用知识网格就能返回查询结果(而不需要读取数据), 这种情况下在 1s 时间内就可以返回查询结果。
入口函数:
RCAttr::ApproxAnswerSize
Knowledge Grid
Knowledge Grid,即知识网格,是 Tianmu 引擎进行快速数据查询的关键,在查询计划分析与构建过程中,通过知识网格可以消除或大量减少需要解压的数据块,降低 IO 消耗,提高查询响应时间和网络利用率。
KN Node
Knowledge Node(KN Node),即知识节点,除了基础元数据外,还包括数据特征以及更深度的数据统信息,知识节点在数据查询/装载过程中会动态计算。
DPN
Data Pack Node(DPN),即数据包节点,又叫元数据节点(Metadata Node,MD Node),与数据包(DP)之间保持一一对应关系,数据包节点中包含了其对应数据包的元数据信息。
数据结构:
struct DPN{}
获取DPN:
DPN &get_dpn
Data Pack
Data Pack(DP),即数据包,数据包用于存放实际数据,是最底层的数据存储单元,每列按照65536行切分成一个数据包。每个数据包比列更小,具有更高的压缩比,而每个数据包又比每行更大,具有更好的查询性能。数据包是知识网格的解压缩单元。
获取 DP:
Pack *get_pack(size_t i)
CMAP
字符过滤,粗糙集过滤寻找可疑包,生成字符位图文件。
RSIndex_CMap::RSIndex_CMap;
HIST
整形过滤,粗糙集过滤寻找可疑包,生产直方图文件。
RSIndex_Hist::RSIndex_Hist
Replication Manager
StoneDB 复制引擎, StoneDB 本身与常见关系数据库的高可用架构一样(例如 MySQL ),为了保证强一致性,都会将数据更新在 Master 上执行,然后通过复制技术将副本导入到 Slave 节点。但是与 MySQL 标准的 binlog 复制不同,Tianmu 引擎中存储的不是原始数据,而是压缩后的数据块(DP) 。此时如果使用 binlog 的方式来进行复制,会导致网络上产生大量数据流量。为了解决这一点,Tianmu 实现了基于压缩后数据块的高效数据复制支持,相对于 binlog 复制,该技术可以大大降低网络传输所需的数据量。
Compress&Decompress
数据压缩和解压模块,Tianmu 基于列数据类型和特定领域优化的压缩算法,因为列中所有记录的类型一致,可以基于数据类型选择压缩算法,列中重复值越高压缩效果越好。除了常规的压缩算法外,针对特殊场景提供高效的压缩算法,如 Email 地址, IP 地址, URL 等 。
压缩入口:
Compress()
解压入口:
CprsErr Decompress
读操作执行过程
对于来自客户端的请求,首先由查询优化器进行基于知识网格的优化,产生执行计划后再交给执行引擎去处理。
•基于知识网格中的信息进行粗糙集(Rough Set)构建, 并确定此次请求所需使用到的数据包(DP)。
•基于知识节点和数据包节点,确定查询涉及到的数据包集合,并将数据包归类:
•相关 DP:满足查询条件限制的 DP(直接读取并返回);
•可疑 DP:DP 中部分数据满足查询条件(解压后进行处理再返回);
•不相关 DP:与查询条件完全不相关(直接忽略)。
执行计划构建时, 会完全规避不相关 DP,仅读取并解压相关 DP,按照特定情况决定是否读取可疑 DP。例如,对于一个查询请求,通过 Knowledge Grid 可以确定 3 个相关和 1 个可疑 DP。如果此请求包含聚合函数,此时只需要解压可疑 DP 并计算聚合值,再结合 3 个相关 DP 的数据包节点 (DPN)中的统计值即可得出结果。如果此请求需要返回具体数据,那么无论相关 DP 还是可疑 DP,都需要读取数据块并解压缩,以获得结果集。
•如果查询请求的结果可以直接从 DPN 中产生(例如 count, max, min 等操作),则直接返回元信息节点中的数据,无需访问物理数据文件。
例如:SELECT count(*) FROM employees where salary < 2500:
通过 Knowledge Grid 知识,查找包含 salary < 2500 的 DP,此处可以看到只有 A/B/C 三个 DP 涉及到该查询。
DP A 与 B 属于相关 DP, 只需直接从对应的 DPN 中获取 count 值即可。
DP C 属于不相关 DP,需要读取数据块并解压,执行函数计算后才能返回结果集。
这里只有 DP C 会被读取并解压,DP A 与 B 并不消耗 IO 资源。
执行代码:
Engine::HandleSelect();
Engine::GetTableShare();
class ColumnShare;
ColumnShare::map_dpn();
ColumnShare::read_meta();
ColumnShare::scan_dpn();
TableShare::TableShare();
RCAttr::RoughCheck;
RSIndex_CMap::RSIndex_CMap;
CprsErr Decompress;
TempTable::SendResult();
写操作执行过程
来自客户端的请求经过连接器、分析器后,由查询优化器进行基于知识网格的优化,产生执行计划,经过数据的压缩、校验后再交给执行引擎去处理。
Tianmu 执行引擎将数据组织为两个层次:物理存储介质上的的数据块(Data Pack,DP),内存上的知识网格层(Knowledge Grid,KG)。
入口函数:
write_row
StoneDB 现已开源,欢迎大家在 GitHub 上关注~
http://github.com/stoneatom/stonedb
添加微信小助手,进群与数百位数据库从业者共话真正的HTAP
本文分享自微信公众号 - StoneDB(StoneDB2021)。
如有侵权,请联系 [email protected] 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。
- 为什么 MySQL 使用 B 树?| StoneDB数据库观察
- 带你来吃瓜!Andy Pavlo教授带您一文回顾数据库的2022年
- 哪篇论文宣布了 HTAP 数据库的诞生? | StoneDB学术分享会#5
- 列存引擎 Tianmu 如何实现 Delete?| StoneDB 研发分享 #3
- StoneDB 首席架构师李浩:如何选择一款 HTAP 产品?
- 如何给一个 HTAP 数据库做基准测试?| StoneDB学术分享会 #4
- StoneDB读写分离实践方案
- StoneDB 团队成员与 MySQL 之父 Monty 会面,共话未来数据库形态
- 爆肝整理5000字!HTAP的关键技术有哪些?| StoneDB学术分享会#3
- 爆肝整理5000字!HTAP的关键技术有哪些?| StoneDB学术分享会#3
- 解读《Benchmarking Hybrid OLTP&OLAP Database Systems》| StoneDB学术分享会
- 深度干货!一篇 Paper 带您读懂 HTAP | StoneDB 学术分享会第①期
- StoneDB 读、写操作的执行过程
- StoneDB 宣布开源,一体化实时 HTAP 架构为何是当前最优解
- 什么是真正的HTAP?(一)背景篇
- 什么是真正的HTAP?(一)背景篇
- 一体化实时HTAP数据库StoneDB,如何替换MySQL并实现近百倍分析性能的提升
- StoneDB 为国产数据库添砖加瓦,基于 MySQL 的一体化实时 HTAP 数据库正式开源!