如何理解ClickHouse的part和partition？

Question

我看到 clickhouse 为每个分区键创建了多个目录。

文档说目录名称格式是：分区名称，最小数据块数，最大数据块数和块级别。例如，目录名称是201901_1_11_1.

我认为这意味着该目录是属于分区201901的一部分，具有从1到11的块并且在级别1。所以我们可以有另一个部分，其目录类似于201901_12_21_1，这意味着这部分属于分区201901，具有从12到21的块并且在级别1。

所以我认为分区被分成不同的部分。我对吗？

Answer 1

部分 - 存储行的表的部分。一部分 = 一个带有列的文件夹。

分区是虚拟实体。他们没有实体代表。但是你可以说这些部分属于同一个分区。

Select 不关心分区。

Select 不知道分区键。

因为每个部分都有特殊文件 minmax_{PARTITIONING_KEY_COLUMN}.idx 这些文件包含这部分中这些列的最小值和最大值。此 minmax_ 值也存储在内存中的（c++ 向量）部件列表中。

create table X (A Int64, B Date, K Int64,C String) 
Engine=MergeTree partition by (A, toYYYYMM(B)) order by K;

insert into X values (1, today(), 1, '1');

cd /var/lib/clickhouse/data/default/X/1-202002_1_1_0/
ls -1 *.idx
minmax_A.idx   <-----
minmax_B.idx   <-----
primary.idx

SET send_logs_level = 'debug';
select * from X where A = 555;

(SelectExecutor): MinMax index condition: (column 0 in [555, 555])
(SelectExecutor): Selected 0 parts by date

SelectExecutor 检查了内存中的零件列表并找到了 0 个零件，因为 minmax_A.idx = (1,1) 并且这个选择需要 (555, 555)。

CH 不存储分区键值。

因此，例如 toYYYYMM(today()) = 202002 但是这个 202002 没有存储在部分或任何地方。

minmax_B.idx 存储（18302、18302） (2020-02-10 == select toInt16(today()))