ClickHouse 2016年开源的，由俄罗斯IT公司Yandex开发，是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)，而且查询性能优越。
主要特点：
面向列+向量执行；
自己管理存储（非Hadoop）；
线性可扩展，高可靠（通过shard+replication实现）；
DDL（数据定义语言）：可以动态地创建、修改或者删除数据库、表和视图，而无需重启服务；
DML（数据操作语言）：可以动态地查询、插入、修改或删除数据；
权限控制：可以按照用户粒度设置数据库或者表的操作权限，保障数据的安全性。
使用的场景：单表分析，这个表可以很宽。
不足：
update or delete支持较弱；
不擅长根据主键按行粒度进行查询（虽然支持），所以不应该把 ClickHouse 当做键值对数据库使用。
总原则：能够提前过滤，一定要提前过滤。
1 列裁剪与分区裁剪：
数据量太大时应避免使用 select * 操作,查询的性能会与查询的字段大小和数量成线性表换,字段越少,消耗的 io 资源越少,性能就会越高。
// 反例
select * from datasets.test;
// 正例
select test1,test2,test3,test4,test5 from datasets.test;分区裁剪就是只读取需要的分区,在过滤条件中指定。
select test1,test2,test3,test4,test5 from datasets.test where test1='2022-03-23';2 order by 结合 where、limit：
千万以上数据集进行 order by 查询时需要搭配 where 条件和 limit 语句一起使用。
// 正例
select test1,test2,test3,test4,test5 from datasets.test where test1='2022-03-23' order by test2 desc limit 1000;
// 反例
select test1,test2,test3,test4,test5 from datasets.test order by test2 desc;3 避免构建虚拟列：
如非必须,不要在结果集上构建虚拟列,虚拟列非常消耗资源浪费性能,可以考虑在前端进行处理,或者在表中构造实际字段进行额外存储。
// 反例
select test1,test2,test1/test2 as result,test3,test4,test5 from datasets.test;
// 正例:拿到test1和test1后,考虑在前端进行处理,或者在表中构造实际字段进行额外存储
select test1,test2,test3,test4,test5 from datasets.test;4 大小表 JOIN：
多表 join 时要满足小表在右的原则,右表关联时被加载到内存中与左表进行比较,ClickHouse 中无论是 Left join、Right join 还是 Inner join 永远都是拿着右表中的每一条记录到左表中查找该记录是否存在,所以右表必须是小表。
5 数据类型：
建表时能用数值型或日期时间型表示的字段，就不要用字符串——全String类型在以Hive为中心的数仓建设中常见，但CK环境不应受此影响。
虽然clickhouse底层将DateTime存储为时间戳Long类型，但不建议直接存储Long类型，因为DateTime不需要经过函数转换处理，执行效率高、可读性好。
