[大数据]clickhouse的一些总结

1. 写入数据到clickhouse时最好是批量写入，比如一批1000行以上，并且每一批不能创建太多的分区，因为我们知道每一次insert数据插入，对应的分区都会创建一个分区的目录，后台有专门的线程合并这些分区的目录，如果每批的数据写入的数据量都足够大，clickhouse的数据写入速度是非常高的，因为数据写入时都是磁盘的顺序io操作，支持每秒30M或者200M的顺序io速度.
2. clickhouse和es一样，他不擅长join操作，而是更擅长于把所有的字段都放在同一张表中，不过这样的话，可能容易造成数据冗余和一致性问题
3. mysql的单条sql查询操作最多只能使用一个线程，不管其他线程是否空闲，而clickhouse即使是单条sql查询也使用很多的线程，所以cpu消耗很大，往往在io到达瓶颈之前cpu已经跑满了。这也导致了clickhouse支持的qps其实很有限，所以如果你的应用有很大的qps(比如电商行业的搜索框)的话，还是建议使用elasticsearch, elasticsearch有更高的qps，并且速度更快，clickhouse更适合于olap分析应用.
4. 鉴于分布式表的写放大问题,建议按照如下对clickhouse集群进行部署:
   这样就实现了负载均衡，以及高可用的目的
5. 一些重要的配置：
   session_timeout_ms : clickhouse与zk服务器最长会话超时时间，超过改时间则认为服务器断开
   background_pool_size: 后台用于merge合并的最大线程池大小
   max_execute_time: 单个查询最大的查询超时时间
   max_memory_usage: 单个查询在单条服务器的最大内存使用量
6. 关于set 和布隆过滤器 skip index:

	`CREATE TABLE xx_table (id int32, name String, 
	INDEX s_idx_name(name) TYPE set(0) GRANULARITY 4
	INDEX bf_name(name) TYPE bloom_filter(0.1) GRANULARITY 3) ENGINE = MergeTree() ORDER BY id SETTINGS index_granularity=8192;

创建的set索引的含义：每4 * 8192行的name列的唯一值组成一个set集合保存起来，以便后面数据过滤使用
创建的BloomFilter索引的含义:每3 * 8192行name列根据误判率的值创建bitmap数组大小以及需要的hash个数，以便后面数据查询使用
注意：这两种索引文件的大小是很大的，所以读取这些索引本身也是需要耗费IO耗时的，这些读取skip index索引本身的cpu和io耗时甚至抵消了他能带来的过滤操作好处,所以生产环境使用skip index要先进行试验

参考文章:
https://www.cnblogs.com/gentlescholar/category/1997579.html

创作打卡挑战赛

赢取流量/现金/CSDN周边激励大奖