简介：本文的宗旨在于通过彻底分析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中的查问语句如下：
--Q1select _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;--Q2select 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 valuefrom access_logwhere 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;--Q3select 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;--Q4select 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_localengine = Distributed(default, default, trace_local, rand());ClickHouse中的查问语句如下：
--Q1select *from traceprewheretraceId ='ccc6084420b76183'where startTime > 1597968000300000 and startTime < 1598054399099000 settings max_threads = 1;--Q2select count(*) count, spanName as name from tracewhere serviceName ='conan-dean-user-period'and startTime > 1597968000300000 and startTime < 1598054399099000group by spanNameorder by count desc limit 1000;--Q3select host as name, count(*) countfrom tracewhere serviceName ='conan-dean-user-period'and startTime > 1597968000300000 and startTime < 1598054399099000group by host;--Q4select count(*) count, tags.k as name from tracearray join tags.kwhere serviceName ='conan-dean-user-period'and startTime > 1597968000300000 and startTime < 1598054399099000group by tags.k;--Q5select count(*) spancount, sum(duration) as sumDuration, intDiv(startTime, 1440000000) as timeSelfrom tracewhere serviceName ='conan-dean-user-period'and startTime > 1597968000300000 and startTime < 1598054399099000group by timeSel;--Q6select count(*) spanCount, countIf(duration <=1000000), countIf(duration > 1000000), countIf(duration > 3000000)from tracewhere serviceName ='conan-dean-user-period'and startTime > 1597968000300000 and startTime < 1598054399099000;--Q7select host, startTime,traceId,spanName,duration,tags.k,tags.vfrom tracewhere 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中的查问语句如下：
--Q1select user_idfrom person_tagwhere mock3d_like > 8 and mock3d_consume_content_cnt > 8 and mock_10_day_product_avg_amt < 1 settings append_squashing_after_filter = 1;--Q2select user_idfrom person_tagwhere mock_7_day_receive_cnt > 8 and like_fitness = 1 and mock14d_share_cnt > 8 settings append_squashing_after_filter = 1;--Q3select user_idfrom person_tagwhere home_perfer_mock_score > 8 and mock7d_access_homepage_cnt > 8 settings append_squashing_after_filter = 1;--Q4select user_idfrom person_tagwhere is_send_register_coupon > 8 and mock1d_like > 8 settings append_squashing_after_filter = 1;--Q5select user_idfrom person_tagwhere 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;--Q6select user_idfrom person_tagwhere mock14d_access_homepage_cnt > 8 and like_anime = 1 settings append_squashing_after_filter = 1;--Q7select 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_scorefrom person_tagwhere 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_localengine = 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更加具备相对的劣势。
原文链接
本文为阿里云原创内容，未经容许不得转载。