摘要:

gbk是monetdb中的核心, 是Goblin Database Kernel的缩写, 在monetdb中的最核心的模块, 可以说是作为逻辑优化,物理优化, 查询执行的整个汇集。

本文记录下对monetdb解读的角度

monetdb对于列存储数据库的整体上的启发:

1. 设计列存储的理论基础
2. 向量化的cpu的硬件的架构基础, cpu分支预测, pipeline 预处理, cpu的cache命中
3. 列存储与行存储的设计上的区别
   1. 行存储对于写和读的场景，分别有哪些优势和劣势
   2. 为什么行存储大部分都是在围绕b+树做处理
   3. 列存储的处理单元是列, 对于写和读的影响分别是什么
4. 列存储对读做了向量化的优化处理, 那么对于更新是如何处理，对于ACID是如何实现的?

monetdb的模块分解

一. 整体上的模块划分

参考: Design Overview | MonetDB Docs

1. 查询解析器
   1. 输入: ANSI SQL的查询语句
   2. 输出: monetdb的MAL语句，分解为BAT的关系代数形式的语句
2. 查询优化器
   1. 对于MAL语句做一些基于规则的优化
   2. 代码中是以opt开头的文件
   3. 大部分是人为的规则, 可以对比duckdb的rules
3. MAL执行器
   1. 查询执行的核心, 并且在不同的算子上做具体的优化
   2. 此处应该注意区别于基于代价的查询优化器和执行器, 不做整体的代价公式, 具体的细节可以查看monetdb中的相关设计文档
   3. 执行的基本单位是BAT，直接翻译是二进制的列关系, 而且对于列是认为是只读的，每次对于列的计算是生成一个新的列。这点上clickhouse汲取了monetdb的设计经验
   4. 内存模型和磁盘模型是一致的，磁盘的读取是基于内存映射mmap, 数据的存储结构是为了向量化的读取做了优化
   5. 此处对于如何实现更新的ACID是一个尚未被彻底解读代码的地方

二. 查询优化器

参考: MAL Optimizers | MonetDB Docs

三. MAL执行层

参考: 

1. Algebra | MonetDB Docs
2. Bat | MonetDB Docs