登录
首页 >  数据库 >  MySQL

StoneDB 读、写操作的执行过程

来源:SegmentFault

时间:2023-01-17 16:40:34 412浏览 收藏

在数据库实战开发的过程中,我们经常会遇到一些这样那样的问题,然后要卡好半天,等问题解决了才发现原来一些细节知识点还是没有掌握好。今天golang学习网就整理分享《StoneDB 读、写操作的执行过程》,聊聊MySQL、数据库,希望可以帮助到正在努力赚钱的你。

背景介绍

StoneDB 是一款兼容 MySQL 的开源 HTAP 数据库。StoneDB 的整体架构分为三层,分别是应用层、服务层和存储引擎层。应用层主要负责客户端的连接管理和权限验证;服务层提供了 SQL 接口、查询缓存、解析器、优化器、执行器等组件;Tianmu 引擎所在的存储引擎层是 StoneDB 的核心,数据的组织和压缩、以及基于知识网格的查询优化均是在 Tianmu 引擎实现。
本文主要为大家介绍 StoneDB 的读操作、写操作执行过程,方便大家了解引擎架构、内部逻辑和各个功能模块。

一、Tianmu 引擎架构

1 Tianmu 存储引擎在 Server 组件中的位置

file

2 Tianmu 引擎架构图

file

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.
解析入口:

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

字符过滤,粗糙集过滤寻找可疑包,生成字符位图文件。

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 等操作),则直接返回元信息节点中的数据,无需访问物理数据文件。
    file

    例如:SELECT count(*) FROM employees where salary
  • 通过 Knowledge Grid 知识,查找包含 salary
  • DP A 与 B 属于相关 DP, 只需直接从对应的 DPN 中获取 count 值即可。
  • DP C 属于不相关 DP,需要读取数据块并解压,执行函数计算后才能返回结果集。
  • 这里只有 DP C 会被读取并解压,DP A 与 B 并不消耗 IO 资源。

file

file

执行代码:

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();

三、写操作执行过程

file

来自客户端的请求经过连接器、分析器后,由查询优化器进行基于知识网格的优化,产生执行计划,经过数据的压缩、校验后再交给执行引擎去处理。
Tianmu 执行引擎将数据组织为两个层次:物理存储介质上的的数据块(Data Pack,DP),内存上的知识网格层(Knowledge Grid,KG)。
入口函数:

write_row

文中关于mysql的知识介绍,希望对你的学习有所帮助!若是受益匪浅,那就动动鼠标收藏这篇《StoneDB 读、写操作的执行过程》文章吧,也可关注golang学习网公众号了解相关技术文章。

声明:本文转载于:SegmentFault 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>
评论列表