共计 3205 个字符,预计需要花费 9 分钟才能阅读完成。
StoneDB 引擎根底组件
本章次要介绍 StoneDB 引擎的根底外围组件,这些组件能够说是 StoneDB 的基石,所具备的外围组件如下图所示:
1. 内存治理
StoneDB 引擎内存治理模块整体架构图如下:
内存治理模块为 StoneDB 引擎提供了高效且平安的动态内存操作,具体特点如下:
(1)反对基于 tcmolloc 机制封装对内存的创立和开释的类与操作。
(2)基于 LRU- K 和 2Q 缓存算法定制了不同的内存开释策略,晋升内存调配效率。
(3)定制了内存守卫对各类型的内存进行监管,晋升零碎的健壮性。
(4)反对大数据操作,对于大数据的操作基于 mmap 机制进行了封装。
1.1 内存控制器
内存控制器提供了各个层级的堆内存治理,内存调配策略和开释策略,是内存治理模块的外围。
内存控制器把堆内存分为了三类:
- 主堆内存
主堆内存,调配一般堆内存时首选对象。 - 零碎堆内存
次要作为主堆的备用堆,当主堆内存调配达到最大限度时,应用该堆。 - 大数据堆内存
调配长期大块内存时应用该堆对象。
内存控制器外围类:
class MemoryHandling
下图为内存控制器的结构图:
1.2 内存管理器基类
下图为内存管理器基类的结构图,其中内存控制器是以动态成员的形式存在与零碎中,只有一个实例且须要初始化。
内存管理器是内存治理模块对其余模块提供的内存操作基类,须要基于内存管理器的进行治理分配内存的可继承该类。
class TraceableObject
目前 StoneDB 引擎中继承自 TraceableObject 类 的子类如下图所示:
1.3 内存初始化流程
内存初始化次要是对内存控制器进行实例化,初始化一些内存的状态,对外围堆内存,零碎堆内存,大数据堆内存进行初始化创立,并初始化设置内存开释策略,其中零碎中负责内存初始工作的是一个单例类,继承于 TraceableObject。
内存初始化外围类:
class MemoryManagerInitializer
下图为内存初始化 StoneDB 零碎调用的流程:
2. 数据压缩 / 解压缩
StoneDB 基于列数据类型和特定畛域优化的压缩算法,因为列中所有记录的数据类型统一,能够基于数据类型抉择压缩算法,列中反复值越高压缩成果越好。除了惯例的压缩算法外,针对非凡场景提供高效的压缩算法,如 Email 地址、IP 地址、URL 等。
2.1 数据压缩流程
下图为 StoneDB 的写流程图:
整体的写流程如下:
1. 来自客户端的申请 ->2. 连接器 ->3. 分析器后 ->4. 由查问优化器进行基于常识网格的优化 ->5. 产生执行打算 ->6.通过数据的压缩->7. 校验后再交给执行引擎去解决。
压缩数据入口函数:
CprsErr Compress
2.1.1 执行 Insert 语句零碎的调用流程图(提早加载模式)
2.2 数据解压缩流程
整体的读流程如下:
1. 来自客户端的申请 ->2. 连接器 ->3. 分析器后 ->4. 由常识网格进行判断命中 ->5.命中后解压相干包->7. 返回后果集。
解压函数入口:
CprsErr Decompress
查问流程在其余文章有做具体解说,本章就不作过多赘述。
3. 线程池
StoneDB 的线程是基于 C ++ 新个性实现的
线程池外围类:
class utils::thread_pool
其具备以下长处:
一.StoneDB 的线程池的实现是基于 C ++11 规范的线程库:std::thread。可进行跨平台编译而无需批改代码。
二. 应用 std::condition_variable 和 std::mutex 进行线程的阻塞管制和唤醒,防止线程有效的循环和期待,进步程序效率。
三. 对增加线程的入口应用了函数模板与可变长参数模板,使之可增加任意的解决流程进入到线程池中。
四. 其中 StoneDB 零碎反对利用 std::thread::hardware_concurrency()函数或者机器的 CPU 外围数,主动的对不同线程池利用不同的调配策略来设置线程池中的线程数量,能够主动精准的配置和利用机器的 CPU,防止造成 CPU 资源利用有余和线程调配过多导致系统资源内耗的状况。同时用户也可依据机器的资源状况进行配置。
3.1 线程池类型
目前 Stone DB 引擎基于此线程池类定义了以下三类线程池
3.1.1 提早插入线程池
次要性能是将 insert buffer 中的数据加载到数据库
utils::thread_pool delay_insert_thread_pool;
3.1.2 加载导入线程池
次要性能是把插入、批改、导入的数据落地到磁盘
utils::thread_pool load_thread_pool;
3.1.3 查询处理线程池
utils::thread_pool query_thread_pool;
各类线程池和其中退出的线程执行体如下图所示:
3.2 线程池初始化流程
线程池初始化的过程是再 StoneDB 系统启动的过程中进行的初始化,次要是为各类线程池初始化实例对象,设置各类线程池的类型,和线程池的大小。
下图为线程初始化过程 StoneDB 零碎调用的流程:
4. 日志零碎
StoneDB 引擎的日志类型分为了三类,系统日志、调试日志、和查问引擎执行的后果日志。其中零碎的异样信息、异常情况的堆栈信息 和一些计时信息都记录在系统日志外面。
4.1 系统日志
系统日志把日志分为了以下 7 个级别
应用枚举类型示意各个级别
enumLogCtl_Level {DISABLED = 0, FATAL = 1, ERROR = 2, WARN = 3, INFO = 4, DEBUG = 5, TRACE = 6};
并反对将 mysql 日志级别映射到 stonedb 日志级别
StoneDB 的系统日志会对立落地到 mysql 装置目录下 /log/stonedb.log 文件
日志系统核心类:
class utils:: LogCtl
4.2 调试日志
调试日志落地到 mysql 装置目录下 /log/trace.log 文件。
由 stonedb_control_trace 该配置项管制,为 1 关上记录日志的开关,为 0 则敞开
调用接口对象:
system::Channel rccontrol
4.3 查问引擎执行的后果日志
查问引擎执行的后果日志落地到 mysql 装置目录下 /log/ query.log 文件。
由 stonedb_ini_controlquerylog 该配置项管制,为 1 关上记录日志的开关,为 0 则敞开
调用接口对象:
system::Channel rcquerylog
5. 计时器
StoneDB 的计时器 是基于 std::chrono::high_resolution_clock 实现的。
提供了 StoneDB 的计时器性能,对系统要害性能进行计时,记录下相干性能的耗时状况。耗时相干的信息会以 INFO 级别的日志信息记录在 StoneDB 的系统日志外面,日志所在的目录:mysql 装置目录下 /log/stonedb.log 文件中。
外围类:
class utils::Timer
6. 堆栈跟踪
保留堆栈的相干信息(堆栈的函数调用和堆栈的符号信息等),不便后续调试和问题排查,目前 StoneDB 零碎基于异样解决模块加上了堆栈信息的记录,如果有异常情况呈现,就会把现场的堆栈信息记录下来。堆栈的调用信息会以 WARN 级别的日志信息记录在 StoneDB 的系统日志外面,日志所在的目录:mysql 装置目录下 /log/stonedb.log 文件中。
其中为了取得堆栈信息,应用 g++ 中的 abi::__cxa_demangle 来 demangle 从 typeid 失去的 函数的 name。
调用函数接口:
GetStackTrace();
7. 异样解决
StoneDB 反对的异样解决类型如下图:
异样解决的流程图如下:
出现异常后 StoneDB 零碎会把异样信息,和出现异常逻辑的堆栈调用信息以 WARN 级别的日志信息记录在 StoneDB 的系统日志外面,日志所在的目录:mysql 装置目录下 /log/stonedb.log 文件中。
异样解决模块外围基类:
class common:: Exception