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

本文首发于 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_0 和 1_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 来爱护客户端的高频、大量写机制，缩小服务端目录和文件数量，让客户端操作尽可能简略、高效。

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