您好!
欢迎来到京东云开发者社区
登录
首页
博文
课程
大赛
工具
用户中心
首页
博文
课程
大赛
工具
更多
用户中心
开发者社区
>
博文
>
Elasticsearch与Clickhouse数据存储对比
分享
打开微信扫码分享
点击前往QQ分享
点击前往微博分享
点击复制链接
Elasticsearch与Clickhouse数据存储对比
自猿其说Tech
2021-09-14
IP归属:未知
54000浏览
ClickHouse
Elasticsearch
### 1 背景 京喜达技术部在社区团购场景下采用JDQ+Flink+Elasticsearch架构来打造实时数据报表。随着业务的发展Elasticsearch开始暴露出一些弊端,不适合大批量的数据查询,高频次分页导出导致宕机、存储成本较高。 Elasticsearch的查询语句维护成本较高、在聚合计算场景下出现数据不精确等问题。Clickhouse是列是数据库,列式型数据库天然适合OLAP场景,类似SQL语法降低开发和学习成本,采用快速压缩算法节省存储成本,采用向量执行引擎技术大幅缩减计算耗时。所以做此对比,进行Elasticsearch切换至Clickhouse工作。 ### 2 OLAP OLAP意思是On-Line Analytical Processing 联机分析处理,Clickhouse就是典型的OLAP联机分析型数据库管理系统(DBMS)。OLAP主要针对数据进行复杂分析汇总操作,比如我们业务系统每天都对当天所有运输团单做汇总统计,计算出每个省区的妥投率,这个操作就属于OLAP类数据处理。与OLAP类似的还有一个OLTP类数据处理,意思是On-Line Transaction Processing 联机事务处理,在OLTP场景中用户并发操作量会很大,要求系统实时进行数据操作的响应,需要支持事务,Mysql、Oracle、SQLServer等都是OLTP型数据库。 #### 2.1 OLTP场景的特征 - 宽表,即每个表包含着大量的列 - 对于读取,从数据库中提取相当多的行,但只提取列的一小部分。 - 查询相对较少(通常每台服务器每秒查询数百次或更少) - 查询结果明显小于源数据。换句话说,数据经过过滤或聚合,因此结果适合于单个服务器的RAM中 - 绝大多数是读请求 - 数据以相当大的批次(> 1000行)更新,而不是单行更新;或者根本没有更新。 - 对于简单查询,允许延迟大约50毫秒 - 列中的数据相对较小:数字和短字符串(例如,每个URL 60个字节) - 处理单个查询时需要高吞吐量(每台服务器每秒可达数十亿行) - 事务不是必须的 - 对数据一致性要求低 ### 3 特性 #### 3.1 Elasticsearch - **搜索:**适用倒排索引,每个字段都可被索引且可用于搜索,海量数据下近实时实现秒级的响应,基于Lucene的开源搜索引擎,为全文检索、高亮、搜索推荐等提供了检索能力。百度搜索、淘宝商品搜索、日志搜索等 - **数据分析:**Elasticsearch提供了大量数据分析的API和丰富的聚合能力,支持在海量数据的基础上进行数据分析处理。统计订单量、爬虫爬取不同电商的某个商品数据,通过Elasticsearch进行数据分析(各个平台的历史价格、购买力等等) #### 3.2 Clickhouse - 列式存储 - 压缩算法:采用lz4和zstd算法数据压缩,高压缩比降低数据大小,降低磁盘IO,降低CPU使用率。 - 索引:按照主键对数据进行排序,clickhouse能在几十毫秒内完成在大量数据对特定数据或范围数据进行查找。 - 多核心并行处理:ClickHouse会使用服务器上一切可用的资源,来全力完成一次查询。 - 支持SQL:一种基于SQL的声明式查询语言,在许多情况下与ANSI SQL标准相同。支持group by,order by,from, join,in以及非相关子查询等。 - 向量引擎:为了高效的使用CPU,数据不仅仅按列存储,同时还按向量(列的一部分)进行处理,这样可以更加高效地使用CPU。 - 实时的数据更新:数据总是已增量的方式有序的存储在MergeTree中。数据可以持续不断高效的写入到表中,不会进行任何加锁等操作。写入流量在50M-200M/s - 适合在线查询:响应速度快延迟极低 - 丰富的聚合计算函数 ### 4 我们的业务场景 1. 大宽表,读大量行少量列进行指标聚合计算查询,结果集比较小。数据表都是通过Flink加工出来的宽表,列比较多。在对数据进行查询或者分析时,经常选择其中的少数几列作为维度列、对其他少数几列作为指标列,对全表或者一定范围内的数据做聚合计算。这个过程会扫描大量的行数据,但是只用了少数几列。 1. 大量的列表分页查询与导出 1. Flink中数据大批量追加写入,不做更新操作 1. 有时某个指标计算需要全表扫描做聚合计算 1. 很少进行全文搜索 **结论:数据报表、数据分析场景是典型的OLAP场景,在业务场景上列式存储数据库Clickhouse比Elasticsearch更有优势,Elasticsearch在全文搜索上更占优势,但是我们这种全文搜索场景较少。** ### 5 成本 - 学习成本:Clickhouse是SQL语法比Elasticsearch的DSL更简单,几乎所有后端研发都有Mysql开发经验,比较相通学习成本更低。 - 开发、测试、维护成本:Clickhouse是SQL语法,与Mysql开发模式相似,更好写单元测试。Elasticsearch是使用Java API拼接查询语句,复杂度较高,不易读不易维护。 - 运维成本:未知,互联网上在日志场景下Clickhouse比Elasticsearch成本更低。 - 服务器成本: - - Clickhouse的数据压缩比要高于Elasticsearch,相同业务数据占用的磁盘空间ES占用磁盘空间是Clickhouse的3-10倍,平均在6倍。 见图1 - - Clickhouse比ES占用更少的CPU和内存 ![](//img1.jcloudcs.com/developer.jdcloud.com/62a7f54d-ec78-4a18-9406-352f73874ccf20210914143142.png) **结论:同等数据量情况下,Elasticsearch使用的存储空间是Clickhouse的3-10倍,平均在6倍。综合学习、开发、测试、维护方面,Clickhouse比Elasticsearch更友好** ### 6 测试 #### 6.1服务器配置 以下均基于下图配置进行测试 ![](//img1.jcloudcs.com/developer.jdcloud.com/da2a92e2-b3ce-472a-9a23-d81dfb663a4a20210914143209.png) #### 6.2 写入压测 以下基于wms_order_sku表,通过Flink在业务平稳情况下双写Elasticsearch和Clickhouse1000W+数据进行测试得到的结果 - 占用CPU情况:Elasticsearch CPU一直占用很高,Clickhouse占用很少CPU。见 图2 ![](//img1.jcloudcs.com/developer.jdcloud.com/4c2074d9-9dac-4a3a-b519-4f32133efa6320210914143230.png) - 占用内存情况:Elasticsearch 内存升高频繁GC,Clickhouse占用内存较低,比较平稳。见 图3 ![](//img1.jcloudcs.com/developer.jdcloud.com/007a0c73-490b-4532-9e92-93c892a1d6fb20210914143245.png) - 写入吞吐量:CH单机写入速度大约为50~200MB/s,如果写入的数据每行为1kb,写入速度为5~20W/s,图 4(写入吞吐量)为互联网上Elasticsearch与Clickhouse写入数据的对比图,同等数据样本的情况下CH写入性能是Elasticsearch的5倍。由于我们目前Flink任务为双写,考虑到会互相影响,后续补充压测结果。 ![](//img1.jcloudcs.com/developer.jdcloud.com/35c8800d-f557-4355-8bef-d1f4488747d220210914143303.png) **结论:批量写入数据时Elasticsearch比Clickhouse更吃内存和CPU,Elasticsearch消耗的内存是Clickhouse的5.3倍,消耗的CPU是Clickhouse的27.5倍。吞吐量是Elasticsearch的5倍** #### 6.3 查询性能(单并发测试) 以下场景是我们数据报表以及数据分析中出现的高频场景,所以基于此进行查询性能测试 ![](//img1.jcloudcs.com/developer.jdcloud.com/c3748051-cbf7-4eca-b2af-70a9abe7447c20210914143327.png) **数据对比情况** - Clickhouse自身在集群配置差一倍的情况下查询性能差异不是很大,CH2(48C 182GB)比CH1(80C 320GB)平均慢14%。见图 5 ![](//img1.jcloudcs.com/developer.jdcloud.com/996be579-a7d3-4d84-9941-130f0153d98b20210914143348.png) - Elasticsearch在集群配置差一倍的情况下查询性能受影响较大,ES2(46C 320GB)比ES1(78C 576GB)平均慢40%。见图 6 ![](//img1.jcloudcs.com/developer.jdcloud.com/57d00830-7875-4f2f-8b63-9c0a38829d9220210914143410.png) - ES2(46C 320GB)与CH2(48C 182GB)相比,ES2与CH2 CPU核数相近,ES2内存是CH2 1.75倍的情况下,CH2的响应速度是ES2的响应速度的的12.7倍。见图 7 ![](//img1.jcloudcs.com/developer.jdcloud.com/a7e454db-cd89-4db0-b52a-91b945d1c5da20210914143432.png) **结论:查询数据时Elasticsearch比Clickhouse慢,在配置相近的情况下Clickhouse的响应速度是Elasticsearch的12.7倍,特别是基于时间的多字段进行聚合查询是Clickhouse比Elasticsearch快32倍。Clickhouse的查询响应素速度受集群配置大小的影响较小。** #### 6.4 查询压测(高并发测试,数据来源于互联网) 由于准备高并发测试比较复杂耗时多,后续会基于我们的业务数据以及业务场景进行查询压力测试。以下数据来源于互联网在用户画像场景(数据量262933269)下进行的测试,与我们的场景非常类似。 ![](//img1.jcloudcs.com/developer.jdcloud.com/421e30b4-8824-4ccb-b2ea-45beb2e3fbe420210914143458.png) ![](//img1.jcloudcs.com/developer.jdcloud.com/8fe4b40a-748d-4497-8a30-7b7cd024757220210914143507.png) 结论:Clickhouse对于高并发支持的不够,官方建议最大QPS为100。高并发情况下吞吐量不如Elasticsearch更友好 ### 7 总结 Clickhouse与Elasticsearch对比Clickhouse的优缺点。 **优点:** - 硬件资源成本更低,同等场景下,Clickhouse占用的资源更小。 - 人力成本更低,新人学习、开发单测以及测试方面都更加友好,更容易介入。 - OLAP场景下Clickhouse比Elasticsearch更适合,聚合计算比Elasticsearch更精缺、更快,更节省服务器计算资源。 - 写入性能更高,同等情况下是Elasticsearch的5倍,写入时消耗的服务器资源更小。 - Elasticsearch在大量导出情况下频繁GC,严重可能导致宕机,不如Clickhouse稳定。 - 查询性能平均是Elasticsearch的12.7倍,Clickhouse的查询性能受服务器配置影响较小 - 月服务器消费相同情况Clickhouse能够得到更好的性能。 **缺点:** - 在全文搜索上不如Elasticsearch支持的更好,在高并发查询上支持的不如Elasticsearch支持的更好 ------------ ###### 自猿其说Tech-JDL京东物流技术发展部 ###### 作者:京喜达技术部 马红岩
原创文章,需联系作者,授权转载
上一篇:innodb中MVCC实现原理浅析
下一篇:一起聊聊工作中的功能安全测试
相关文章
京东mPaaS平台之Android组件化系统私有化部署改造实践!
别困惑,不是你的错!90%的开发者把Clubhouse看成了Clickhouse!
JUST技术: 使用 ClickHouse实现时序数据管理
自猿其说Tech
文章数
426
阅读量
2149940
作者其他文章
01
深入JDK中的Optional
本文将从Optional所解决的问题开始,逐层解剖,由浅入深,文中会出现Optioanl方法之间的对比,实践,误用情况分析,优缺点等。与大家一起,对这项Java8中的新特性,进行理解和深入。
01
Taro小程序跨端开发入门实战
为了让小程序开发更简单,更高效,我们采用 Taro 作为首选框架,我们将使用 Taro 的实践经验整理了出来,主要内容围绕着什么是 Taro,为什么用 Taro,以及 Taro 如何使用(正确使用的姿势),还有 Taro 背后的一些设计思想来进行展开,让大家能够对 Taro 有个完整的认识。
01
Flutter For Web实践
Flutter For Web 已经发布一年多时间,它的发布意味着我们可以真正地使用一套代码、一套资源部署整个大前端系统(包括:iOS、Android、Web)。渠道研发组经过一段时间的探索,使用Flutter For Web技术开发了移动端可视化编程平台—Flutter乐高,在这里希望和大家分享下使用Flutter For Web实践过程和踩坑实践
01
配运基础数据缓存瘦身实践
在基础数据的常规能力当中,数据的存取是最基础也是最重要的能力,为了整体提高数据的读取能力,缓存技术在基础数据的场景中得到了广泛的使用,下面会重点展示一下配运组近期针对数据缓存做的瘦身实践。
自猿其说Tech
文章数
426
阅读量
2149940
作者其他文章
01
深入JDK中的Optional
01
Taro小程序跨端开发入门实战
01
Flutter For Web实践
01
配运基础数据缓存瘦身实践
添加企业微信
获取1V1专业服务
扫码关注
京东云开发者公众号