乌海网站开发,公司网页建立,关于协会网站建设的几点思考,汽车便宜网站建设Elasticsearch从入门到精通-01认识Elasticsearch #x1f44f;作者简介#xff1a;大家好#xff0c;我是程序员行走的鱼 #x1f342;博主从本篇正式开始ES学习#xff0c;希望小伙伴可以一起探讨 #x1f4d6; 本篇主要介绍和大家一块简单认识下ES并了解ES中的主要角色…Elasticsearch从入门到精通-01认识Elasticsearch 作者简介大家好我是程序员行走的鱼 博主从本篇正式开始ES学习希望小伙伴可以一起探讨 本篇主要介绍和大家一块简单认识下ES并了解ES中的主要角色 ElasticSearch概述
1.1 认识Elasticsearch The Elastic Stack, 包括 Elasticsearch、Kibana、Beats 和 Logstash也称为 ELK Stack。能够安全可靠地获取任何来源、任何格式的数据然后实时地对数据进行搜索、分析和可视化。Elaticsearch简称为 ESES 是一个**开源的高扩展的分布式全文搜索引擎是整个 Elastic Stack 技术栈的核心。它可以近乎实时的存储、检索数据本身扩展性很好可以扩展到上百台服务器处理 PB 级别的数据。
1.2 什么是全文搜索引擎
Google百度类的网站搜索它们都是根据网页中的关键字生成索引我们在搜索的时候输入关键字它们会将该关键字即索引匹配到的所有网页返回还有常见的项目中应用日志的搜索等等。对于这些非结构化的数据文本关系型数据库搜索不是能很好的支持。一般传统数据库全文检索都实现的很鸡肋因为一般也没人用数据库存文本字段。进行全文检索需要扫描整个表如果数据量大的话即使对 SQL 的语法优化也收效甚微。即使建立了索引但是维护起来也很麻烦对于 insert 和 update 操作都会重新构建索引。基于以上原因可以分析得出在一些生产环境中使用常规的搜索方式性能是非常差的
搜索的数据对象是大量的非结构化的文本数据。文本记录量达到数十万或数百万个甚至更多。需要支持大量基于交互式文本的查询。需要非常灵活的全文搜索查询。对高度相关的搜索结果的有特殊需求但是没有可用的关系数据库可以满足。对不同记录类型、非文本数据操作或安全事务处理的需求相对较少的情况。为了解决结构化数据搜索和非结构化数据搜索性能问题我们就需要专业健壮强大的全文搜索引擎
这里说到的全文搜索引擎指的是目前广泛应用的主流搜索引擎。它的工作原理是计算机索引程序通过扫描文章中的每一个词对每一个词建立一个索引指明该词在文章中出现的次数和位置当用户查询时检索程序就根据事先建立的索引进行查找并将查找的结果反馈给用户的检索方式。这个过程类似于通过字典中的检索字表查字的过程。
1.3 Elasticsearch And Solr
Lucene 是 Apache 软件基金会 Jakarta 项目组的一个子项目提供了一个简单却强大的应用程式接口能够做全文索引和搜寻。在 Java 开发环境里 Lucene 是一个成熟的免费开源工具。就其本身而言Lucene 是当前以及最近几年最受欢迎的免费 Java 信息检索程序库。但 Lucene 只是一个提供全文搜索功能类库的核心工具包而真正使用它还需要一个完善的服务框架搭建起来进行应用。
目前市面上流行的搜索引擎软件主流的就两款Elasticsearch 和 Solr,这两款都是基于 Lucene 搭建的可以独立部署启动的搜索引擎服务软件。由于内核相同所以两者除了服务器安装、部署、管理、集群以外对于数据的操作修改、添加、保存、查询等等都十分类似。
在使用过程中一般都会将 Elasticsearch 和 Solr 这两个软件对比然后进行选型。这两个搜索引擎都是流行的先进的的开源搜索引擎。它们都是围绕核心底层搜索库 - Lucene构建的 - 但它们又是不同的。像所有东西一样每个都有其优点和缺点 当单纯的对已有数据进行搜索时Solr更快。当实时建立索引时, Solr会产生io阻塞查询性能较差, Elasticsearch具有明显的优势。大型互联网公司实际生产环境测试将搜索引擎从Solr转到 Elasticsearch以后的平均查询速度有了50倍的提升。 1.4 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 支持更多格式的数据比如JSON、XML、CSV而 Elasticsearch 仅支持json文件格式。 Solr 在传统的搜索应用中表现好于 Elasticsearch但在处理实时搜索应用时效率明显低于 Elasticsearch。
那么到底是Solr还是Elasticsearch
有时很难找到明确的答案。无论您选择 Solr 还是 Elasticsearch首先需要了解正确的用例和未来需求。总结他们的每个属性。
由于易于使用Elasticsearch 在新开发者中更受欢迎。一个下载和一个命令就可以启动一切。如果除了搜索文本之外还需要它来处理分析查询Elasticsearch 是更好的选择如果需要分布式索引则需要选择 Elasticsearch。对于需要良好可伸缩性和以及性能分布式环境Elasticsearch 是更好的选择。Elasticsearch 在开源日志管理用例中占据主导地位许多组织在 Elasticsearch 中索引它们的日志以使其可搜索。如果你喜欢监控和指标那么请使用 Elasticsearch因为相对于 SolrElasticsearch 暴露了更多的关键指标
1.5 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 问题的网站全英文编程人员交流的网站。
ElasticSearch基本概念
2.1索引(Index)
一个索引就是一个拥有几分相似特征的文档的集合。比如说你可以有一个客户数据的索引另一个产品目录的索引还有一个订单数据的索引。一个索引由一个名字来标识必须全部是小写字母并且当我们要对这个索引中的文档进行索引、搜索、更新和删除的时候都要使用到这个名字。在一个集群中可以定义任意多的索引。
能搜索的数据必须索引这样的好处是可以提高查询速度比如新华字典前面的目录就是索引的意思目录可以提高查询速度。 Elasticsearch 索引的精髓一切设计都是为了提高搜索的性能。 2.2 类型(Type)
在一个索引中你可以定义一种或多种类型。
一个类型是你的索引的一个逻辑上的分类/分区其语义完全由你来定。通常会为具有一组共同字段的文档定义一个类型。不同的版本类型发生了不同的变化 2.3 文档(Document)
一个文档是一个可被索引的基础信息单元也就是一条数据.
比如你可以拥有某一个客户的文档某一个产品的一个文档当然也可以拥有某个订单的一个文档。文档以JSON格式来表示而 JSON 是一个到处存在的互联网数据交互格式。
在一个 index/type 里面你可以存储任意多的文档。
2.4 字段(Field)
相当于是数据表的字段对文档数据根据不同属性进行的分类标识。
2.5 映射(Mapping)
mapping 是处理数据的方式和规则方面做一些限制如某个字段的数据类型、默认值、分析器、是否被索引等等。这些都是映射里面可以设置的其它就是处理 ES 里面数据的一些使用规则设置也叫做映射按着最优规则处理数据对性能提高很大因此才需要建立映射并且需要思考如何建立映射才能对性能更好。
2.6 分片(Shards)
一个索引可以存储超出单个节点硬件限制的大量数据。比如一个具有 10 亿文档数据的索引占据 1TB 的磁盘空间而任一节点都可能没有这样大的磁盘空间。或者单个节点处理搜索请求响应太慢。为了解决这个问题Elasticsearch 提供了将索引划分成多份的能力每一份就称之为分片。当你创建一个索引的时候你可以指定你想要的分片的数量。每个分片本身也是一个功能完善并且独立的“索引”这个“索引”可以被放置到集群中的任何节点上。
分片很重要主要有两方面的原因
(1)允许你水平分割 / 扩展你的内容容量。
(2)允许你在分片之上进行分布式的、并行的操作进而提高性能/吞吐量。
至于一个分片怎样分布它的文档怎样聚合和搜索请求是完全由 Elasticsearch 管理的对于作为用户的你来说这些都是透明的无需过分关心。 被混淆的概念是一个 Lucene 索引我们在 Elasticsearch称作分片 。 一个Elasticsearch 索引是分片的集合。 当 Elasticsearch 在索引中搜索的时候 他发送查询到每一个属于索引的分片(Lucene 索引)然后合并每个分片的结果到一个全局的结果集。 2.7副本(Replicas)
在一个网络 / 云的环境里失败随时都可能发生在某个分片/节点不知怎么的就处于离线状态或者由于任何原因消失了这种情况下有一个故障转移机制是非常有用并且是强烈推荐的。为此目的Elasticsearch允许你创建分片的一份或多份拷贝这些拷贝叫做复制分片(副本)。
复制分片之所以重要有两个主要原因
(1)在分片/节点失败的情况下提供了高可用性。因为这个原因注意到复制分片从不与原/主要original/primary分片置于同一节点上是非常重要的。
(2)扩展你的搜索量/吞吐量因为搜索可以在所有的副本上并行运行。
总之每个索引可以被分成多个分片。一个索引也可以被复制 0 次意思是没有复制或多次。一旦复制了每个索引就有了主分片作为复制源的原来的分片和复制分片主分片的拷贝之别。分片和复制的数量可以在索引创建的时候指定。在索引创建之后你可以在任何时候动态地改变复制的数量但是你事后不能改变分片的数量。默认情况下Elasticsearch中的每个索引被分片 1 个主分片和 1 个复制分配这意味着如果你的集群中至少有两个节点你的索引将会有 1 个主分片和另外 1 个复制分片1 个完全拷贝这样的话每个索引总共就有 2 个分片我们需要根据索引需要确定分片个数。
2.8分配
将分片分配给某个节点的过程包括分配主分片或者副本。如果是副本还包含从主分片复制数据的过程。这个过程是由 master 节点完成的。
主分片和另外 1 个复制分片1 个完全拷贝这样的话每个索引总共就有 2 个分片我们需要根据索引需要确定分片个数。
2.8分配
将分片分配给某个节点的过程包括分配主分片或者副本。如果是副本还包含从主分片复制数据的过程。这个过程是由 master 节点完成的。 至此本篇就结束了下一篇将介绍ES环境搭建以及客户端的安装包括Linux和Docker两种轻松搭建一个属于自己的ES服务
