ClickHouse源码阅读计划(一) Everything About MergeTree.docxVIP

ClickHouse源码阅读方案(一) - Everything About MergeTree 我们晓得数据以列存方式组织，那么即便是读取一行数据也要把整个.bin文件加载到内存，那么这样是很消耗IO的，那CK是如何在存储引擎来处理IO读放大问题呢？ ClickHouse引入了颗粒度这个概念。每个data part都会被规律划分为若干个Granules，Granule作为CK在内存中进行数据扫描的单位。写入数据会依据index_granularity或者index_granularity_bytes 参数来积累成一个Granule，默认是8192行一个Granule ，当若干个Granule在内存的buffer中又积累到肯定量（min_compress_block_size 默认64KB）的时候就会触发数据压缩和落盘操作而生成一个Block。每个Granule会对应.mrk文件中的一个mrk。 Block Block作为CK进行磁盘IO的基本单位和文件压缩/解压缩的基本单位。每一个Block都有若干个Granules。在CK的代码内我们也可以看到很多以Block为单位的字节流接口，说明数据在读写字节流中都是以Block为单位进行传输的。block的大小范围取决于max_compress_block_size和min_compress_block_size,每个block的文件头都会保存该block压缩前后大小，用于数据校验。 这里顺便引见一下header:在CompressionInfo.h头文件中我们可以看到其内存规划 /** The compressed block format is as follows: * * The first 16 bytes are the checksum from all other bytes of the block. Now only CityHash128 is used. * In the future, you can provide other checksums, although it will not be possible to make them different in size. * * The next byte specifies the compression algorithm. Then everything depends on the algorithm. * * 0x82 - LZ4 or LZ4HC (they have the same format). * Next 4 bytes - the size of the compressed data, taking into account the header; 4 bytes is the size of the uncompressed data. * * NOTE: Why is 0x82? * Originally only QuickLZ was used. Then LZ4 was added. * The high bit is set to distinguish from QuickLZ, and the second bit is set for compatibility, * for the functions qlz_size_compressed, qlz_size_decompressed to work. * Although now such compatibility is no longer relevant. * * 0x90 - ZSTD * * All sizes are little endian. */ 16bytes用于存储校验和 1byte用于标记接受的压缩算法 两个4byte用来存储压缩前后大小 到这里我们就能回答我们刚才提出的两个问题： 1.mrk文件存储着若干个mrk,每个mrk对应一个Granule,分记录着Granule所在的block在压缩文件.bin的偏移量，Granule在block压缩后的偏移量，还记录着每一个Graunle的行数，分别占8个bytes，即一个mark占24个bytes。 2.有了.mrk文件，CK即便是读取一行数据，也不需要把整个.bin文件加载到内存，只需要通过.mrk文件快速定位所查询数据所在的Granule，首先依据该Granule所在的block在.bin文件中的偏移量把block找出来，然后解压，解压之后有依据.mrk中记录的该Granule在解压后的block的偏移量把该Granule找出来。然后就