【StoneDB Class】入门第四课:StoneDB 的体系结构

本次课程为大家介绍 StoneDB 的体系结构。StoneDB 的体系结构分为内存管理和文件管理,其中内存管理由内存堆和线程池组成,文件管理由分布在磁盘的一系列物理文件组成。


image.png

image.png

内存

Main Heap

主堆内存,对数据进行更新和查询会分配主堆内存用于缓存数据,执行批量插入会分配 insert buffer,由参数 tianmu_ini_servermainheapsize 控制主堆内存大小,单位为 MB,默认值为操作系统物理内存的1/2。StoneDB 启动时可以在 tianmu.log 看到 Main Heap 分配的大小,主堆内存的大小建议保持默认值。

System Heap

系统堆内存,当主堆内存使用达到最大限制时,使用该内存。由于主堆内存在默认情况下已经分配了操作系统物理内存的1/2,因此正常情况下是不会出现使用系统堆内存的。如果出现了使用系统堆内存的情况,大概率是由于 SQL 消耗大量内存或者系统发生了内存泄漏。

Large Temporary Heap

临时堆内存,执行 group by、union 以及子查询时会分配该内存,用于缓存临时结果集。临时堆内存大小由参数 tianmu_mm_largetempratio 和 tianmu_ini_servermainheapsize 的乘积决定,前者参数值是个百分比,默认是0,表示不使用临时堆内存,用的是主堆内存。StoneDB 启动时可以在 tianmu.log 中看到 Large Temporary Heap 分配的大小,由于主堆内存已分配操作系统物理内存的1/2,因此临时堆内存的大小建议保持默认值。

image.png

线程池

delay_insert_thread_pool
创建和分配 delay insert thread,线程的作用是将 insert buffer 中的数据刷新到磁盘,由参数 tianmu_bg_load_threads 控制线程池中线程数量,默认为0,表示线程池中的线程数量等于 CPU 核数的1/2。StoneDB 启动时可以在 tianmu.log 中看到分配的线程数。

load_thread_pool
创建和分配 load thread,线程的作用是将插入、修改、导入的数据刷新到磁盘,由参数 tianmu_load_threads 控制线程池中线程数量,默认为0,表示线程池中的线程数量等于 CPU 核数。StoneDB 启动时可以在 tianmu.log 中看到分配的线程数。

query_thread_pool
创建和分配 query thread,线程的作用是用于查询,由参数 tianmu_query_threads 控制线程池中线程数量,默认为0,表示线程池中的线程数量等于 CPU 核数。StoneDB 启动时可以在 tianmu.log 看到分配的线程数。


image.png

物理存储结构

StoneDB 的物理存储结构指的是存储在文件系统上的文件,包括参数文件、数据文件、日志文件。

image.png

参数文件

参数文件记录了各个文件所在的位置以及实例启动时的初始化参数等,参数文件的默认位置在 basedir 下,文件名默认为 my.cnf,StoneDB 的参数名以“tianmu”为前缀。参数文件中的参数根据是否可以在实例中直接修改,分为以下两类参数:

1)动态参数:可以在实例中直接修改,并且可基于当前变量或者全局变量进行修改,但实例重启后会失效,如 tianmu_force_hashjoin。

2)静态参数:不能直接在实例中修改,只能修改参数文件,并且实例重启后才生效,如 tianmu_insert_buffer_size。

数据文件

在 StoneDB 创建一张表,文件系统上会自动创建以表名命名的两个文件,一个是表结构定义文件,命名为 xxx.frm,另一个是数据文件,命名为 xxx.tianmu。表结构定义文件包含表结构的描述,无论哪种存储引擎,只要创建一张表,就会创建表结构定义文件,我们重点关注的是数据文件。

数据文件下面分为1个目录和3个文件,结构如下所示:

├── columns
│   ├── 0 -> /stonedb/install/data/stonedb_data/22.0
│   ├── 1 -> /stonedb/install/data/stonedb_data/22.1
│   ├── 2 -> /stonedb/install/data/stonedb_data/22.2
│   ├── 3 -> /stonedb/install/data/stonedb_data/22.3
│   ├── 4 -> /stonedb/install/data/stonedb_data/22.4
│   ├── 5 -> /stonedb/install/data/stonedb_data/22.5
│   ├── 6 -> /stonedb/install/data/stonedb_data/22.6
│   └── 7 -> /stonedb/install/data/stonedb_data/22.7
├── TABLE_DESC
├── V.62d643a500002720
└── VERSION -> V.62d643a500002720

TABLE_DESC
返回值是 TianmuTB,表示表使用的存储引擎是 Tianmu。

V.xxx
表的版本号,创建一个新表后,版本号默认是 V.0000000000000000,对表做 DML 后,版本号就会递增。如果执行 DML ,但没有匹配的行,版本号保持不变。如果执行 DDL ,版本号不会立即改变。

VERSION
V.xxx 的软连接。

columns
StoneDB 是个列式存储数据库,创建的表有多少个列,在文件系统上就有多少个从 0 开始递增的编号。即0表示表的第一个字段,1表示表的第二个字段,以此类推。上文中 columns 目录下有编号 0~7 的子目录,说明这张表有 8 个列,每个编号的子目录下面又分了 2 个目录和 3 个文件,结构如下所示:


├── DATA
├── DN
├── filters
│   ├── bloom
│   ├── cmap
│   └── hist
├── META
└── v
    └── 62d643a500002720

DATA
存储的是经过压缩后的 Data Pack,一个 Data Pack 存储了65,536行数据。如果一个 Data Pack 是可疑的,那么线程就会从 DATA 文件读取这个 Data Pack 到内存,知识网格对这个可疑的 Data Pack 进行解压缩,然后读取解压出来符合查询条件的数据行。

DATA 文件大小与 information_schema.columns 中 column_comment 返回值近似。

DN
存储的是 Data Pack Node,记录了 Data Pack 的基本元数据,包含 Data Pack 中列的最大值、最小值、平均值、总和、总记录数、null值的数量。Data Pack Node 与 Data Pack 是一一对应的关系。

META
存储的是 Data Pack 的压缩格式以及其列的数据类型等。

V
和上文提到的 VERSION 相同,是个版本号。

filters
filters 目录下是知识节点的基本类型,正常情况下是个空目录,数据被加载时会自动创建。

hist:数据类型为整型、日期型、浮点型的列的统计值以直方图的形式存在。将一个数据包的最小值到最大值之间分为1,024段,每段占用一个 bit,如果数据包中的实际值处于段中的范围,则标记为1,否则标记为0。

cmap:数据类型为字符串的列的字符映射表。统计当前数据包内 1~64 长度中 ASCII 字符是否存在。如果存在,则标记为1,否则标记为0。字符检索时,按照字符顺序依次对比字符标识值即可知道该数据包是否包含匹配数据。

日志文件
StoneDB 的日志文件有三种,分别是 tianmu.log、trace.log、query.log,其中 tianmu.log 是 StoneDB 的引擎日志,记录了 StoneDB 运行过程中的详细信息,以上三种日志默认都在 basedir/log 下。

tianmu.log
记录了 StoneDB 在启动和关闭过程的详细信息,以及 StoneDB 在运行过程中发生的较为严重的错误信息、警告信息、状态信息,发生错误时的调用堆栈等。

StoneDB 在启动时,会记录分配的线程数、主堆内存大小、insert buffer 大小等。如果在 StoneDB 创建不支持的对象会有错误提示,创建不支持的数据类型会有告警提示,并且会显示调用的堆栈。tianmu.log 也会记录在 StoneDB 创建和删除的对象,并且记录过去一分钟内发生的查询次数,更新、插入、插入失败行数,以及自上一次 StoneDB 启动以来,查询总次数,更新、插入、插入失败总行数。

trace.log
trace.log 记录了 StoneDB 的 debug 版本在进行调试时的日志。如果想知道表关联使用的是哪种表连接方式可开启参数 tianmu_control_trace,然后观察 trace.log 的输出。

如果是 StoneDB 的 release 版本,即便开启了参数 tianmu_control_trace,trace.log 也没有任何输出,因为参数 tianmu_control_trace 只对 StoneDB 的 debug 版本有效。

query.log
query.log 记录了在 StoneDB 发起的任何查询语句,由参数 tianmu_ini_controlquerylog 控制,默认为1,表示在 StoneDB 发起的任何查询语句都会被记录。由于生产环境的查询语句很多,如果开启参数 tianmu_ini_controlquerylog,那么 query.log 会很大,且可筛选性较差。在运维中常用的方法是开启慢查询日志,针对执行时间超过指定阀值的 SQL 进行记录,因此生产环境建议关闭这个参数,query.log 不记录任何的查询语句。

以上是本次课程的全部内容,下节课程将为大家介绍关于 StoneDB 的表连接方式,请各位继续关注。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 217,406评论 6 503
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,732评论 3 393
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 163,711评论 0 353
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,380评论 1 293
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,432评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,301评论 1 301
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,145评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,008评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,443评论 1 314
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,649评论 3 334
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,795评论 1 347
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,501评论 5 345
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,119评论 3 328
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,731评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,865评论 1 269
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,899评论 2 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,724评论 2 354

推荐阅读更多精彩内容