ClickHouse 特性及存储原理.docxVIP

ClickHouse 特性及存储原理 列式数据库是以列相关存储架构进行数据存储的数据库，次要适合于批量数据处理和 OLAP。相对应的是行式数据库，数据以行相关的存储体系架构进行空间安排，次要适合于小批量的数据处理，常用于 OLTP。 以下述数据为例进行行式与列式存储的简约分析： 常见的数据库如：MySQL、Postgres 为行式存储数据库，需要把二维表存储在一系列一维的“字节”中，由操作系统写到内存或硬盘中。行式存储数据库把一“行”数据存储在一起，然后再存储下一“行”；读取时也依据行为单位读取，即便只需要其中的几个字段内容也是需要读取整行数据再进行过滤。简化的存储格式： 1,zhang,san,shanghai,182xxxxxxxx,male 2,li,si,beijing,182xxxxxxxx,female 3,wang,wu,shenzhen,182xxxxxxxx,male 4,he,liu,guangzhou,182xxxxxxxx,unknow 列式存储则与之相反，以 ClickHouse 为例，规律上一行数据照旧是由多个不同的 column 组成，但列存储会将二维表中同一列的数据组织在一起，以 ClickHouse 为例：一列数据在物理硬盘上对应于一组文件，落盘存储前，ClickHouse 会对列数据进行压缩，相同类型的数据在一起压缩能供应更高压缩比；读取时也会优先对 SQL 进行解析和裁剪，只加载指定列数据，从而有效的降低数据从文件系统中加载的耗时。这是 ClickHouse 核心优势之一。 简化的存储格式（最终一行为对应列在文件系统中存储的文件名）： 1 |zhang |san |shanghai |182xxxxxxxx|male 2 |li |si |beijing |182xxxxxxxx|female 3 |wang |wu |shenzhen |182xxxxxxxx|male 4 |he |liu |guangzhou |182xxxxxxxx|unknow ... | ... | ... | ... | ... | ... row.bin |last_name.bin|first_name.bin|address.bin|phone.bin |sex.bin 数据存储 ClickHouse 中有众多的不同特性的表引擎可以应对不同的需要，其中 MergeTree 引擎作为 ClickHouse 的核心，凭仗其强大的功能与丰富的特性得到了广泛的使用，并成为其他特性引擎的基础。后续将基于 MergeTree 引擎进行争辩。 由于 ClickHouse 的更新迭代较快，相邻版本之间的数据存储结构以及特性会有变化，但基本原理相通，本文基于 21.6.5 版本做演示和说明。 文件结构 在 ClickHouse 中，每个表都对应文件系统中的一个名目，名目中不同的文件保存了表数据与相关的属性信息，例如我们创建如下的表，并写入一些数据： CREATE TABLE id_test ( `ID` Int64, `StringID` FixedString(24) ) ENGINE = MergeTree ORDER BY (ID, StringID) SETTINGS min_rows_for_wide_part = 0, min_bytes_for_wide_part = 0； insert into id_test values(1,1)(2,2) 执行成功后会在文件系统中创建如下的名目结构： id_test ├── all_1_1_0 │ ├── ID.bin │ ├── ID.mrk2 │ ├── StringID.bin │ ├── StringID.mrk2 │ ├── checksums.txt │ ├── columns.txt │ ├── count.txt │ └── primary.idx ├── detached └── format_version.txt 说明： id_test：每个表在文件系统都对应于一个名目，以表名命名。 all_1_1_0：假如对表进行了分区，那么每个分区的都会有相应的名目，本例没有进行分区，所以只要一个名目。 checksums.txt：校