玩足球的稀饭 · 《走近科学》有哪些侮辱观众智商的故事? - 知乎· 1 年前 · |
文武双全的跑步鞋 · DISS风波再起!艾福杰尼惨遭前队友炮轰:“ ...· 1 年前 · |
兴奋的开水瓶 · 杨小虎主持召开全县安全生产工作会议_进行_预 ...· 1 年前 · |
曾经爱过的冰棍 · 蝶之毒 华之锁 - 萌娘百科 万物皆可萌的百科全书· 1 年前 · |
直爽的青蛙 · 京通号今早首发 ...· 1 年前 · |
Elasticsearch当前热度排名很高
青出于蓝,而胜于蓝。
入行Elastic-Stack技术栈很久很久,为了免于知识匮乏眼光局限,有必要到外面的世界看看,丰富自己的世界观。本篇内容从Elastic的竞争产品角度分析探讨。
本文仅代表个人的观点,不代表社区技术阵营观点,无意口水之争,限于本人的经验知识有限,可能与读者观点认知不一致。
Elasticseach从做搜索引擎开始,到现在主攻大数据分析领域,逐步进化成了一个全能型的数据产品,在Elasticsearch诸多优秀的功能中,与很多数据产品有越来越多的交叉竞争,有的功能很有特色,有的功能只是附带,了解这些产品特点有助于更好的应用于业务需求。
图片:Elasticsearch竞争图谱示意图
Lucene是一个搜索的核心库,Elastic也是在Lucene基础之上构建,它们之间的竞争关系是由Lucene本身决定的。
在互联网2.0时代,考验各互联网公司最简单的技术要求,就是看他们的搜索做的怎么样,那时大家的做法几乎一样,都基于Lucene核心库构建一套搜索引擎,剩下的就看各公司的开发者们的水平。笔者有幸在2012年之前,基于Lucene做过垂直行业的搜索引擎,遇到很多问题有必要说一下:
图示:Lucene内部索引构建与查询过程
Elasticsearch与Lucene核心库竞争的优势在于:
Elastic近年的快速发展,市面上已经很少发现基于Lucene构建搜索引擎的项目,几乎清一色选择Elasticsearch作为基础数据库服务,由于其开源特性,广大云厂商也在此基础上定制开发,与自己的云平台深度集成,但也没有独自发展一个分支。
本次的竞争中,Elasticsearch完胜。
Solr是第一个基于Lucene核心库功能完备的搜索引擎产品,诞生远早于Elasticsearch,早期在全文搜索领域,Solr有非常大的优势,几乎完全压倒Elastic,在近几年大数据发展时代,Elastic由于其分布式特性,满足了很多大数据的处理需求,特别是后面ELK这个概念的流行,几乎完全忘记了Solr的存在,虽然也推出了Solr-Coud分布式产品,但已经基本无优势。
接触过几个数据类公司,全文搜索都基于Solr构建,且是单节点模式,偶然出现一些问题,找咨询顾问排查问题,人员难找,后面都迁移到Elasticsearch之上。
现在市面上几乎大大小小公司都在使用Elasticsearch,除了老旧系统有的基于Solr的,新系统项目应该全部是Elasticsearch。
个人认为有以下几个原因:
图示:Solr产品功能模块内部架构图
本次竞争中,Elasticsearch完胜。
关系型数据库与Elasticsarch相比主要优点是事务隔离机制无可替代,但其局限性很明显,如下:
若数据无需严格事务机制隔离,个人认为都可以采用Elasticsearch替代。若数据既要事务隔离,也要查询性能,可以采用DB与ES混合实现,详细见笔者的博客文章 《DB与ES混合应用之数据实时同步》
图示:RDBMS与ES各自优势示意图
OpenTSDB内部基于HBase实现,属于时间序列数据库,主要针对具有时间特性和需求的数据,进行过数据结构的优化和处理,从而适合存储具有时间特性的数据,如监控数据、温度变化数据等,小米公司开源监控体系open-falcon的就是基于OpenTSDB实现。
图示:OpenTSDB时间序列数据库内部实现
Elastic产品本身无意时间序列这个领域,随着ELK的流行,很多公司采用ELK来构建监控体系,虽然在数值类型上不像时间序列数据库做过特别处理,但由于其便利的使用,以及生态技术栈的优势,我们也接受了这样的事实。
Elasticsearch构建时间序列很简单,性能也相当不错:
除非对于时间序列数据有非常苛刻的监控需求,否则选择Elasticsearch会更加合适一些。
HBase是列式数据库的代表,其内部有几个致命设计大大限制了它的应用范围:
关于其各种技术原理就不多说了,说说它的一些使用情况。
公司所属物流速运行业,一个与车辆有关的项目,记录所有车辆行驶轨迹,车载设备会定时上报车子的轨迹信息,后端数据存储基于HBase,数据量在几十TB级以上,由于业务端需要依据车辆轨迹信息计算它的公里油耗以及相关成本,所以要按查询条件批量查询数据,查询条件有一些非rowkey的字段,如时间范围,车票号,城市编号等,这几乎无法实现,原来暴力的做过,性能问题堪忧。此项目的问题首先也在于rowkey难设计满足查询条件的需求,其次是二级索引问题,查询的条件很多。
如果用列式数据库仅限于Rowkey访问场景,其实采用Elastic也可以,只要设计好 _id,与HBase可以达到相同的效果。
如果用列式数据库查询还需要引入三方组件,那还不如直接在Elasticsearch上构建更直接。
除非对使用列式数据库有非常苛刻的要求,否则Elasticsearch更具备通用性,业务需求场景适用性更多。
图示:列式数据库内部数据结构示意图
MongoDB是文档型数据库的代表,数据模型基于Bson,而Elasticsearch的文档数据模型是Json,Bson本质是Json的一种扩展,可以相互直接转换,且它们的数据模式都是可以自由扩展的,基本无限制。MongoDB本身定位与关系型数据库竞争,支持严格的事务隔离机制,在这个层面实际上与Elasticsearch产品定位不一样,但实际工作中,几乎没有公司会将核心业务数据放在MongoDB上,关系型数据库依然是第一选择。若超出这个定位,则Elasticsearh相比MongoDB有如下优点:
公司刚好有个项目,原来数据层基于MongoDB设计构建的,查询问题不少 ,后面成功迁移到Elasticsearch平台上,服务器数据量从15台降低到3台,查询性能还大幅度提升十倍,详细可阅读笔者另一篇文章《 从MongoDB迁移到ES后,我们减少了80%的服务器 》
抛开数据事务隔离,Elasticsearch可以完全替代MongoDB。
ClickHouse是一款MPP查询分析型数据库,近几年活跃度很高,很多头部公司都引入其中。我们为什么要引入呢,原因可能跟其他头部公司不太一样,如下:
ClickHouse与Elasticsearch一样,都采用列式存储结构,都支持副本分片,不同的是ClickHouse底层有一些独特的实现,如下:
图示:ClickHouse在大数据平台中的位置
Durid是一个大数据MPP查询型数据产品,核心功能Rollup,所有的需要Rollup原始数据必须带有时间序列字段。Elasticsearch在6.3.X版本之后推出了此功能,此时两者产品形成竞争关系,谁高谁下,看应用场景需求。
Druid样本数据,必须带有time时间字段。
笔者之前负责过公司所有Elasticsearch技术栈相关数据项目,当时也有碰到一些实时聚合查询返回部分数据的需求,但我们的需求不太一样,索引数据属于离线型更新,每天都会全部删除并重新创建索引插入数据,此时使用Elastic的版本是6.8.X,仅支持离线型数据Rollup,所以此功能没用上,Elastic在7.2.X版本之后才推出实时Rollup功能。
图示:Druid产品技术架构体系示意图
关于Rollup这个大数据分析领域,若有大规模的Rollup的场景需求,个人更倾向于Druid。
总结 :
注 :
作者介绍 :
李猛(ynuosoft) ,Elastic-stack产品深度用户,ES认证工程师,2012年接触Elasticsearch,对Elastic-Stack开发、架构、运维等方面有深入体验,实践过多种Elasticsearch项目,最暴力的大数据分析应用,最复杂的业务系统应用;业余为企业提供Elastic-stack咨询培训以及调优实施。
本文由 dbaplus 社群授权转载。
扫码关注腾讯云开发者
领取腾讯云代金券
Copyright © 2013 - 2023 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号: 粤B2-20090059 深公网安备号 44030502008569
腾讯云计算(北京)有限责任公司 京ICP证150476号 | 京ICP备11018762号 | 京公网安备号11010802020287
扫码关注腾讯云开发者
领取腾讯云代金券
玩足球的稀饭 · 《走近科学》有哪些侮辱观众智商的故事? - 知乎 1 年前 |
兴奋的开水瓶 · 杨小虎主持召开全县安全生产工作会议_进行_预案_部署 1 年前 |
曾经爱过的冰棍 · 蝶之毒 华之锁 - 萌娘百科 万物皆可萌的百科全书 1 年前 |