关于clickhouse:源码分析-ClickHouse和他的朋友们10MergeTree-WriteAhead-Log

41次阅读

共计 1616 个字符,预计需要花费 5 分钟才能阅读完成。

本文首发于 2020-08-20 19:55:14

《ClickHouse 和他的敌人们》系列文章转载自圈内好友 BohuTANG 的博客,原文链接:
https://bohutang.me/2020/08/1…
以下为注释。

数据库系统为了进步写入性能,会把数据先写到内存,等“攒”到肯定水平后再回写到磁盘,比方 MySQL 的 buffer pool 机制。

因为数据先写到内存,为了数据的安全性,咱们须要一个 Write-Ahead Log (WAL) 来保障内存数据的安全性。

明天咱们来看看 ClickHouse 新增的 MergeTreeWriteAheadLog 模块,它到底解决了什么问题。

高频写问题

对于 ClickHouse MergeTree 引擎,每次写入 (即便1条数据) 都会在磁盘生成一个分区目录(part),等着 merge 线程合并。

如果有多个客户端,每个客户端写入的数据量较少、次数较频繁的状况下,就会引发 DB::Exception: Too many parts 谬误。

这样就对客户端有肯定的要求,比方须要做 batch 写入。

或者,写入到 Buffer 引擎,定时的刷回 MergeTree,毛病是在宕机时可能会失落数据。

MergeTree WAL

1. 默认模式

咱们先看看在没有 WAL 状况下,MergeTree 是如何写入的:

每次写入 MergeTree 都会间接在磁盘上创立分区目录,并生成分区数据,这种模式其实就是 WAL + 数据的交融。

很显然,这种模式不适宜频繁写操作的状况,否则会生成十分多的分区目录和文件,引发 Too many parts 谬误。

2. WAL 模式

设置 SETTINGS: min_rows_for_compact_part=2,别离执行2条写 SQL,数据会先写到 wal.bin 文件:

当满足 min_rows_for_compact_part=2 后,merger 线程触发合并操作,生成 1_1_2_1 分区,也就是实现了 wal.bin 里的 1_1_1_01_2_2_0 两个分区的合并操作。当咱们执行第三条 SQL 写入:

insert into default.mt(a,b,c) values(1,3,3)

数据块 (分区) 会持续追加到 wal.bin 尾部:

此时,3 条数据分布在两个中央:分区 1_1_2_1,wal.bin 里的 1_3_3_0

这样就有一个问题:当咱们执行查问的时候,数据是怎么合并的呢?

MergeTree 应用全局构造 data_parts_indexes 保护分区信息,当服务启动的时候,MergeTreeData::loadDataParts办法:

  1. data_parts_indexes.insert(1_1_2_1)
  2. 读取 wal.bin,通过 getActiveContainingPart 判断分区是否曾经 merge 到磁盘:1_1_1_0 曾经存在, 1_2_2_0 曾经存在,data_parts_indexes.insert(1_3_3_0)
  3. data_parts_indexes:{1_1_2_1,1_3_3_0}

这样,它总是能保护全局的分区信息。

总结

WAL 性能在 PR#8290 实现,master 分支曾经默认开启。

MergeTree 通过 WAL 来爱护客户端的高频、大量写机制,缩小服务端目录和文件数量,让客户端操作尽可能简略、高效。


欢送关注我的微信公众号【数据库内核】:分享支流开源数据库和存储引擎相干技术。

题目 网址
GitHub https://dbkernel.github.io
知乎 https://www.zhihu.com/people/…
思否(SegmentFault) https://segmentfault.com/u/db…
掘金 https://juejin.im/user/5e9d3e…
开源中国(oschina) https://my.oschina.net/dbkernel
博客园(cnblogs) https://www.cnblogs.com/dbkernel

正文完
 0