a. 查询速度快，es是基于lucene的倒排索引实现，数据分词后预先已经排好序了，所以查询速度很快,qps较高，并且cpu消耗不大
b.es的索引字段比较灵活，可以随意的增加新字段到es中

a.数据写入时要对所有的字段进行分词操作，然后在对这些分词构建倒排索引，事实上，并不是所有的分词都会在搜索中用到，这里类似于数据预聚合的概念，有些分词是没必要的
b.es的倒排索引文件，正排文件，docvalue文件等都很大，压缩效果很小，这就造成了数据写入到IndexBuffer内存后flush到磁盘时不仅速度慢，而且磁盘占用很大，而且我们知道es搜索时是会把segment缓存到内存中的，segment文件很大也就意味着内存占用极大，不管是读取磁盘还是内存消耗都很大，硬件成本高
c.es的分片数的调整代价很大，需要新建新的索引才能做到调整分片的目的，这对于日志来说很不合理，因为你很难预先知道日志量的大小，所以分片数很难精确估计，此外，es需要很多的脚本做一些比如关闭旧索引，创建新索引等工作
d.es的查询语句有自己的一套规则，聚合查询语句尤其复杂，学习成本较高
e.es是Master-Slaver的架构，当某个分片挂掉时，Master需要重新确认并选择主分片，在这段时间内，该分片不能进行写入操作

a. clickhouse是列式存储，有分区，一级稀疏索引，二级跳数索引，列式压缩存储的优势，这使得clickhouse的数据文件很小，压缩比一般都能达到十几倍的压缩率，所以clickhouse不管是磁盘io还是内存消耗都不高，而且因为文件很小，所以即使是磁盘io，速度也很快,clickhouse的数据定位流程如下：先通过分区建确定分区，然后通过主键确定数据块，定位到读取数据块，进行解压缩并搜索
b.clickhouse充分利用了SIMD单指令多数据指令，多线程，cpu L1 L2 L3等硬件层面的优化手段，加快查询速度
c.clickhouse的所有数据都可以放到一张mergetree的表中，通过使用时间作为分区键，域名+时间戳作为主键搜索条件即可，这样几千G的文件都可以放到一个表中，不需要考虑分片等操作，管理非常方便
d.clickhouse是基于sql语句的，很容易写出各种聚合操作的sql，查询方便，学习成本低
e.clickhouse是Mul-Master的架构，无论哪个副本挂掉了，另一个副本马上可以接管写入和查询操作，中途没有任何延迟.

a. clickhouse的CPU消耗很大，因为clickhouse大量使用SIMD和多线程等手段，所以数据查询时cpu消耗很大，而且总体上来说查询速度相对es来说，查询响应的速度比es速度慢
b.clickhouse的每次insert操作，不管是批量还是只是一条数据，都会创建一个分区part的目录，如果每次都是写入小批量的数据的话，就会导致创建大量的分区part目录，clickhouse会一直忙于合并分区part，这对于clickhouse来说简直就是灾难，所以写入数据的时候，最好先按分区批量提交的方式，预先按照分区归类数据，然后一次insert写入，这样这一批的数据就只会创建一个分区part目录，这样目录文件数就会少的多，而且clickhouse也不用一直合并大量的分区目录文件了

create table ck_log(ts timestamp, domain string, loglevel string,msg string, INDEX msg_index msg token_bf_v1(10240,2,0) granularity 2) engine = ReplicateMergeTree partition by toDate(ts) order by domain,ts
以天的时间作为分区键，域名+时间戳作为一级索引查找创建日志表，单表就可以搞定几千g的日志文件了,并且对字符串列创建了二级索引（tokenbf_v1会通过标点符号对字符串进行分词），这样就通过索引直接支持msg like ‘%test clickhouse%’的模糊查询