有段时间没来写博客了~ 工作太忙~
目前使用了ck和es作为olap组件，下面从使用感受上分析下优劣。

使用方式

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更加适合低成本、大数据量的分析场景，它能够充分利用磁盘的带宽能力。