关于clickhouse分区问题

距离上一次更新该文章已经过了 688 天，文章所描述的內容可能已经发生变化，请留意。

最近项目在尝试clickhouse集群部署,但是我们在做etl的时候,有个表想着为了加快响应速度,建立了分区,所以对分区知识进行了二次调研

首先分区并不能加快查询速度，而更加适用于更新或者删除数据用.

分区数量限制由max_partitions_per_insert_block控制,默认是100
当插入数据到100以上的时候,会报错
提示

sql

DB::Exception: Too many partitions for single INSERT block (more than 100). 
The limit is controlled by 'max_partitions_per_insert_block' setting. 
Large number of partitions is a common misconception. 
It will lead to severe negative performance impact, 
including slow server startup, slow INSERT queries and slow SELECT queries. 
Recommended total number of partitions for a table is under 1000..10000. 
Please note, that partitioning is not intended to speed up SELECT queries (ORDER BY key is sufficient to make range queries fast). 
Partitions are intended for data manipulation (DROP PARTITION, etc)..

分区只能在MergeTree引擎下使用

分区不会对分片造成影响

分区是表的分区，具体的DDL操作关键词是 PARTITION BY，指的是一个表按照某一列数据（比如日期）进行分区，对应到最终的结果就是不同分区的数据会写入不同的文件中。

分片复用了数据库的分区，相当于在原有的分区下，作为第二层分区，是在不同节点/机器上的体现。

下面这张图展示了clickhouse的分区和分片的关系

在分布式模式下，ClickHouse会将数据分为多个分片，并且分布到不同节点上。

创建完分区,插入好数据,执行如下sql可以看到数据分布情况

select database,table,partition,partition_id,name,path from system.parts where table='xxx';

数据文件命名规则为:PartitionID_MinBlockNum_MaxBlockNum_Level

总结,clickhouse适用的场景

plaintext

1
2
3

在partition key上进行分区裁剪，只查询必要的数据。

对partition进行TTL管理，淘汰过期的分区数据。