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集合保存起来，也就是说比如4 * 8192行的name值有100个非重复值，那么此时set集合中就会存在100个非重复的hash set值，当sql表达式中使用name in xx作为条件判断时，就可以先查询name的hash值是否在这个对应的48192的区域内，如果不在直接排除掉这个区域即可
创建的BloomFilter索引的含义:每3 * 8192行name列根据误判率的值创建bitmap数组大小以及需要的hash个数，比如每个38192行的name记录创建一个100长度bitmap数组，使用3个hash函数，当sql表达式中使用name in xx作为条件判断时，也可以首先通过布隆过滤器判断name是否在对应的3*8192这个区域内，如果不在直接排除掉这个区域即可
注意：这两种索引文件的大小是很大的，所以读取这些索引本身也是需要耗费IO耗时的，这些读取skip index索引本身的cpu和io耗时甚至抵消了他能带来的过滤操作好处,所以生产环境使用skip index要先进行试验。
ps：日志表中查询message字段的关键字匹配时最常使用到的二级索引是tokenbf_v1索引，他可以优化关键字的匹配，比如优化类似message like '%test clickhouse%'等的查询，提高模糊匹配的性能，所以为了达到模糊匹配的效果，对字符串列创建tokenbf_v1索引非常关键，否则性能上很难超越ES全文搜索.