简介：本文的宗旨在于通过彻底分析 ClickHouse 和 Elasticsearch 的内核架构，从原理上讲明确两者的优劣之处，同时会附上一份笼罩多场景的测试报告给读者作为参考。
作者：阿里云数据库 OLAP 产品部 仁劼
Clickhouse 是俄罗斯搜寻巨头 Yandex 开发的齐全列式存储计算的剖析型数据库。ClickHouse 在这两年的 OLAP 畛域中始终十分热门，国内互联网大厂都有大规模应用。Elasticsearch 是一个近实时的分布式搜寻剖析引擎，它的底层存储齐全构建在 Lucene 之上。简略来说是通过扩大 Lucene 的单机搜寻能力，使其具备分布式的搜寻和剖析能力。Elasticsearch 通常会和其它两个开源组件 Logstash（日志采集）和 Kibana（仪表盘）一起提供端到端的日志 / 搜寻剖析的性能，经常被简称为 ELK。
明天很多用户在理论的业务场景中，经常面对 ClickHouse 和 Elasticsearch 技术选型的难题。用户对 ClickHouse 和 Elasticsearch 的内核常识理解有余，往往只能通过性能测试的伎俩来进行选型。本文的宗旨在于通过彻底分析 ClickHouse 和 Elasticsearch 的内核架构，从原理上讲明确两者的优劣之处，同时会附上一份笼罩多场景的测试报告给读者作为参考。
分布式架构
Elasticsearch 和 ClickHouse 都是反对分布式多机的数据产品，这里作者首先要比对的就是两者的分布式架构差别，分布式结构设计对产品的易用性和可扩展性具备十分重要的影响。在分布式架构上，外围要解决的几个问题包含：节点发现、Meta 同步、正本数据同步。Elasticsearch 作为一个老牌的开源产品，在这块上做的绝对比拟成熟。原生的节点发现、Meta 同步协定，给用户十分好的易用性体验。Elasticsearch 的 Meta 同步协定须要解决的问题其实和开源的 Raft 协定十分类似，只不过在 Elasticsearch 诞生的时候还没有 Raft 呈现，所以就只能本人入手搞一个了。通过这么多年的打磨，Elasticsearch 的 Meta 同步协定也是相当成熟了。依靠于此，Elasticsearch 具备十分易用的多角色划分，auto schema inference 等性能。值得一提的是 Elasticsearch 的多正本数据同步，并没有复用 Meta 同步协定，而是采纳传统的主备同步机制，由主节点负责同步到备节点，这种形式会更加简略高效。
ClickHouse 的分布式架构能力绝对会简略一些，这也是因为 ClickHouse 还是一个比拟年老的开源产品，还处在分布式易用性一直迭代回升的阶段。ClickHouse 引入了外置的 ZooKeeper 集群，来进行分布式 DDL 工作（节点 Meta 变更）、主备同步工作等操作的下发。多正本之间的数据同步（data shipping）工作下发也是依赖于 ZooKeeper 集群，但最终多正本之间的数据传输还是通过 Http 协定来进行点对点的数据拷贝，同时多正本都可写，数据同步是齐全多向的。至于节点发现，ClickHouse 目前都没有这方面的能力，都是须要通过手动配置集群节点地址来解决。ClickHouse 目前这种脚手架式的分布式架构，导致它具备极强的灵便部署能力和运维染指能力，对用户的易用性略差，用户门槛绝对较高，然而在能力下限方面，ClickHouse 的分布式部署扩展性并没有短板，集群规模下限比照 Elasticsearch 没有差别。ClickHouse 架构扁平，没有前端节点和后端节点之分，可部署任意规模集群。同时 ClickHouse 在多正本性能上有更细粒度的控制能力，能够做到表级别正本数配置，同一物理集群可划分多个逻辑集群，每个逻辑机器可任意配置分片数和正本数。
存储架构
写入链路设计
写入吞吐能力是大数据场景下的一项外围指标，用户对大数据产品的要求不光是要存的下，还要写得快。这里首先介绍 Elasticsearch 的实时写入链路设计：在 Elasticsearch 的每一个 Shard 中，写入流程分为两局部，先写入 Lucene，再写入 TransLog。写入申请达到 Shard 后，先写 Lucene 内存索引，此时数据还在内存外面，接着去写 TransLog，写完 TransLog 后，刷新 TransLog 数据到磁盘上，写磁盘胜利后，申请返回给用户。这里有几个关键点，一是把写 Lucene 放在了最后面，次要是避免用户的写入申请蕴含“非法”的数据。二是写 Lucene 索引后，并不是可被搜寻的，须要通过 refresh 把内存的对象转成残缺的 Segment 后，而后再次 reopen 后能力被搜寻，这个 refresh 工夫距离是用户可设定的。能够看出 Lucene 索引并没有写入实时可见的能力，所以 Elasticsearch 是一个近实时（Near Real Time）的零碎。最初是每隔一段比拟长的工夫，比方 30 分钟后，Lucene 会把内存中生成的新 Segment 刷新到磁盘上，刷新后索引文件曾经长久化了，历史的 TransLog 就没用了，才会清空掉旧的 TransLog。
Elasticsearch 单 Shard 写入链路
ClickHouse 单 Shard 写入链路
比照 Elasticsearch 的写入链路，ClickHouse 的写入形式更加“简略间接”、极致，下面曾经讲过 Elasticsearch 是一个近实时零碎，内存存储引擎中新写入的数据须要定时 flush 才可见。而 ClickHouse 则是罗唆彻底放弃了内存存储引擎这一性能，所有的数据写入时间接落盘，同时也就省略了传统的写 redo 日志阶段。在极高写入吞吐要求的场景下，Elasticsearch 和 ClickHouse 都须要为了晋升吞吐而放弃局部写入实时可见性。只不过 ClickHouse 主推的做法是把数据提早攒批写入交给客户端来实现。另外在多正本同步上，Elasticsearch 要求的是实时同步，也就是写入申请必须写穿多个正本才会返回，而 ClickHouse 是依赖于 ZooKeeper 做异步的磁盘文件同步（data shipping）。在实战中 ClickHouse 的写入吞吐能力能够远远超过同规格的 Elasticsearch。
Segment vs DataPart
Elasticsearch 和 ClickHouse 的存储设计表面上看起来十分类似，但能力却又截然不同。Elasticsearch 的磁盘文件由一个个 Segment 组成，Segment 实际上是一份最小单位的 Lucene 索引，对于 Segment 外部的存储格局这里不展开讨论。而 Segment 又会在后盾异步合并，这里合并次要解决两个问题：1）让二级索引更加有序；2）实现主键数据变更。二级索引是一种“全局”有序的索引，全副数据构建到一个索引外面比构建到多个索引里对查问的减速更显著。Elasticsearch 是反对主键删除更新的，这都是依靠于 Lucene 索引的删除性能来实现的，更新操作会被转换成删除操作加写入操作。当 Lucene 索引的 Segment 里存在多条删除记录时，零碎就须要通过 Segment 合并来剔除这些记录。在多个 Segment 进行合并的时候，Lucene 索引中的存储数据体现出的是 append-only 的合并，这种形式下二级索引的合并就不须要进行“重排序”。
比照 Elasticsearch 中的 Segment，ClickHouse 存储中的最小单位是 DataPart，一次批量写入的数据会落盘成一个 DataPart。DataPart 外部的数据存储是齐全有序的状态（依照表定义的 order by 排序），这种有序存储就是一种默认聚簇索引能够用来减速数据扫描。ClickHouse 也会对 DataPart 进行异步合并，其合并也是用来解决两个问题：1）让数据存储更加有序；2）实现主键数据变更。DataPart 在合并存储数据时体现出的是 merge-sorted 的形式，合并后产生的 DataPart 依然处于齐全有序状态。依赖于 DataPart 存储齐全有序的设定，ClickHouse 实现主键数据更新的形式和 Elasticsearch 截然不同。
Elasticsearch 在变更主键时，采纳的是“先查原纪录 - 生成新记录 - 删除原纪录 - 写入新纪录”的形式，这种形式齐全限制住了主键更新的效率，主键更新写入和 append-only 写入的效率差别十分大。而 ClickHouse 的主键更新是齐全异步进行的，主键雷同的多条记录在异步合并的时候会产生最新的记录后果。这种异步批量的主键更新形式比 Elasticsearch 更加高效。
最初总结一下 Segment 和 DataPart 外部文件存储的能力差异，Segment 齐全就是 Lucene 索引的存储格局，Lucene 索引在倒排文件上的存储毋庸置疑是做到极致的，Lucene 索引同时也提供了行存、列存等不同格局的原数据存储。
Elasticsearch 默认都会把原数据存两份，一份在行存里，一份在列存里。Elasticsearch 会依据查问的 pattern，抉择扫描的适合的存储文件。原生 ClickHouse 的 DataPart 中并没有任何二级索引文件，数据齐全按列存储，ClickHouse 实现的列存在压缩率、扫描吞吐上都做到了极致。相对而言 Elasticsearch 中的存储比拟中庸，并且老本至多翻倍。
再谈 Schemaless
讲到 Elasticsearch 的个性，大家都会提到 Schemaless 这个词，Elasticsearch 能够主动推断写入数据的 json-shema，依据写入数据的 json-schema 调整存储表的 Meta 构造，这能够帮忙用户节俭很多建表、加列的麻烦。然而在作者看来，Elasticsearch 的这种能力其实叫 auto schema inference 更为失当，这都得益于 Elasticsearch 的分布式 Meta 同步能力。而 Elasticsearch 的存储其实是须要 schema 的，甚至是强绑定 schema 的，因为它是以二级索引为外围的存储，没有类型的字段又如何能构建索引呢？真正的 Schemaless 应该是能够灵便高效变更字段类型，同时保障查问性能不会大幅降落的能力。明天用户想变更 Elasticsearch index 中的某个字段类型，那只有一种办法：就是把整份数据数据 reindex。绝对比，ClickHouse 的存储反而不是强绑定 schema 的，因为 ClickHouse 的剖析能力是以存储扫描为外围的，它是能够在数据扫描进行动静类型转换，也能够在 DataPart 合并的时候缓缓异步调整字段的类型，在查问的时候字段类型变更引起的代价也就是运行时减少 cast 算子的开销，用户不会感触到急剧的性能降落。作者认为 Schemeless 相对不是 Elasticsearch 的护城河能力，绝对反而是它的弱项。至于 auto schema inference，这是对小规模用户十分敌对的能力，但它永远不可能能帮用户创立出性能最佳的 Schema，在大数据量场景下大家还是须要依据具体的查问需要来创立 Schema，所有的便当最初都是有老本代价的。
查问架构
计算引擎
作者在这里把 ClickHouse 和 Elasticsearch 摆在一起讲计算引擎其实有些荒诞的滋味，因为 Elasticsearch 实现的只是一个通用化搜索引擎。而搜索引擎能解决的查问复杂度是确定的、有下限的，所有的搜寻查问通过确定的若干个阶段就能够得出后果，然而计算引擎则不然。Elasticsearch 尽管也有 SQL 反对的插件，然而这种插件的实现逻辑就是把简略的 SQL 查问翻译到确定的搜寻模式下面。对于搜索引擎原来就不反对的数据分析行为，Elasticsearch-SQL 也杯水车薪。另外 Elasticsearch-SQL 以后的翻译能力看起来并不是十分齐备和智能，为了取得最高的搜寻性能用户还是须要尝试 Elasticsearch 原生的查问 API。对于习惯应用 SQL 的用户而言，Elasticsearch 的查问 API 是齐全生疏的一套体系，简单查问十分难写。
Elasticsearch 的搜索引擎反对三种不同模式的搜寻形式：query_and_fetch，query_then_fetch，dfs_query_then_fetch。第一种模式很简略，每个分布式节点独立搜寻而后把失去的后果返回给客户端，第二种模式是每个分布式存储节点先搜寻到各自 TopN 的记录 Id 和对应的 score，汇聚到查问申请节点后做重排失去最终的 TopN 后果，最初再申请存储节点去拉取明细数据。这里设计成两轮申请的目标就是尽量减少拉取明细的数量，也就是磁盘扫描的次数。最初一种形式是为了平衡各个存储节点打分的规范，先统计全局的 TF（Term Frequency）和 DF（Document Frequency），再进行 query_then_fetch。Elasticsearch 的搜索引擎齐全不具备数据库计算引擎的流式解决能力，它是齐全回合制的 request-response 数据处理。当用户须要返回的数据量很大时，就很容易呈现查问失败，或者触发 GC。一般来说 Elasticsearch 的搜索引擎能力下限就是两阶段的查问，像多表关联这种查问是齐全超出其能力下限的。
ClickHouse 的计算引擎特点则是极致的向量化，齐全用 c ++ 模板手写的向量化函数和 aggregator 算子使得它在聚合查问上的解决性能达到了极致。配合上存储极致的并行扫描能力，轻松就能够把机器资源跑满。ClickHouse 的计算引擎能力在剖析查问反对上能够齐全覆盖住 Elasticsearch 的搜索引擎，有齐备 SQL 能力的计算引擎能够让用户在解决数据分析时更加灵便、自在。
数据扫描
ClickHouse 是齐全列式的存储计算引擎，而且是以有序存储为外围，在查问扫描数据的过程中，首先会依据存储的有序性、列存块统计信息、分区键等信息推断出须要扫描的列存块，而后进行并行的数据扫描，像表达式计算、聚合算子都是在正规的计算引擎中解决。从计算引擎到数据扫描，数据流转都是以列存块为单位，高度向量化的。而 Elasticsearch 的数据扫描如上一节所述，次要产生在 query 和 fetch 阶段。其中 query 阶段次要是扫描 Lucene 的索引文件获取查问命中的 DocId，也包含扫描列存文件进行聚合计算。而 fetch 阶段次要是点查 Lucene 索引中的行存文件读取明细后果。表达式计算和聚合计算在两个阶段都有可能产生，其计算逻辑都是以行为单位进行运算。总的来说 Elasticsearch 的数据扫描和计算都没有向量化的能力，而且是以二级索引后果为根底，当二级索引返回的命中行数特地大时（波及大量数据的剖析查问），其搜索引擎就会暴露出数据处理能力有余的短板。
再谈高并发
很多用户谈到 ClickHouse，都会有一个谬误的映像，ClickHouse 查问跑得快，然而并发不行。但这背地的起因其实是 ClickHouse 的并行太牛逼了，这是 ClickHouse 的一大强项，一个查问就能够把磁盘吞吐都打满，查问并行齐全不依赖于 shard，能够任意调整。不可否认解决并发申请的吞吐能力是掂量一个数据系统效率的最终指标，ClickHouse 的架构上并没有什么人造的并发缺点，只不过它是个正直 boy，查问须要扫描的数据量和计算复杂度摆在那，ClickHouse 只是每次都老老实实计算而已，机器的硬件能力就决定了它的并发下限。ClickHouse 的并发能力事实上是不错的，认为它并发不行是个误区。只是默认状况下 ClickHouse 的指标是保障单个 query 的 latency 足够低；局部场景下用户能够通过设置适合的零碎参数来晋升并发能力，比方 max_threads 等。反过来，在这里介绍一下为什么有些场景下 Elasticsearch 的并发能力会很好。首先从 Cache 设计层面来看，Elasticsearch 的 Cache 包含 Query Cache, Request Cache，Data Cache，Index Cache，从查问后果到索引扫描后果层层的 Cache 减速，就是因为 Elasticsearch 认为它的场景下存在热点数据，可能被重复查问。反观 ClickHouse，只有一个面向 IO 的 UnCompressedBlockCache 和零碎的 PageCache，为什么呢？因为 ClickHouse 立足于剖析查问场景，剖析场景下的数据和查问都是多变的，查问后果等 Cache 都不容易命中，所以 ClickHouse 的做法是始终围绕磁盘数据，具备良好的 IO Cache 能力。其次回到数据扫描粒度，Elasticsearch 具备全列的二级索引能力，这些索引个别都是预热好提前加载到内存中的，即便在多变的查问条件下索引查问失去后果的代价也很低，拿到索引后果就能够按行读取数据进行计算。而原生 ClickHouse 并没有二级索引的能力，在多变的查问条件下只能大批量地去扫描数据过滤出后果（阿里云 ClickHouse 曾经具备二级索引能力，解决了这一问题，性能程度和 Elasticsearch 相当，后续性能测评局部会进行具体介绍）。然而 Elasticsearch 具备二级索引，并发能力就肯定会好么？也不尽然，当二级索引搜寻失去的后果集很大时，查问还是会随同大量的 IO 扫描，高并发就无从谈起，除非 Elasticsearch 的 Data Cache 足够大，把所有原数据都加载到内存里来。
总结来说，Elasticsearch 只有在齐全搜寻场景上面（where 过滤后的记录数较少），并且内存足够的运行环境下，能力展现出并发上的劣势。而在剖析场景下（where 过滤后的记录数较多），ClickHouse 凭借极致的列存和向量化计算会有更加杰出的并发体现。两者的偏重不同而已，同时 ClickHouse 并发解决能力立足于磁盘吞吐，而 Elasticsearch 的并发解决能力立足于内存 Cache。ClickHouse 更加适宜低成本、大数据量的剖析场景，它可能充分利用磁盘的带宽能力。
性能测试
在本章中，作者选取了用户业务中多个具备代表性的数据场景，以此对 Elasticsearch 和 ClickHouse 做了一个全方面多角度的性能测试报告。具体的 测试集群环境如下：
日志剖析场景
作者在日志剖析场景中选取了两个具备代表性的查问场景进行比照测试，后果如下所示。从后果剖析来看 ClickHouse 和 Elasicsearch 在两个场景中的性能差距随着 where 条件过滤后的记录数增大而扩充，在数据量更大的 trace_log 场景中，两者的剖析查问性能差距高深莫测。Elasticsearch 和 ClickHouse 完整版建表语句和查问下载：日志剖析场景
access_log（数据量 197921836）
ClickHouse 中的建表语句如下：
ClickHouse 中的查问语句如下：
--Q1
select _date, accept_time, access_ip, type, total_time, concat(toString(total_time),'ms') as total_time_ms, sql,schema,succeed,process_id,inst_name from access_log where _date >= '2020-12-27 00:38:31' and _date <= '2020-12-28 00:38:31' and logic_ins_id = 502680264 and accept_time <= 1609087111000 and accept_time >= 1609000711000 and positionCaseInsensitive(sql, 'select') > 0 order by accept_time desc limit 50,50;
--Q2
select
case
when total_time <=100 then 1
when total_time > 100 and total_time <= 500 then 2
when total_time > 500 and total_time <= 1000 then 3
when total_time > 1000 and total_time <= 3000 then 4
when total_time > 3000 and total_time <= 10000 then 5
when total_time > 10000 and total_time <= 30000 then 6
else 7
end as reorder,
case
when total_time <=100 then '0~100ms'
when total_time > 100 and total_time <= 500 then '100ms~500ms'
when total_time > 500 and total_time <= 1000 then '500ms~1s'
when total_time > 1000 and total_time <= 3000 then '1s~3s'
when total_time > 3000 and total_time <= 10000 then '3s~10s'
when total_time > 10000 and total_time <= 30000 then '10s~30s'
else '30s 以上'
end as label,
case
when total_time <= 100 then '0~100'
when total_time > 100 and total_time <= 500 then '100~500'
when total_time > 500 and total_time <= 1000 then '500~1000'
when total_time > 1000 and total_time <= 3000 then '1000~3000'
when total_time > 3000 and total_time <= 10000 then '3000~10000'
when total_time > 10000 and total_time <= 30000 then '10000~30000'
else '30000~10000000000'
end as vlabel,
count() as value
from access_log
where logic_ins_id = 502867976 and _date >= '2020-12-27 00:38:31' and _date <= '2020-12-28 00:38:31' and accept_time <= 1609087111000 and accept_time >= 1609000711000
group by label,vlabel,reorder
order by reorder;
--Q3
select toStartOfMinute(_date) as time, count() as value
from access_log
where logic_ins_id = 500152868 and accept_time <= 1609087111000 and accept_time >= 1609000711000
group by time
order by time;
--Q4
select count(*) as c from (select _date, accept_time, access_ip, type, total_time, concat(toString(total_time),'ms') as total_time_ms, sql, schema, succeed, process_id, inst_name
from access_log
where logic_ins_id = 501422856 and _date >= '2020-12-27 00:38:31' and _date <= '2020-12-28 00:38:31' and accept_time <= 1609087111000 and accept_time >= 1609000711000
);性能比照如下：
trace_log（数据量 569816761）
ClickHouse 中的建表语句如下：
CREATE TABLE trace_local on cluster default
(`serviceName` LowCardinality(String),
`host` LowCardinality(String),
`ip` String,
`spanName` String,
`spanId` String,
`pid` LowCardinality(String),
`parentSpanId` String,
`ppid` String,
`duration` Int64,
`rpcType` Int32,
`startTime` Int64,
`traceId` String,
`tags.k` Array(String),
`tags.v` Array(String),
`events` String,
KEY trace_idx traceId TYPE range
) ENGINE = MergeTree()
PARTITION BY intDiv(startTime, toInt64(7200000000))
PRIMARY KEY (serviceName, host, ip, pid, spanName)
ORDER BY (serviceName, host, ip, pid, spanName, tags.k);
CREATE TABLE trace on cluster default as trace_local
engine = Distributed(default, default, trace_local, rand());ClickHouse 中的查问语句如下：
--Q1
select *
from trace
prewhere
traceId ='ccc6084420b76183'
where startTime > 1597968000300000 and startTime < 1598054399099000 settings max_threads = 1;
--Q2
select count(*) count, spanName as name from trace
where serviceName ='conan-dean-user-period'
and startTime > 1597968000300000 and startTime < 1598054399099000
group by spanName
order by count desc limit 1000;
--Q3
select host as name, count(*) count
from trace
where serviceName ='conan-dean-user-period'
and startTime > 1597968000300000 and startTime < 1598054399099000
group by host;
--Q4
select count(*) count, tags.k as name from trace
array join tags.k
where serviceName ='conan-dean-user-period'
and startTime > 1597968000300000 and startTime < 1598054399099000
group by tags.k;
--Q5
select count(*) spancount,
sum(duration) as sumDuration, intDiv(startTime, 1440000000) as timeSel
from trace
where serviceName ='conan-dean-user-period'
and startTime > 1597968000300000 and startTime < 1598054399099000
group by timeSel;
--Q6
select count(*) spanCount,
countIf(duration <=1000000), countIf(duration > 1000000), countIf(duration > 3000000)
from trace
where serviceName ='conan-dean-user-period'
and startTime > 1597968000300000 and startTime < 1598054399099000;
--Q7
select host, startTime,traceId,spanName,duration,tags.k,tags.v
from trace
where serviceName ='conan-dean-user-period'
and startTime > 1597968000300000 and startTime < 1598054399099000 limit 1000000;性能比照如下：
官网 Ontime 测试集
Ontime 测试集是 ClickHouse 官网上举荐的一个剖析型查问 benchmark，为了更加公证公开地比照 ClickHouse 和 Elasticsearch 在剖析查问上的性能差别。作者也引入了这个数据集进行测试比对，后果如下所示，ClickHouse 在纯剖析型查问场景下具备微小性能劣势。Elasticsearch 和 ClickHouse 完整版建表语句和查问下载：聚合剖析场景
用户画像场景（数据量 262933269）
用户画像场景也是用户比拟难抉择应用 Elasticsearch 还是 ClickHouse 的一个典型场景，该场景的具体特点是超大宽表，大批量更新写入，查问返回的数据量大，筛选条件复杂多变。用户在应用 Elasticsearch 时遇到的难点问题次要有两个：数据写不进去，导入慢；数据拉不进去，返回大规模明细数据十分慢。针对这个场景，作者依据实在用户的业务场景，mock 了一张靠近 150 列的大宽表进行相干的查问测试，具体的查问如下所示，每条查问返回的后果集在 10 万到 100 万行级别。Elasticsearch 和 ClickHouse 完整版建表语句和查问下载：用户画像场景
ClickHouse 中的查问语句如下：
--Q1
select user_id
from person_tag
where mock3d_like > 8 and mock3d_consume_content_cnt > 8 and mock_10_day_product_avg_amt < 1 settings append_squashing_after_filter = 1;
--Q2
select user_id
from person_tag
where mock_7_day_receive_cnt > 8 and like_fitness = 1 and mock14d_share_cnt > 8 settings append_squashing_after_filter = 1;
--Q3
select user_id
from person_tag
where home_perfer_mock_score > 8 and mock7d_access_homepage_cnt > 8 settings append_squashing_after_filter = 1;
--Q4
select user_id
from person_tag
where is_send_register_coupon > 8 and mock1d_like > 8 settings append_squashing_after_filter = 1;
--Q5
select user_id
from person_tag
where like_sports = 1 and like_3c = 1 and sex = 1 and like_dance = 1 and mock1d_share_cnt > 6 settings append_squashing_after_filter = 1;
--Q6
select user_id
from person_tag
where mock14d_access_homepage_cnt > 8 and like_anime = 1 settings append_squashing_after_filter = 1;
--Q7
select user_id,offline_ver,is_visitor,mock1d_comment_like,reg_days,mock14d_share_cnt,mock_30_order_avg_delivery_time_cnt,mock7d_comment_cnt,performance_rate,mock3d_valid_user_follow_cnt,mock30d_consume_content_cnt,like_cnt,like_photo,ls90_day_access_days,mock3d_release_trend_cnt,mock14d_access_homepage_range,qutdoor_perfer_mock_score,mock3d_access_homepage_cnt,mock_15_order_avg_delivery_time_cnt,mock7d_release_trend_cnt,like_food,mock30d_follow_topic_cnt,mock7d_is_access_topic,like_music,mock3d_interactive_cnt,mock14d_valid_user_follow_cnt,reg_platform,mock_7_day_lottery_participate_cnt,pre_churn_users,etl_time,like_anime,mock14d_access_homepage_cnt,mock14d_consume_content_cnt,like_travel,like_watches,mock14d_comment_like,ls30_day_access_days,mock14d_release_trend_cnt,ftooeawr_perfer_mock_score,mock7d_valid_user_follow_cnt,beauty_perfer_mock_score
from person_tag
where mock3d_like > 8 and mock3d_consume_content_cnt > 8 and mock_10_day_product_avg_amt < 1 settings append_squashing_after_filter = 1;查问性能后果比照如下，能够看出 Elasticsearch 在扫描导出大量后果数据的场景下，性能十分大，返回的后果集越大越慢，其中 Q5 是查问命中后果集很小的比照 case。
二级索引点查场景（数据量 1000000000）
在剖析查问业务场景中，用户难免会有几个明细点查 case，例如依据日志 traceId 查问明细信息。开源 ClickHouse 因为没有二级索引能力，在遇到这种状况时，查问性能比照 Elasticsearch 齐全落后。阿里云 ClickHouse 自研了二级索引能力，补齐了这方面的短板，作者在这里专门加了一个二级索引点查的场景来进行性能比照测试。Elasticsearch 和 ClickHouse 完整版建表语句和查问下载：二级索引点查场景
ClickHouse 中的建表语句如下：
CREATE TABLE point_search_test_local on cluster default (
`PRI_KEY` String,
`SED_KEY` String,
`INT_0` UInt32,
`INT_1` UInt32,
`INT_2` UInt32,
`INT_3` UInt32,
`INT_4` UInt32,
`LONG_0` UInt64,
`LONG_1` UInt64,
`LONG_2` UInt64,
`LONG_3` UInt64,
`LONG_4` UInt64,
`STR_0` String,
`STR_1` String,
`STR_2` String,
`STR_3` String,
`STR_4` String,
`FIXSTR_0` FixedString(16),
`FIXSTR_1` FixedString(16),
`FIXSTR_2` FixedString(16),
`FIXSTR_3` FixedString(16),
`FIXSTR_4` FixedString(16),
KEY SED_KEY_IDX SED_KEY Type range
) ENGINE = MergeTree ORDER BY PRI_KEY
SETTINGS index_granularity_bytes = 4096, secondary_key_segment_min_rows = 1000000000, min_rows_for_wide_part = 2000000000;
CREATE TABLE point_search_test on cluster default as point_search_test_local
engine = Distributed(default, default, point_search_test_local, rand());ClickHouse 中的查问模板语句如下：
select * from point_search_test where SED_KEY = ‘XXX’ settings max_threads = 1;
最终的查问性能比照如下，阿里云 ClickHouse 具备二级索引能力后，其点查能力齐全不弱于 Elasticsearch，存储原生反对的二级索引能力，具备极致性能。（阿里云 ClickHouse 二级索引文档）
数据导入性能比照
后面列举的所有数据集数据，作者都应用了 ESSD 本地文件导入的形式测试比照了 Elasticsearch 和 ClickHouse 的导入性能。ClickHouse 能够间接应用 ClickHouse-Client 读取各种格局的本地文件进行导入，而 Elasticsearch 则是通过配置 Logstash 工作。具体耗时后果如下：
结语
Elasticsearch 最善于的次要是齐全搜寻场景（where 过滤后的记录数较少），在内存富裕运行环境下能够展现出十分杰出的并发查问能力。然而在大规模数据的剖析场景下（where 过滤后的记录数较多），ClickHouse 凭借极致的列存和向量化计算会有更加杰出的并发体现，并且查问反对齐备度也更好。ClickHouse 的并发解决能力立足于磁盘吞吐，而 Elasticsearch 的并发解决能力立足于内存 Cache，这使得两者的老本区间有很大差别，ClickHouse 更加适宜低成本、大数据量的剖析场景，它可能充分利用磁盘的带宽能力。数据导入和存储老本上，ClickHouse 更加具备相对的劣势。
原文链接
本文为阿里云原创内容，未经容许不得转载。