ElasticSearch笔记01-ElasticSearch概述

ElasticSearch是一个基于Lucene的分布式、RESTful的搜索和数据分析引擎,常用于日志分析、实时搜索等场景。相比Solr,ElasticSearch更易用,适合分布式环境,提供更丰富的分析和可视化功能。两者都是构建在Lucene之上,但在社区支持、配置复杂度和特定功能上有所区别,选择取决于具体用例和需求。
摘要由CSDN通过智能技术生成

ElasticSearch是什么

Elastic Stack的核心:Elasticsearch是一个分布式、RESTful风格的搜索和数据分析引擎,能够解决不断涌现出的各种用例。作为Elastic Stack的核心,它集中存储您的数据,帮助您发现意料之中以及意料之外的情况。
The Elastic Stack,包括Elasticsearch、Kibana、Beats和Logstash(也称为ELK Stack)。能够安全可靠地获取任何来源、任何格式的数据,然后实时地对数据进行搜索、分析和可视化。
Elaticsearch,简称为ES,ES是一个开源的高扩展的分布式全文搜索引擎,是整个Elastic Stack技术栈的核心。它可以近乎实时的存储、检索数据;本身扩展性很好,可以扩展到上百台服务器,处理PB级别的数据。

全文搜索引擎

Google,百度类的网站搜索,它们都是根据网页中的关键字生成索引,我们在搜索的时候输入关键字,它们会将该关键字即索引匹配到的所有网页返回;还有常见的项目中应用日志的搜索等等。对于这些非结构化的数据文本,关系型数据库搜索不是能很好的支持。
一般传统数据库,全文检索都实现的很鸡肋,因为一般也没人用数据库存文本字段。进行全文检索需要扫描整个表,如果数据量大的话即使对SQL的语法优化,也收效甚微。建立了索引,但是维护起来也很麻烦,对于insert和update操作都会重新构建索引。
基于以上原因可以分析得出,在一些生产环境中,使用常规的搜索方式,性能是非常差的:

  • 搜索的数据对象是大量的非结构化的文本数据
  • 文件记录量达到数十万或数百万个甚至更多
  • 支持大量基于交互式文本的查询
  • 需求非常灵活的全文搜索查询
  • 对高度相关的搜索结果的有特殊需求,但是没有可用的关系数据库可以满足
  • 对不同记录类型、非文本数据操作或安全事务处理的需求相对较少的情况。

为了解决结构化数据搜索和非结构化数据搜索性能问题,我们就需要专业,健壮,强大的全文搜索引擎。这里说到的全文搜索引擎指的是目前广泛应用的主流搜索引擎。它的工作原理是计算机索引程序通过扫描文章中的每一个词,对每一个词建立一个索引,指明该词在文章中出现的次数和位置,当用户查询时,检索程序就根据事先建立的索引进行查找,并将查找的结果反馈给用户的检索方式。这个过程类似于通过字典中的检索字表查字的过程。

ElasticSearch And Solr

Lucene是Apache软件基金会Jakarta项目组的一个子项目,提供了一个简单却强大的应用程式接口,能够做全文索引和搜寻。在Java开发环境里Lucene是一个成熟的免费开源工具。就其本身而言,Lucene是当前以及最近几年最受欢迎的免费Java信息检索程序库。
但Lucene只是一个提供全文搜索功能类库的核心工具包,而真正使用它还需要一个完善的服务框架搭建起来进行应用。
目前市面上流行的搜索引擎软件,主流的就两款:Elasticsearch和Solr,这两款都是基于Lucene搭建的,可以独立部署启动的搜索引擎服务软件。由于内核相同,所以两者除了服务器安装、部署、管理、集群以外,对于数据的操作修改、添加、保存、查询等等都十分类似。
在使用过程中,一般都会将Elasticsearch和Solr这两个软件对比,然后进行选型。这两个搜索引擎都是流行的,先进的的开源搜索引擎。它们都是围绕核心底层搜索库Lucene构建的但它们又是不同的。像所有东西一样,每个都有其优点和缺点:

特征Solr/SolrCloudElasticSearch
社区和开发者Apache软件基金和社区支持单一商业实体及其员工
节点发现Apache ZooKeeper,在大量项目中成熟且经过实战测试Zen内置于ElasticSearch本身,需要专用的主节点才能进行分裂脑保护
碎片放置本质上是静态,需要手动工作来迁移分片,从Solr 7开始,Autoscaling API允许一些动态操作动态,可以根据集群状态按需移动分片
高速缓存全局,每个段更改无效每段,更适合动态更改数据
分析引擎性能非常适合精确计算的静态数据结果的准确性取决于数据放置
全文搜索功能基于Lucene的语言分析,多建议,拼写检查,丰富的高亮显示支持基于Lucene的语言分析,单一建议API实现,高亮显示重新计算
DevOps支持尚未完全,但即将到来非常好的API
非平面数据处理嵌套文档和父子支持嵌套和对象类型的自然支持允许几乎无限的嵌套和父子支持
查询DSLJSON(有限),XML(有限)或URL参数JSON
索引/收集领导控制领导者安置控制和领导者重新平衡甚至可以节点上的负载不可能
机器学习内置-在流聚合之上,专注于逻辑回归和学习排名贡献模块商业功能,专注于异常和异常值以及时间序列数据

ElasticSearch Or Solr

Elasticsearch和Solr都是开源搜索引擎,那么我们在使用时该如何选择呢?

  • Google搜索趋势结果表明,与Solr相比,Elasticsearch具有很大的吸引力,但这并不意味着Apache Solr已经死亡。虽然有些人可能不这么认为,但Solr仍然是最受欢迎的搜索引擎之一,拥有强大的社区和开源支持
  • 与Solr相比,Elasticsearch易于安装且非常轻巧。此外,你可以在几分钟内安装并运行Elasticsearch。但是,如果Elasticsearch管理不当,这种易于部署和使用可能会成为一个问题。基于 JSON 的配置很简单,但如果要为文件中的每个配置指定注释,那么它不适合您。总的来说,如果你的应用使用的是JSON,那么Elasticsearch是一个更好的选择。否则,请使用Solr,因为它的schema.xml和solrconfig.xml都有很好的文档记录
  • Solr拥有更大,更成熟的用户,开发者和贡献者社区。ES虽拥有的规模较小但活跃的用户社区以及不断增长的贡献者社区。Solr贡献者和提交者来自许多不同的组织,而Elasticsearch提交者来自单个公司
  • Solr更成熟,但ES增长迅速,更稳定
  • Solr是一个非常有据可查的产品,具有清晰的示例和API用例场景。Elasticsearch的文档组织良好,但它缺乏好的示例和清晰的配置说明。

那么,到底是 Solr 还是 Elasticsearch?
有时很难找到明确的答案。无论您选择Solr还是Elasticsearch,首先需要了解正确的用例和未来需求。总结他们的每个属性。

  • 由于易于使用,Elasticsearch在新开发者中更受欢迎。一个下载和一个命令就可以启动一切
  • 如果除了搜索文本之外还需要它来处理分析查询,Elasticsearch是更好的选择
  • 如果需要分布式索引,则需要选择Elasticsearch。对于需要良好可伸缩性和以及性能分布式环境,Elasticsearch是更好的选择
  • Elasticsearch在开源日志管理用例中占据主导地位,许多组织在Elasticsearch中索引它们的日志以使其可搜索
  • 如果你喜欢监控和指标,那么请使用Elasticsearch,因为相对于Solr,Elasticsearch 暴露了更多的关键指标

ElasticSearch应用案例

  • GitHub:2013年初,抛弃了Solr,采取Elasticsearch来做PB级的搜索。“GitHub 使用Elasticsearch 搜索20TB的数据,包括13亿文件和1300亿行代码”
  • 维基百科:启动以Elasticsearch为基础的核心搜索架构
  • SoundCloud:SoundCloud使用Elasticsearch为1.8亿用户提供即时而精准的音乐搜索服务
  • 百度:目前广泛使用Elasticsearch作为文本数据分析,采集百度所有服务器上的各类指标数据及用户自定义数据,通过对各种数据进行多维分析展示,辅助定位分析实例异常或业务层面异常。目前覆盖百度内部20多个业务线(包括云分析、网盟、预测、文库、直达号、钱包、风控等),单集群最大100台机器,200个ES节点,每天导入30TB+数据
  • 新浪:使用Elasticsearch分析处理32亿条实时日志
  • 阿里:使用Elasticsearch构建日志采集和分析体系
  • Stack Overflow:解决Bug问题的网站,全英文,编程人员交流的网站
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值