原文先发于:https://mp.weixin.qq.com/s/0cTaqiYSJ1Pr9jBEVYfKHw
一、elasticsearch 背地乏味的故事
许多年前,一个刚结婚的名叫 Shay Banon 的就业开发者,跟着他的妻子去了伦敦,他的妻子在那里学习厨师。在寻找一个赚钱的工作的时候,为了给他的妻子做一个食谱搜索引擎,他开始应用 Lucene 的一个晚期版本。间接应用 Lucene 是很难的,因而 Shay 开始做一个形象层,Java 开发者应用它能够很简略的给他们的程序增加搜寻性能。他公布了他的第一个开源我的项目 Compass。起初 Shay 取得了一份工作,次要是高性能,分布式环境下的内存数据网格。这个对于高性能,实时,分布式搜索引擎的需要尤为突出,他决定重写 Compass,把它变为一个独立的服务并取名 Elasticsearch。
第一个公开版本在 2010 年 2 月公布,从此以后,Elasticsearch 曾经成为了 Github 上最沉闷的我的项目之一,他领有超过 300 名 contributors(目前 736 名 contributors)。一家公司曾经开始围绕 Elasticsearch 提供商业服务,并开发新的个性,然而,Elasticsearch 将永远开源并对所有人可用。
据说,Shay 的妻子还在等着她的食谱搜索引擎…
二、elasticsearch 简介
Elasticsearch 是一个开源的搜索引擎,建设在一个全文搜索引擎库 Apache Lucene™ 根底之上。Lucene 能够说是当下最先进、高性能、全功能的搜索引擎库 – 无论是开源还是公有。然而 Lucene 仅仅只是一个库。为了充分发挥其性能,你须要应用 Java 并将 Lucene 间接集成到应用程序中。更蹩脚的是,您可能须要取得信息检索学位能力理解其工作原理。Lucene 十分 简单。Elasticsearch 也是应用 Java 编写的,它的外部应用 Lucene 做索引与搜寻,然而它的目标是使全文检索变得简略,通过暗藏 Lucene 的复杂性,取而代之的提供一套简略统一的 RESTful API。然而,Elasticsearch 不仅仅是 Lucene,并且也不仅仅只是一个全文搜索引擎。它能够被上面这样精确的形容:
- 一个分布式的实时文档存储,每个字段 能够被索引与搜寻
- 一个分布式实时剖析搜索引擎
- 能胜任上百个服务节点的扩大,并反对 PB 级别的结构化或者非结构化数据
2.1、elasticsearch 性能
- 分布式的搜索引擎
es 可作为一个分布式的搜索引擎,例如百度,淘宝的商品搜寻,个别 web 零碎的站内搜索,es 都是不错的技术选型。
- 数据分析引擎
es 在搜寻的根底上提供了丰盛的 API 反对个性化的搜寻和数据分析性能,比方电商网站,咱们能够查问最近几天的热销商品等。
- 对海量数据进行近实时的解决
es 是一个分布式的搜索引擎,es 通过集群和外部分片能够将海量数据扩散到多台服务器上进行存储和检索,大大提高了其可伸缩性和容灾能力。
所谓近实时是一个绝对的概念,个别的如果相应速度能达到秒级别,咱们就称为其实近实时的。es 的近实时包含两个方面:其一写入的数据在 1s 后就能够进行检索。其二其检索和剖析响应速度能够达到秒级别。
2.2、elasticsearch 的特点
- 分布式
es 是一个分布式的搜索引擎,能够很好的进行数据的容灾迁徙,动静扩容,负载平衡等分布式个性。
- 海量数据
es 能解决 PB 级别的数据,因为 es 是一个分布式的架构,反对动静扩容,所以对于海量数据的解决和存储都不再是问题。
三、elasticsearch 的几个根底概念
es 中数据的根底概念
- index
索引 (index) 相似于关系型数据库里的“数据库”——它是咱们存储和索引关联数据的中央。
提醒:
事实上,咱们的数据被存储和索引在分片 (shards) 中,索引只是一个把一个或多个分片分组在一起的逻辑空间。然而,这只是一些外部细节——咱们的程序齐全不必关怀分 片。对于咱们的程序而言,文档存储在索引 (index) 中。
剩下的细节由 Elasticsearch 关怀 既可。
- type
type 的概念相似于 MySql 中表的概念。
在利用中,咱们应用对象示意一些“事物”,例如一个用户、一篇博客、一个评论,或者一封邮 件。每个对象都属于一个类 (class),这个类定义了属性或与对象关联的数据。user 类的对象 可能蕴含姓名、性别、年龄和 Email 地址。在关系型数据库中,咱们常常将雷同类的对象存储在一个表里,因为它们有着雷同的构造。同理,在 Elasticsearch 中,咱们应用雷同类型(type) 的文档示意雷同的“事物”,因为他们的数 据构造也是雷同的。每个类型 (type) 都有本人的映射 (mapping) 或者构造定义,就像传统数据库表中的列一样。所 有类型下的文档被存储在同一个索引下,然而类型的映射 (mapping) 会通知 Elasticsearch 不同 的文档如何被索引。咱们将会在《映射》章节探讨如何定义和治理映射,然而当初咱们将依 赖 Elasticsearch 去主动解决数据结构。
- document
document 是 es 的根本索引单元,document 相似于 MySql 中的一行记录。document 的数据是 json 格局。
- id
在 MySql 中咱们应用主键示意一条记录的唯一性,在 es 中 id 就是这种概念。在 es 中 id 同样能够是自产生的,es 主动生成的 ID 具备以下特点:主动生成的是 url 平安的,base64 编码,GUID,保障分布式下 ID 不抵触(全局惟一 ID)。当然也能够咱们本人来指定。
2,es 在分布式下的几个概念
- Cluster(集群):
置信相熟分布式的小伙伴对这个 Cluster 都不会生疏,Cluster 示意 es 的一个集群,所谓集群就是有好多 es 组合成的一个分布式下的 es 集群。
- node(节点):
node 就是 es 集群(Cluster)中的一个 es 节点就称为 node。简略来说能够了解成一个 es 实例就是该集群中的一个节点。
3,es 存储策略上的两个概念
- shard(分片)和 replica:
为了将数据增加到 Elasticsearch,咱们须要索引 (index)——一个存储关联数据的中央。理论 上,索引只是一个用来指向一个或多个分片(shards) 的“逻辑命名空间 (logical namespace)”. 一个分片(shard) 是一个最小级别“工作单元(worker unit)”, 它只是保留了索引中所有数据的一 局部。
道分片就是一个 Lucene 实例,并且它自身就是一个残缺的搜索引擎。咱们的文档存储在分片中,并且在分片中被索引,然而咱们的应用程序不会间接与它们通信,取而代之的是,间接与索引通信。分片是 Elasticsearch 在集群中散发数据的要害。把分片设想成数据的容器。文档存储在分片中,而后分片调配到你集群中的节点上。当你的集群扩容或放大,Elasticsearch 将会主动在你的节点间迁徙分片,以使集群保持平衡。分片能够是主分片 (primary shard) 或者是复制分片(replica shard)。
你索引中的每个文档属于一个独自的主分片,所以主分片的数量决定了索引最多能存储多少数据。实践上主分片能存储的数据大小是没有限度的,限度取决于你理论的应用状况。分片的最大容量齐全取决于你的应用情况:硬件存储的大小、文档的大小和复杂度、如何索引 和查问你的文档,以及你冀望的响应工夫。
复制分片只是主分片的一个正本,它能够避免硬件故障导致的数据失落,同时能够提供读请 求,比方搜寻或者从别的 shard 取回文档。当索引创立实现的时候,主分片的数量就固定了,然而复制分片的数量能够随时调整。默认状况下,一个索引被调配 5 个主分片,一个主分片默认只有一个复制分片。
重点:
shard 分为两种:
-
primary shard — 主分片
- replica shard — 复制分片(或者称为备份分片或者正本分片)
须要留神的是,在业界有一个约定俗称的货色,单说一个单词 shard 个别指的是 primary shard,而单说一个单词 replica 就是指的 replica shard。
另外一个须要留神的是 replica shard 是绝对于索引而言的,如果说以后 index 有一个复制分片,那么绝对于主分片来说就是每一个主分片都有一个复制分片,即如果有 5 个主分片就有 5 个复制分片,并且主分片和复制分片之间是一一对应的关系。
很重要的一点:primary shard 不能和 replica shard 在同一个节点上。重要的事件说三遍:
**primary shard 不能和 replica shard 在同一个节点上
primary shard 不能和 replica shard 在同一个节点上
primary shard 不能和 replica shard 在同一个节点上 **
所以 es 最小的高可用配置为两台服务器。
四、elasticsearch 的装置和开发工具
- 自己装置的是 elasticsearch-6.6.2 版本
- 开发工具:kibana-6.6.2(留神 kibana 的版本肯定要和 elasticsearch 的版本统一)
另外本地还配置了另一个开发工具:elasticsearch-head
装置形式,大家去百度一下,有很多很具体的装置步骤,在这里就不在赘述了。
简略贴一张图对于如何在 kibana 中执行 curl
四、集群衰弱状态
Elasticsearch 的集群监控信息中蕴含了许多的统计数据,其中最为重要的一项就是集群衰弱,它在 status 字段中展现为 green、yellow 或者 red。
在 kibana 中执行:GET /_cat/health?v
1 epoch timestamp cluster status node.total node.data shards pri relo init unassign pending_tasks max_task_wait_time active_shards_percent
2 1568794410 08:13:30 my-application yellow 1 1 47 47 0 0 40 0 - 54.0%
其中咱们能够看到以后我本地的集群衰弱状态是 yellow,但这里问题来了,集群的健康状况是如何进行判断的呢?
- green(很衰弱)
所有的主分片和正本分片都失常运行。 - yellow(亚健康)
所有的主分片都失常运行,但不是所有的正本分片都失常运行。 - red(不衰弱)
有主分片没能失常运行。
留神:
我本地只配置了一个单节点的 elasticsearch,因为 primary shard 和 replica shard 是不能调配到一个节点上的所以,在我本地的 elasticsearch 中是不存在 replica shard 的,所以健康状况为 yellow。
文章也会继续更新,能够微信搜寻「迈莫 coding」第一工夫浏览。每天分享优质文章、大厂教训、大厂面经,助力面试,是每个程序员值得关注的平台。
原文地址:https://www.cnblogs.com/hello…