clickhouse join注意点及自定义存储策略

一般来说，使用clickhouse和es一样，都是使用的宽表的形式，即一张表中包含了很多的字段，建立的模型不是类似于之前常见的雪花或者星型模型，所以我们一般都会尽量避免join操作，不过如果我们真的需要表join操作时(比如A join B)，需要注意以下几点:
a. 右边的表B是小表，clickhouse目前不论是处理left join，right join，inner join都是先把右表B加载到内存中，然后对于B表中的每一行再去寻找A表中满足条件的记录 ----注意对于clickhouse来说，主键是可以重复的，不是唯一的，它仅仅是作为数据查找，而不是用于约束记录的唯一性
b.A和B表join之前最好先保证各自的数据记录条数是最少的，很多时候先执行group by之后在进行数据join会比先进行数据join在进行group by要快得多

自定义存储策略

这里介绍常见的hotcold策略，并且每个hot或者cold区域内支持jbod策略，使用自定义的存储策略的sql建表语句如下:

create table hc_table (id uint32, name string, createtime date) engine=mergetree() partition by toyymmdd(createtime) order by id settings storage_policy = ‘自定义存储策略名称’;

a.首先配置策略:

<policies>
	<hotcoldpolicy> --自定义策略名称
		<volumns>
			<hotvolumn> --自定义卷磁盘区域
				<disk>hot_disk_a</disk>
				<disk>hot_disk_b</disk>
				<max_data_part_size>1M</max_data_part_size>
			</hotvolumn>
			<coldvolumn> --自定义卷磁盘区域
				<disk>cold_disk_c</disk>
				<disk>cold_disk_d</disk>
			</codevolumn>
		</volumns>
	</hotcodepolicy>
</policies>

假设我们配置的策略如上所述，那么当对表进行insert或者merge合并的时候有如下规则：
假设insert插入的数据所产生的分区目录的大小小于1M，那么数据将会存放到hotvolumn卷中，也就是说会按照顺序存放到hot_disk_a 和hot_disk_b中，如果插入或者merge产生的分区目录的数据大小大于1M的话，分区目录会被移动到coldvolumn中，也就是按照顺序移动到cold_disk_c和cold_disk_d中。
我们可以从系统表：system.disks，system.storage_policy,system.parts 查看存储策略以及各个分区目录所属的磁盘。此外通过 alter table xx move part yy to disk zz的形式是可以把分区从一次磁盘移动到另外一块磁盘中的。