分布式结构
clickhouse是multi-master结构，即所有节点均是数据操作节点，每个节点均知道所有的数据片存放的节点
ES是master-slave 结构，分master节点和数据节点，数据meta信息存放于master节点
使用方式
ck使用SQL， es使用DSL，DSL有些复杂，特别是一些复杂查询非常难写，有一定的学习成本和开发成本。
es周边的工具比较完善，Logstash或Beats用于收集、聚合数据写入到ES中，上层是Kibana可以灵活搭建看板，ES提供存储和查询、分析服务，统称为ELK套件。
ck的话我们使用是自己开发了一个平台，用于查询，看板展示。
写入
首先ck写入的吞吐量远远超过es。
es是近实时的写入，按照先写内存，tanslog，然后refresh生成新的segment才能被搜索。
ck直接落盘，并且主推在客户端攒批次写入。
在副本同步上，es所有副本实时同步，也就是写入请求必须写穿多个副本才会返回，而ClickHouse是依赖于ZooKeeper做异步的磁盘文件同步。
查询能力
大查询能力
ES不具备数据库的流式处理能力，它的查询方式为query_then_fetch query_and_fetch，查询请求节点会拉取各个数据节点的查询结果到内存，如果结果很大会导致OOM或者GC，查询失败。
ES不适合大批量的数据查询，高频次深度分页导出导致ES宕机、不能精确去重统计，多个字段聚合计算时性能下降明显。
查询性能
在查询扫描数据的过程中，首先会根据存储的主键、数据标记文件等信息推断出需要扫描的block，进行并行的数据扫描。之后进行向量化计算，对内存中的列式数据，一个batch调用一次SIMD指令（而非每一行调用一次），不仅减少了函数调用次数、降低了cache miss，而且可以充分发挥SIMD指令的并行能力，大幅缩短了计算耗时。
对于ES来讲，查询有一个cache加速，但是对于分析场景下的数据和查询都是多变的，查询结果等Cache都不容易命中。而且对于聚合计算的场景，使用倒排索引来查找docid,然后在doc_value里进行聚合计算，存储上也要存两份。
并发查询能力
es的并发相对好一些，主要是因为ck一个查询就会把负载打满，机器的性能决定了并发上限。
负载打满的原因：ck查询使用向量化执行引擎，一次对一批数据进行并发计算。
去重
目前ck是不能做到支持全局去重的，ES是可以按照id进行去重。
线上情况
目前已有的计费数据要求不重复，使用ES。原始日志写入量大，查询量大，使用ck，并且将一些大查询的场景逐渐往ck迁移，比如topurl。
总结来说，Elasticsearch只有在完全搜索场景下面（where过滤后的记录数较少），并且内存足够的运行环境下，才能展现出并发上的优势。而在分析场景下（where过滤后的记录数较多），ClickHouse凭借极致的列存和向量化计算会有更加出色的并发表现。两者的侧重不同而已，同时ClickHouse并发处理能力立足于磁盘吞吐，而Elasticsearch的并发处理能力立足于内存Cache。ClickHouse更加适合低成本、大数据量的分析场景，它能够充分利用磁盘的带宽能力。
高并发效率
高并发效率一般以吞吐能力作为判断标准。 clickhouse一个查询都会占用一半的CPU，ES直接查询内存，所以ES的高并发处理能力更好（阿里云的clickhouse完善了二级索引从而降低了IO吞吐压力所以在高并发效率和ES旗鼓相当）。由于ES是预热数据到内存，当查询返回数据量大的时候由于产生大量的IO，反而ES处理能力会急剧下降，clickhouse并行扫描数据分片所以无论扫描多少数据块耗时都是一样的。
单并发效率
单并发效率一般以响应时间作为判断标准（即扫描效率）。
ES先查询二级索引，然后再扫描一级索引（数据和一级索引是同一个B+树节点，所有无需再次查询数据），所有ES一次查询经过2次数据扫描。
clickhouse采用的是列式存储（列存储的数据因为数据的相似度更高所以压缩比更高，IO吞吐压力相对较低）并使用SIMD实现向量化（列式存储才支持向量化查询）执行（离CPU越近访问越快）
由于clickhouse的扫描能力更加出色，所以clickhouse的单并发比ES更加出色。
计算能力
ES是汇合制模式，即各节查询top数据然后合并到查询节点再次进行top排序，由于不具备流式计算能力当返回数据量非常大的时候容易产生GC或者把节点跑死。
clickhouse利用C++写的向量化计算 加上 借住SIMD计算能力，使得查询聚合操作发挥极高的效率。
技术选型
clickhouse 是列式存储所以无法进行全文检索，所以更适合数据分析的需求。
elasticsearch更适合高并发并且查询返回结果较少的全文检索，如搜索引擎。
