ClickHouse各种MergeTree的关系与作用

在ClickHouse的整个体系里面,MergeTree表引擎绝对是一等公民,使用ClickHouse就是在使用MergeTree,这种说法一点也不为过。

众所周知,MergeTree表引擎是一个家族系列,目前整个系列一共包含了14种不同类型的MergeTree,可谓是功能丰富了吧?

但凡事都有两面性,功能丰富的同时也无疑让很多朋友犯了难。

这么多表引擎,它们之间是什么关系?

我们到底应该使用哪一种表引擎?

今天我就用这篇文章,尝试回答上述两个高频问题。

老师常教导我们要训练结构化思维,通过抽象、归纳等办法来分析一个事物,有时候会起到事半功倍的效果。


这么多表引擎,它们之间是什么关系?

我们可以使用两种关系,来理解整个MergeTree系列:

  • 继承关系

首先,为了便于理解,可以使用继承关系来看待MergeTree。通过最基础的MergeTree表引擎,向下派生出6个变种表引擎,如下图所示

ClickHouse各种MergeTree的关系与作用_第1张图片

在ClickHouse底层具体的实现方法中,上述7种表引擎的区别主要体现在Merge合并的逻辑部分。如下图所示,是我简化后的对象关系:

ClickHouse各种MergeTree的关系与作用_第2张图片

可以看到,在具体的实现逻辑部分,7种MergeTree共用一个主体,在触发Merge动作时,调用了各自独有的合并逻辑。

而除开MergeTree之外的其他6个变种表引擎,它们的Merge合并逻辑,全部是建立在MergeTree基础之上的,如下图所示:

ClickHouse各种MergeTree的关系与作用_第3张图片

它们均继承于MergeTree的 MergingSortedBlockInputStream。

MergingSortedBlockInputStream 的主要作用,是按照ORDER BY的规则保持新分区数据的有序性。

而其他6种变种MergeTree的合并逻辑,则是在有序的基础之上 "各有所长",要么是将排序后相邻的重复数据消除、亦或是将它们累加汇总。

所以,从继承关系的角度来理解,我们不仅明白了这7种MergeTree的关系,也进一步明确了一个事实,它们的主要区别在Merge部分的逻辑,所以特殊功能只会在Merge合并时才会触发。

  • 组合关系

刚才已经介绍了7种MergeTree的关系,余下的7种是ReplicatedMergeTree系列。

ReplicatedMergeTree与普通的MergeTree又有什么区别呢?  我们接着看下面这张图:

ClickHouse各种MergeTree的关系与作用_第4张图片

图中的虚线框部分是MergeTree的能力边界,而ReplicatedMergeTree在它的基础之上增加了分布式协同的能力。


借助ZooKeeper的消息日志广播,实现了副本实例之间的数据同步功能。

ReplicatedMergeTree系列可以用组合关系来理解,如下图所示:

ClickHouse各种MergeTree的关系与作用_第5张图片

当我们为7种MergeTree加上Replicated前缀后,又能组合出7种新的表引擎,这些ReplicatedMergeTree拥有副本协同的能力。


我们到底应该使用哪一种表引擎?

现在回答第二个问题,按照使用的场景划分,可以将上述14种表引擎大致分成以下6类应用场景:

  • 默认情况

在没有特殊要求的场合,使用基础的MergeTree表引擎即可,它不仅拥有高效的性能,也提供了所有MergeTree共有的基础功能,包括列存、数据分区、分区索引、一级索引、二级索引、TTL、多路径存储等等。

ClickHouse各种MergeTree的关系与作用_第6张图片

与此同时,它也定义了整个MergeTree家族的基调,例如:

ORDER BY 决定了每个分区中数据的排序规则;

PRIMARY KEY 决定了一级索引(primary.idx);

ORDER BY 可以指代PRIMARY KEY, 通常只用声明ORDER BY 即可。

接下来将要介绍的其他表引擎,除开ReplicatedMergeTree系列外,都是在Merge合并动作时添加了各自独有的逻辑。

  • 数据去重

通过刚才的说明,大家应该明白,MergeTree的主键(PRIMARY KEY)只是用来生成一级索引(primary.idx)的,并没有唯一性约束这样的语义。

一些朋友在使用MergeTree的时候,用传统数据库的思维来理解MergeTree就会出现问题。

如果业务上不允许数据重复,遇到这类场景就可以使用ReplacingMergeTree,如下图所示:

ClickHouse各种MergeTree的关系与作用_第7张图片

ReplacingMergeTree通过ORDER BY,表示判断唯一约束的条件。当分区合并之时,根据ORDER BY排序后,相邻重复的数据会被排除。

由此,可以得出几点结论:

第一,使用ORDER BY作为特殊判断标识,而不是PRIMARY KEY。关于这一点网上有一些误传,但是如果理解了ORDER BYPRIMARY KEY的作用,以及合并逻辑之后,都能够推理出应该是由ORDER BY决定。

ORDER BY的作用, 负责分区内数据排序;

PRIMARY KEY的作用, 负责一级索引生成;

Merge的逻辑, 分区内数据排序后,找到相邻的数据,做特殊处理。

第二,只有在触发合并之后,才能触发特殊逻辑。以去重为例,在没有合并的时候,还是会出现重复数据。

第三,只对同一分区内的数据有效。以去重为例,只有属于相同分区的数据才能去重,跨越不同分区的重复数据不能去重。
 

上述几点结论,适用于包含ReplacingMergeTree在内的6种MergeTree,所以后面不在赘述。

  • 预聚合(数据立方体)

有这么一类场景,它的查询主题是非常明确的,也就是说聚合查询的维度字段是固定,并且没有明细数据的查询需求,这类场合就可以使用SummingMergeTree或是AggregatingMergeTree,如下图所示:

ClickHouse各种MergeTree的关系与作用_第8张图片

可以看到,在新分区合并后,在同一分区内,ORDER BY条件相同的数据会进行合并。如此一来,首先表内的数据行实现了有效的减少,其次度量值被预先聚合,进一步减少了后续计算开销。

聚合类MergeTree通常可以和表引擎协同使用,如下图所示:

ClickHouse各种MergeTree的关系与作用_第9张图片

可以将物化视图设置成聚合类MergeTree,将其作为固定主题的查询表使用。

值得一提的是,通常只有在使用SummingMergeTree或AggregatingMergeTree的时候,才需要同时设置ORDER BYPRIMARY KEY。

显式的设置PRIMARY KEY,是为了将主键和排序键设置成不同的值,是进一步优化的体现。

例如某个场景的查询需求如下:

聚合条件,GROUP BY A,B,C

过滤条件,WHERE A

此时,如下设置将会是一种较优的选择:

GROUP BY A,B,C

PRIMARY KEY A

BTW,如果ORDER BYPRIMARY KEY不同,PRIMARY KEY必须是ORDER BY的前缀(为了保证分区内数据和主键的有序性)。

  • 数据更新

数据的更新在ClickHouse中有多种实现手段,例如按照分区Partition重新写入、使用Mutation的DELETE和UPDATE查询。

使用CollapsingMergeTree或VersionedCollapsingMergeTree也能实现数据更新,这是一种使用标记位,以增代删的数据更新方法,如下图所示:

ClickHouse各种MergeTree的关系与作用_第10张图片

通过增加一个标志字段(例如图中的sigh字段),作为数据有效性的判断依据。

可以看到,在新分区合并后,在同一分区内,ORDER BY条件相同的数据,其标志值为1和-1的数据行会进行抵消。

下图是另外一种便于理解的视角,就如同挤压瓦楞纸一般,数据被抵消了:

ClickHouse各种MergeTree的关系与作用_第11张图片

CollapsingMergeTree和VersionedCollapsingMergeTree的区别又是什么呢?

CollapsingMergeTree对数据写入的顺序是敏感的,它要求标志位需要按照正确的顺序排序。例如按照1,-1的写入顺序是正确的; 而如果按照-1,1的错误顺序写入,CollapsingMergeTree就无法正确抵消。

试想,如果在一个多线程并行的写入场景,我们是无法保证这种顺序写入的,此时就需要使用VersionedCollapsingMergeTree了。

VersionedCollapsingMergeTree在CollapsingMergeTree基础之上,额外要求指定一个version字段,在分区Merge合并时,它会自动将version字段追加到ORERY BY的末尾,从而保证了标志位的有序性。

ENGINE = VersionedCollapsingMergeTree(sign,ver)ORDER BY id//等效于ORDER BY id,ver

  • 监控集成

GraphiteMergeTree可以与Graphite集成,如果你使用了Graphite作为系统的运行监控系统, 则可以通过GraphiteMergeTree存储指标数据,加速查询性能、降低存储成本。

  • 高可用

Replicated* 拥有数据副本的能力,如下图所示:

ClickHouse各种MergeTree的关系与作用_第12张图片

结合刚才的5类场景,如果进一步需要高可用的需求,选择一种MergeTree和Replicated组合即可,例如ReplicatedMergeTree、ReplicatedReplacingMergeTree等等。

你可能感兴趣的:(clickhouse,数据库,clickhouse,java,开发语言)