《这么多MergeTree 表引擎，我该怎么选？》- part 2

以不变应万变的解决之道

如果换做你是ClickHouse的开发者，你会怎么应对上述的这些挑战呢？是不是想对MergeTree内部进行改造，让它支持更多的功能？但是要想在不降低性能的前提下，直接让MergeTree支撑更多的功能好像有些不大现实，毕竟鱼与熊掌不可兼得，如果性能下降也会违背ClickHouse的设计初衷。那有没有一种方法，既不影响目前MergeTree的整体设计逻辑，又能见缝插针的让它扩展支持更多的功能呢？

这种方法是有的，也许你也已经想到了，那就是在Merge的过程中做文章。我们在此先巩固一下MergeTree合并逻辑的知识。因为MergeTree遵循了不变性设计，所以伴随着每一批次的数据写入，也就是在每执行一次INSERT语句后，不论是多次INSERT之间的数据是否相同，还是多次INSERT之间的数据是否属于同一个的分区，MergeTree总会雷打不动的在磁盘上生成一个全新的part分区目录。与此同时，ClickHouse会使用后台线程不定期的触发part分区的合并动作，当然用户也可以手动执行OPTIMIZE TABLE主动触发分区的合并。MergeTree的合并结果是将属于同一个分区的多个part分区目录，合并成一个全新的part分区目录。而它的合并逻辑，则是将多个part分区内的数据放到一起，重新按照ORDER BY的条件排序。

那么如果在合并的过程中加入一些特殊的处理逻辑会得到什么样的结果呢？例如将属于同一个分区的多个part，在按照ORDER BY的条件排序后，先将相邻的重复数据剔除，然后再去生成合并后的新part分区，这样是不是就达到了唯一性约束的条件，实现了数据去重的功能呢？

如果在MergeTree中先指定一个字段作为标记位字段，例如sign字段。当sign等于1的时候表示这行数据有效，当sign等于-1的时候表示这行数据无效。那么当触发分区合并的时候，数据在按照ORDER BY的条件排序后，将相邻数据标记位正负相抵，是不是就实现了数据更新的功能呢？

所以，基于在MergeTree合并逻辑过程中做文章的方法，以不变应万变的思路，ClickHouse在基础的MergeTree表引擎之上，又另外派生出了另外6个MergeTree的变种表引擎。

未完待续。。。

原创不易，如果这篇文章对你有帮助，欢迎 点赞、转发、在看 三连击