ClickHouse为何能超越Elasticsearch?

这篇具有很好参考价值的文章主要介绍了ClickHouse为何能超越Elasticsearch?。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

背景

Elasticsearch是一个强大的分布式全文检索和数据分析引擎,也是日志分析系统经常使用的一种实现方案,但近年来随着ClickHouse的发展,Elasticsearch在日志分析领域的地位逐渐被取代,许多公司已经将自己的日志分析解决方案从ES迁移到了ClickHouse,比如阿里、bilibili、快手等公司,公司内部有一些团队的数据分析业务也从ES迁移到了ClickHouse。为什么ClickHouse会受到越来越多人的青睐?它与ES相比有什么过人之处?

ClickHouse是俄罗斯搜索巨头Yandex公司于2016年开源的一个列式数据库管理系统,是面向列式存储的关系型数据库,这两年来Clickhouse凭借其极致的性能,成为OLAP领域的后起之秀,发展速度非常快。下面将从数据存储成本、数据写入吞吐量、数据查询速度三个方面详细分析ClickHouse的优势。

数据存储成本

传统的关系型数据库都是面向行存储,而ClickHouse是面向列存储。列式存储有什么优势呢?

行式存储



ClickHouse为何能超越Elasticsearch?





ClickHouse为何能超越Elasticsearch?



行式存储在物理上是逐行存储的,每行的数据在物理上是连续的。

列式存储



ClickHouse为何能超越Elasticsearch?





ClickHouse为何能超越Elasticsearch?



列式存储在物理上是逐列存储的,每列的数据在物理上是连续的,ClickHouse每列的数据存储在一个单独的文件中。

列式存储为什么能够降低数据的存储成本呢?因为列式存储更有利于数据的压缩。ClickHouse 采用列式存储,同一列的数据在物理上是连续的,且数据在存储时是经过排序的,这样数据的局部规律性非常强,有利于获得更高的数据压缩比。此外,ClickHouse 除了支持 LZ4、ZSTD 等通用压缩算法外,还支持 Delta、DoubleDelta、Gorilla 等专用编码算法,能够进一步提高数据压缩比。

而ES存储数据时,默认对数据按行存储一份,按列存储一份,并且数据的压缩比没有ClickHouse高。对于相同的数据,ClickHouse占用的磁盘空间只有ES的1/3到1/30,因此ClickHouse更节省磁盘空间,数据存储成本更低。

数据写入吞吐量

ES的数据写入过程



ClickHouse为何能超越Elasticsearch?



ES在进行数据存储时首先会将数据存到内存中,过一段时间后才会存到磁盘。具体写入过程如下:

写入一个新文档时,首先会对其进行索引,写入到Lucene内存中,此时新写入的文档还不能被检索到。当达到默认的刷新时间或Lucene内存中的数据达到一定量后,会触发一次refresh,Lucene内存中的数据会以一个新的段(segment)的形式刷新到文件缓存系统(也是内存)中,此时新写入的文档数据便能被检索到了。文件缓存系统中的数据需要再等到一定时间或达到一定量才会生成一个新的段,强制flush到磁盘,ES会在后台对这些段进行合并。为防止内存数据丢失,ES对于每一次的写入会追加一条记录到事务日志(TransLog),追加的事务日志也会先保存在内存中,经过一定时间或数据达到一定量才会flush到磁盘。

ClickHouse的数据写入过程



ClickHouse为何能超越Elasticsearch?





ClickHouse的数据写入更加直接,不会先存到内存再刷新到磁盘,而是直接存到磁盘上,因此也省略了传统的redo日志阶段。ClickHouse建议客户端以相当大的批量写入数据(建议不少于1000行,最好是在10000-100000行),支持海量数据的批量插入,每次插入都会创建一个新的DataPart,每个DataPart中数据按主键排序。ClickHouse支持使用分区键来对数据进行分区,数据插入时属于不同分区的数据会生成不同的DataPart,ClickHouse后台会高效合并这些分区的DataPart,不同分区的DataPart不会合并。每个DataPart都会有一个主索引,DataPart合并时每个DataPart的主索引也会合并。

可以看到,ClickHouse批量写入时,不会去修改已有数据,而是直接创建一个新的DataPart,快速写入,后台再对DataPart进行合并,不需要记录redo日志,而且ClickHouse的写入批量非常大,因此ClickHouse能够支持很大的写入吞吐量,单服务器日志写入量在50MB~200MB/s,每秒写入超过60w记录数,是ES的5倍以上。另外,对于副本同步,ES要求实时同步,写入请求必须同步完所有的副本之后才会返回响应,而ClickHouse使用ZooKeeper的异步磁盘文件同步,不需要同步完所有副本才返回响应。

数据查询速度

ClickHouse在存储层面和计算层面的精心设计使得它的数据查询速度也很快。

存储层面

列式存储及数据压缩

ClickHouse的数据存储是面向列的,列式存储方式对于统计、聚类分析场景具有天然的优势。数据分析行为通常会在列维度上进行,在行存模式下,数据按行连续存储,数据分析时会从存储系统读取所有满足条件的行数据,然后在内存中过滤出需要的字段,这样不参与计算的列也要在IO时全部读出,读取操作被严重放大,导致查询速度慢。



ClickHouse为何能超越Elasticsearch?



在列存模式下,只需要读取参与计算的列即可,避免多余的数据读取,极大降低了IO消耗,加速查询。



ClickHouse为何能超越Elasticsearch?



另外,如上文提到的,列式存储使得数据具有更高的压缩比,这就意味着数据量更小,从磁盘读取响应的数据时耗时会更短,也能够加速查询。

数据有序存储

ClickHouse支持在建表时指定排序键,数据存储时会按照排序键进行有序存储,这样的话具有相同排序键的数据在磁盘上会连续存储。在进行等值、范围查询时,查询条件命中的数据都紧密存储在一个或若干个连续的Block中,而不是分散地存储在任意多个Block,这会大幅减少需要IO的Block数量,从而加速查询。另外,连续IO也能够充分利用操作系统page cache的预取能力,减少缺页错误。

数据分区

ClickHouse支持数据分区,在建表时可以指定按照任意列的表达式对数据进行分区操作,比如按月、按天或按事件类型等,不同分区的数据是分开存储的,查询时如果条件包含分区键,ClickHouse会自动排除一些分区。结合业务特点,选择合适的分区表达式,能有效提升查询效率。

主键索引

ClickHouse支持主键索引,它将每列数据按照索引粒度(index_granularity,默认为8192行)进行划分,得到一个一个的索引颗粒(granule),主键索引中存储每个索引颗粒第一行的主键值。



ClickHouse为何能超越Elasticsearch?



如果在查询时,查询条件含有主键,ClickHouse会利用主键索引进行二分查找,能够直接定位到对应的索引颗粒,避免全表扫描,从而加速查询。

二级索引

使用“非主键”字段查询时,由于不能使用主索引,查询速度会慢很多。ClickHouse支持对任意列创建任意数量的二级索引,即跳数索引,使ClickHouse在查询时跳过那些肯定不匹配的数据块,在特定情况下可以显著提高查询速度。目前支持的跳数索引类型包括:



ClickHouse为何能超越Elasticsearch?



计算层面

多核并行

ClickHouse支持将数据划分为多个分区,每个分区再进一步划分为多个索引颗粒,ClickHouse利用CPU的多个核分别处理各个数据部分,实现数据并行处理。在这种设计下,单条查询就能利用整机所有CPU,极致的并行处理能力,极大地降低了查询延时。

分布式计算

除了优秀的单机并行处理能力,ClickHouse还提供了可线性拓展的分布式计算能力。在ClickHouse中,数据可以保存在不同的分片,每一个分片都由一组用于容错的副本组成,查询可以并行地在所有分片上进行处理(对用户透明),从而提升查询效率。

向量化执行

什么是向量化执行?简单理解就是,为了制作m杯果汁,非向量化执行的方式是用1台榨汁机重复循环执行m次,而向量化执行的方式是用m台榨汁机只执行1次。列式存储为数据的向量化执行提供了条件,ClickHouse 实现了一套向量引擎,大量的处理操作都是向量化执行的。ClickHouse利用CPU的SIMD指令,使CPU能够按向量(列的一部分)来处理数据,这种方式能够更加高效利用CPU,加速执行效率,从而提升查询效率。

近似计算

ClickHouse支持通过近似计算来加速查询。近似计算以损失一定结果精度为代价,极大地提升查询性能,在海量数据处理中,近似计算价值更加明显。ClickHouse实现了多种近似计算功能:

•用于近似计算的各类聚合函数,如:distinct values, 中位数, 分位数。

•基于数据的部分样本进行近似查询。

•不使用全部的聚合条件,通过随机选择有限个数据聚合条件进行聚合。

总之,ClickHouse通过减少磁盘IO、增强数据并行计算等方式优化查询,使得ClickHouse具备很快的查询速度,官方宣称,数据在page cache的情况下,单服务器查询速率大约在2-30GB/s,没在pagecache的情况下,查询速度取决于磁盘的读取速率和数据的压缩率。

总结

ClickHouse还有一些其他的优点,比如异步的多主复制技术,能保证系统在不同副本上保持相同的数据,大多情况下能故障后自动恢复;采用SQL语法,比ES的DSL更加简单,学习成本更低……

另外,ClickHouse也有一些缺点:

•没有完整的事务支持。

•无法像ES一样提供全文检索功能。

•无法动态添加字段,需要提前定义好表schema。

•无法支持高并发查询,默认配置QPS为100。

•不适合高频地写入,否则会导致后台合并无法跟上新分区数量。

总的来说,在数据分析场景下,ClickHouse相比ES具有更多的优势,而ES主要优势体现在全文检索上,适合完全搜索场景。当然,没有一个系统能够完全适合所有场景,两者的侧重点不同而已,在OLAP领域,ClickHouse在数据存储成本、写入吞吐量、查询速度等方面都有一定的优势,更适合低成本、大数据量的分析场景。文章来源地址https://www.toymoban.com/news/detail-451923.html

到了这里,关于ClickHouse为何能超越Elasticsearch?的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Elasticsearch 和 ClickHouse 的对比分析

    Elasticsearch 和 ClickHouse 都是当前互联网领域中比较热门的两种数据存储工具。都有自己的优势和适用场景深入了解它们的特点和使用条件才能更好地运用于实际项目中,对 Elasticsearch 和 ClickHouse 进行对比分析,包括数据存储和索引、查询和分析、扩展性和可靠性、安全性和管理

    2024年02月02日
    浏览(31)
  • ClickHouse与Elasticsearch实时搜索案例

    随着数据的增长和实时性的要求,实时搜索技术变得越来越重要。ClickHouse和Elasticsearch都是流行的实时搜索技术,它们各自具有不同的优势和适用场景。本文将详细介绍ClickHouse与Elasticsearch的实时搜索案例,并分析它们的优缺点。 2.1 ClickHouse ClickHouse是一个高性能的列式数据库

    2024年02月19日
    浏览(38)
  • 「从ES到CK 01」Elasticsearch vs Clickhouse

            在完成将公司日志数据从Elasticsearch(下称ES)转战到Clickhouse后,个人认为有必要将过程记录分享。限于篇幅及便于分类组织,我会以一个系列文章的形式记录: 01 《Elasticsearch vs Clickhouse》 02 《Clickhouse的基础知识扫盲》 03 《​Clickhouse多分片多副本集群部署​》 04

    2024年02月04日
    浏览(41)
  • ClickHouse/Doris vs Elasticsearch谁更胜一筹?

    我之前在ClickHouse vs Doris 读写性能比较 一文中,初步做了一下ClickHouse和Doris的读写性能比较,但由于数据样本比较小,且未发挥出所有硬件资源的性能,因此进行了第二轮压测。 本轮压测与上一轮的区别在于: 新加入了Elasticsearch搜索引擎 ClickHouse和Doris均采用多并发写入,发

    2024年01月22日
    浏览(50)
  • 大数据测试-hive、doris、clickhouse、mysql、elasticsearch、kudu、postgresql、sqlserver

    大数据工作要接触很多的数据库和查询引擎 数据库 : 1、 hive :用于跑批,大批量,稳定,缺点:无update。用于数仓 2、 doris db :已更名starrocks。即时查询 可达千亿级别 文档:什么是 StarRocks @ StarRocks_intro @ StarRocks Docs 3、 clickhouse :亿级别 局限性:主表,单表支持能力强,

    2024年02月05日
    浏览(47)
  • 数据库不应放在容器中?- B站Kubernetes有状态服务实践(Elasticsearch/Clickhouse)

    云原生时代下, Kubernetes已成为容器技术的事实标准, 使得基础设施领域应用下自动化运维管理与编排成为可能。对于无状态服务而言, 业界早已落地数套成熟且较完美的解决方案。可对于有状态的服务, 方案的复杂度就以几何倍数增长, 例如分布式应用多个实例间的依

    2024年03月18日
    浏览(55)
  • 华为云云服务器评测|基于华为云云耀云服务器L实例开展性能评测,例如 MySQL、Clickhouse、Elasticsearch等等

    在当今云计算时代,越来越多的企业和个人开始选择将应用部署在云服务器上,以便更好地满足高性能、可靠性和可扩展性等需求。而华为云云耀云服务器L实例不仅提供了高性能和可靠性的计算和存储资源,而且具有灵活和高效的成本控制,深受广大用户的青睐。在这个背景

    2024年02月11日
    浏览(68)
  • 华为云云耀云服务器L实例评测|基于华为云云耀云服务器L实例开展性能评测,例如 MySQL、Clickhouse、Elasticsearch等等

    在当今云计算时代,越来越多的企业和个人开始选择将应用部署在云服务器上,以便更好地满足高性能、可靠性和可扩展性等需求。而华为云云耀云服务器L实例不仅提供了高性能和可靠性的计算和存储资源,而且具有灵活和高效的成本控制,深受广大用户的青睐。在这个背景

    2024年02月05日
    浏览(68)
  • 超越边界:Mistral 7B挑战AI新标准,全面超越Llama 2 13B

    引言 在人工智能领域,模型的性能一直是衡量其价值和应用潜力的关键指标。近日,一个新的里程碑被设立:Mistral AI发布了其最新模型Mistral 7B,它在众多基准测试中全面超越了Llama 2 13B模型,标志着AI技术的一个重大进步。 Mistral 7B vs Llama 2 13B Mistral 7B的发布,不仅是一次技

    2024年02月04日
    浏览(43)
  • 超越想象的GPT医疗 20230723

    7月份读完了这本书,趁着周末写下读书笔记吧 这本书 作者:【美】彼得.李 Peter Lee 【美】凯丽.戈德伯格CareyGoldberg 著 【美】伊萨克.科恩Isaac Kohane 芦义 译 在AI风起云涌时代,在这刚刚过去的新冠三年,“超越想象的GPT医疗”这本书的出版,给正在担忧医疗承载能力的人们,

    2024年02月15日
    浏览(39)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包