背景介绍
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),即数据包,是存储的最底层,列中每份大小固定的单元组成一个数据块。
DP 是存储的最底层,列中每份大小固定的单元组成一个数据块。数据块比列更小,具备更好的压缩比率,又比磁盘默认存储单元单元更 大, 具备更好的查问性能。物理数据按固定数据块存储 (DP)、数据块大小固定 (典型值 128KB)、优化 IO 效率、提供基于块 (Block) 的高效压缩 / 加密算法。
获取 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