1. Elastic Stack简介
如果你没有听说过Elastic Stack,那你一定听说过ELK,实际上ELK是三款软件的简称,分别是Elasticsearch、Logstash、Kibana组成,在发展的过程中,又有新成员Beats的加入,所以就形成了Elastic Stack。所以说,ELK是旧的称呼,Elastic Stack是新的名字。
全系的Elastic Stack技术栈包括:
Elasticsearch
Elasticsearch 基于java,是个开源分布式搜索引擎,它的特点有:分布式,零配置,自动发现,索引自动分片,索引副本机制,restful风格接口,多数据源,自动搜索负载等。
Logstash
Logstash 基于java,是一个开源的用于收集,分析和存储日志的工具。
Kibana
Kibana 基于nodejs,也是一个开源和免费的工具,Kibana可以为 Logstash 和 ElasticSearch 提供的日志分析友好的Web 界面,可以汇总、分析和搜索重要数据日志。
Beats
Beats是elastic公司开源的一款采集系统监控数据的代理agent,是在被监控服务器上以客户端形式运行的数据收集器的统称,可以直接把数据发送给Elasticsearch或者通过Logstash发送给Elasticsearch,然后进行后续的数据分析活动。
Beats由如下组成:
- Packetbeat:是一个网络数据包分析器,用于监控、收集网络流量信息,Packetbeat嗅探服务器之间的流量,解析应用层协议,并关联到消息的处理,其支 持ICMP (v4 and v6)、DNS、HTTP、Mysql、PostgreSQL、Redis、MongoDB、Memcache等协议;
- Filebeat:用于监控、收集服务器日志文件,其已取代 logstash forwarder;
- Metricbeat:可定期获取外部系统的监控指标信息,其可以监控、收集 Apache、HAProxy、MongoDB、MySQL、Nginx、PostgreSQL、Redis、System、Zookeeper等服务;
- Winlogbeat:用于监控、收集Windows系统的日志信息;
2. Elasticsearch
2.1 简介
官网:https://www.elastic.co/cn/products/elasticsearch
2.2 安装
2.2.1 版本说明
Elasticsearch的发展是非常快速的,所以在ES5.0之前,ELK的各个版本都不统一,出现了版本号混乱的状态,所以从5.0开始,所有Elastic Stack中的项目全部统一版本号。目前最新版本是6.5.4,我们将基于这一版本进行学习。
2.2.2 下载
地址:https://www.elastic.co/cn/downloads/elasticsearch
或者,使用资料中提供的已下载好的安装包。
2.2.3 单机版安装
1 | #创建elsearch用户,Elasticsearch不支持root用户运行 |
1 | #启动出错,环境:Centos6 |
2.2.4 elasticsearch-head
由于ES官方并没有为ES提供界面管理工具,仅仅是提供了后台的服务。elasticsearch-head是一个为ES开发的一个页面客户端工具,其源码托管于GitHub,地址为:https://github.com/mobz/elasticsearch-head
head提供了4种安装方式:
- 源码安装,通过npm run start启动(不推荐)
- 通过docker安装(推荐)
- 通过chrome插件安装(推荐)
- 通过ES的plugin方式安装(不推荐)
通过docker安装
1 | #拉取镜像 |
通过浏览器进行访问:
注意:
1 | 由于前后端分离开发,所以会存在跨域问题,需要在服务端做CORS的配置,如下: |
chrome插件的方式安装
打开chrome的应用商店,即可安装https://chrome.google.com/webstore/detail/elasticsearch-head/ffmkiejjmecolpfloofpjologoblkegm
建议:推荐使用chrome插件的方式安装,如果网络环境不允许,就采用其它方式安装。
2.3 基本概念
索引
- 索引(index)是Elasticsearch对逻辑数据的逻辑存储,所以它可以分为更小的部分。
- 可以把索引看成关系型数据库的表,索引的结构是为快速有效的全文索引准备的,特别是它不存储原始值。
- Elasticsearch可以把索引存放在一台机器或者分散在多台服务器上,每个索引有一或多个分片(shard),每个分片可以有多个副本(replica)。
文档
- 存储在Elasticsearch中的主要实体叫文档(document)。用关系型数据库来类比的话,一个文档相当于数据库表中的一行记录。
- Elasticsearch和MongoDB中的文档类似,都可以有不同的结构,但Elasticsearch的文档中,相同字段必须有相同类型。
- 文档由多个字段组成,每个字段可能多次出现在一个文档里,这样的字段叫多值字段(multivalued)。
- 每个字段的类型,可以是文本、数值、日期等。字段类型也可以是复杂类型,一个字段包含其他子文档或者数组。
映射
- 所有文档写进索引之前都会先进行分析,如何将输入的文本分割为词条、哪些词条又会被过滤,这种行为叫做映射(mapping)。一般由用户自己定义规则。
文档类型
- 在Elasticsearch中,一个索引对象可以存储很多不同用途的对象。例如,一个博客应用程序可以保存文章和评论。
- 每个文档可以有不同的结构。
- 不同的文档类型不能为相同的属性设置不同的类型。例如,在同一索引中的所有文档类型中,一个叫title的字段必须具有相同的类型。
2.4 RESTful API
在Elasticsearch中,提供了功能丰富的RESTful API的操作,包括基本的CRUD、创建索引、删除索引等操作。
2.4.1 创建非结构化索引
在Lucene中,创建索引是需要定义字段名称以及字段的类型的,在Elasticsearch中提供了非结构化的索引,就是不需要创建索引结构,即可写入数据到索引中,实际上在Elasticsearch底层会进行结构化操作,此操作对用户是透明的。
创建空索引:
1 | PUT /haoke |
2.4.2 插入数据
URL规则:POST /{索引}/{类型}/{id}
1 | POST /haoke/user/1001 |
说明:非结构化的索引,不需要事先创建,直接插入数据默认创建索引。
不指定id插入数据:
1 | POST /haoke/user/ |
2.4.3 更新数据
在Elasticsearch中,文档数据是不为修改的,但是可以通过覆盖的方式进行更新。
1 | PUT /haoke/user/1001 |
更新结果如下:
可以看到数据已经被覆盖了。
问题来了,可以局部更新吗? – 可以的。
前面不是说,文档数据不能更新吗? 其实是这样的:
在内部,依然会查询到这个文档数据,然后进行覆盖操作,步骤如下:
- 从旧文档中检索JSON
- 修改它
- 删除旧文档
- 索引新文档
示例:
1 | #注意:这里多了_update标识 |
可以看到数据已经被局部更新了。
2.4.4 删除数据
在Elasticsearch中,删除文档数据,只需要发起DELETE请求即可。
1 | DELETE /haoke/user/1001 |
需要注意的是,result表示已经删除,version也更加了。
如果删除一条不存在的数据,会响应404:
说明:
删除一个文档也不会立即从磁盘上移除,它只是被标记成已删除。Elasticsearch将会在你之后添加更多索引的时候才会在后台进行删除内容的清理。
2.4.5 搜索数据
根据id搜索数据
1 | GET /haoke/user/BbPe_WcB9cFOnF3uebvr |
搜索全部数据
1 | GET /haoke/user/_search |
关键字搜素数据
1 | #查询年龄等于20的用户 |
结果:
2.4.6 DSL搜索
Elasticsearch提供丰富且灵活的查询语言叫做DSL查询(Query DSL),它允许你构建更加复杂、强大的查询。
DSL(Domain Specific Language特定领域语言)以JSON请求体的形式出现。
1 | POST /haoke/user/_search |
响应数据:
实现:查询年龄大于30岁的男性用户。
现有数据:
1 | POST /haoke/user/_search |
查询结果:
全文搜索
1 | POST /haoke/user/_search |
2.4.7 高亮显示
1 | POST /haoke/user/_search |
2.4.8 聚合
在Elasticsearch中,支持聚合操作,类似SQL中的group by操作。
1 | POST /haoke/user/_search |
结果:
从结果可以看出,年龄30的有2条数据,20的有一条,40的一条。
3. 核心详解
3.1 文档
在Elasticsearch中,文档以JSON格式进行存储,可以是复杂的结构,如:
1 | { |
其中,card是一个复杂对象,嵌套的Card对象。
元数据(metadata)
一个文档不只有数据。它还包含了元数据(metadata)——关于文档的信息。三个必须的元数据节点是:
节点 | 说明 |
---|---|
_index | 文档存储的地方 |
_type | 文档代表的对象的类 |
_id | 文档的唯一标识 |
_index
索引(index)类似于关系型数据库里的“数据库”——它是我们存储和索引关联数据的地方。
提示:
事实上,我们的数据被存储和索引在分片(shards)中,索引只是一个把一个或多个分片分组在一起的逻辑空间。然而,这只是一些内部细节——我们的程序完全不用关心分片。对于我们的程序而言,文档存储在索引(index)中。剩下的细节由Elasticsearch关心既可。
_type
在应用中,我们使用对象表示一些“事物”,例如一个用户、一篇博客、一个评论,或者一封邮件。每个对象都属于一个类(class),这个类定义了属性或与对象关联的数据。 user 类的对象可能包含姓名、性别、年龄和Email地址。
在关系型数据库中,我们经常将相同类的对象存储在一个表里,因为它们有着相同的结构。同理,在Elasticsearch中,我们使用相同类型(type)的文档表示相同的“事物”,因为他们的数据结构也是相同的。
每个类型(type)都有自己的映射(mapping)或者结构定义,就像传统数据库表中的列一样。所有类型下的文档被存储在同一个索引下,但是类型的映射(mapping)会告诉Elasticsearch不同的文档如何被索引。
_type 的名字可以是大写或小写,不能包含下划线或逗号。我们将使用 blog 做为类型名。
_id
id仅仅是一个字符串,它与 _index 和 _type 组合时,就可以在Elasticsearch中唯一标识一个文档。当创建一个文档,你可以自定义 _id ,也可以让Elasticsearch帮你自动生成(32位长度)。
3.2 查询响应
3.2.1 pretty
可以在查询url后面添加pretty参数,使得返回的json更易查看。
3.2.2 指定响应字段
在响应的数据中,如果我们不需要全部的字段,可以指定某些需要的字段进行返回。
1 | GET /haoke/user/1005?_source=id,name |
如不需要返回元数据,仅仅返回原始数据,可以这样:
1 | GET /haoke/user/1005/_source |
还可以这样:
1 | GET /haoke/user/1005/_source?_source=id,name |
3.3 判断文档是否存在
如果我们只需要判断文档是否存在,而不是查询文档内容,那么可以这样:
1 | HEAD /haoke/user/1005 |
1 | HEAD /haoke/user/1006 |
当然,这只表示你在查询的那一刻文档不存在,但并不表示几毫秒后依旧不存在。另一个进程在这期间可能创建新文档。
3.4 批量操作
有些情况下可以通过批量操作以减少网络请求。如:批量查询、批量插入数据。
3.4.1 批量查询
1 | POST /haoke/user/_mget |
结果:
如果,某一条数据不存在,不影响整体响应,需要通过found的值进行判断是否查询到数据。
1 | POST /haoke/user/_mget |
结果:
3.4.2 _bulk操作
在Elasticsearch中,支持批量的插入、修改、删除操作,都是通过_bulk的api完成的。
请求格式如下:(请求格式不同寻常)
1 | { action: { metadata }}\n |
批量插入数据:
1 | {"create":{"_index":"haoke","_type":"user","_id":2001}} |
注意最后一行的回车。
响应结果:
1 | { |
批量删除:
1 | {"delete":{"_index":"haoke","_type":"user","_id":2001}} |
由于delete没有请求体,所以,action的下一行直接就是下一个action。
响应结果:
1 | { |
其他操作就类似了。
一次请求多少性能最高?
- 整个批量请求需要被加载到接受我们请求节点的内存里,所以请求越大,给其它请求可用的内存就越小。有一个最佳的bulk请求大小。超过这个大小,性能不再提升而且可能降低。
- 最佳大小,当然并不是一个固定的数字。它完全取决于你的硬件、你文档的大小和复杂度以及索引和搜索的负载。
- 幸运的是,这个最佳点(sweetspot)还是容易找到的:试着批量索引标准的文档,随着大小的增长,当性能开始降低,说明你每个批次的大小太大了。开始的数量可以在1000~5000个文档之间,如果你的文档非常大,可以使用较小的批次。
- 通常着眼于你请求批次的物理大小是非常有用的。一千个1kB的文档和一千个1MB的文档大不相同。一个好的批次最好保持在5-15MB大小间。
3.5 分页
和SQL使用 LIMIT 关键字返回只有一页的结果一样,Elasticsearch接受 from 和 size 参数:
1 | size: 结果数,默认10 |
如果你想每页显示5个结果,页码从1到3,那请求如下:
1 | GET /_search?size=5 |
应该当心分页太深或者一次请求太多的结果。结果在返回前会被排序。但是记住一个搜索请求常常涉及多个分片。每个分片生成自己排好序的结果,它们接着需要集中起来排序以确保整体排序正确。
1 | GET /haoke/user/_search?size=1&from=2 |
在集群系统中深度分页
为了理解为什么深度分页是有问题的,让我们假设在一个有5个主分片的索引中搜索。当我们请求结果的第一页(结果1到10)时,每个分片产生自己最顶端10个结果然后返回它们给请求节点(requesting node),它再排序这所有的50个结果以选出顶端的10个结果。
现在假设我们请求第1000页——结果10001到10010。工作方式都相同,不同的是每个分片都必须产生顶端的10010个结果。然后请求节点排序这50050个结果并丢弃50040个!
你可以看到在分布式系统中,排序结果的花费随着分页的深入而成倍增长。这也是为什么网络搜索引擎中任何语句不能返回多于1000个结果的原因。
3.6 映射
前面我们创建的索引以及插入数据,都是由Elasticsearch进行自动判断类型,有些时候我们是需要进行明确字段类型的,否则,自动判断的类型和实际需求是不相符的。
自动判断的规则如下:
JSON type | Field type |
---|---|
Boolean: true or false | “boolean” |
Whole number: 123 | “long” |
Floating point: 123.45 | “double” |
String, valid date: “2014-09-15” | “date” |
String: “foo bar” | “string” |
Elasticsearch中支持的类型如下:
类型 | 表示的数据类型 |
---|---|
String | string , text , keyword |
Whole number | byte , short , integer , long |
Floating point | float , double |
Boolean | boolean |
Date | date |
- string类型在ElasticSearch 旧版本中使用较多,从ElasticSearch 5.x开始不再支持string,由text和keyword类型替代。
- text 类型,当一个字段是要被全文搜索的,比如Email内容、产品描述,应该使用text类型。设置text类型以后,字段内容会被分析,在生成倒排索引以前,字符串会被分析器分成一个一个词项。text类型的字段不用于排序,很少用于聚合。
- keyword类型适用于索引结构化的字段,比如email地址、主机名、状态码和标签。如果字段需要进行过滤(比如查找已发布博客中status属性为published的文章)、排序、聚合。keyword类型的字段只能通过精确值搜索到。
创建明确类型的索引:
1 | PUT /itcast |
查看映射:
1 | GET /itcast/_mapping |
插入数据:
1 | POST /itcast/_bulk |
测试搜索:
1 | POST /itcast/person/_search |
3.7 结构化查询
3.7.1 term查询
term 主要用于精确匹配哪些值,比如数字,日期,布尔值或 not_analyzed 的字符串(未经分析的文本数据类):
1 | { "term": { "age": 26 }} |
示例:
1 | POST /itcast/person/_search |
3.7.2 terms查询
terms 跟 term 有点类似,但 terms 允许指定多个匹配条件。 如果某个字段指定了多个值,那么文档需要一起去做匹配:
1 | { |
示例:
1 | POST /itcast/person/_search |
3.7.3 range查询
range 过滤允许我们按照指定范围查找一批数据:
1 | { |
范围操作符包含:
gt
大于gte
大于等于lt
小于lte
小于等于
示例:
1 | POST /itcast/person/_search |
3.7.4 exists 查询
exists 查询可以用于查找文档中是否包含指定字段或没有某个字段,类似于SQL语句中的 IS_NULL 条件
1 | { |
这两个查询只是针对已经查出一批数据来,但是想区分出某个字段是否存在的时候使用。
示例:
1 | POST /haoke/user/_search |
3.7.5 match查询
match 查询是一个标准查询,不管你需要全文本查询还是精确查询基本上都要用到它。
如果你使用 match 查询一个全文本字段,它会在真正查询之前用分析器先分析 match 一下查询字符:
1 | { |
如果用 match 下指定了一个确切值,在遇到数字,日期,布尔值或者 not_analyzed 的字符串时,它将为你搜索你给定的值:
1 | { "match": { "age": 26 }} |
3.7.6 bool查询
bool 查询可以用来合并多个条件查询结果的布尔逻辑,它包含一下操作符:
must 多个查询条件的完全匹配,相当于 and 。
must_not 多个查询条件的相反匹配,相当于 not 。
should 至少有一个查询条件匹配, 相当于 or 。
这些参数可以分别继承一个查询条件或者一个查询条件的数组:
1 | { |
3.8 过滤查询
前面讲过结构化查询,Elasticsearch也支持过滤查询,如term、range、match等。
示例:查询年龄为20岁的用户。
1 | POST /itcast/person/_search |
结果:
查询和过滤的对比
- 一条过滤语句会询问每个文档的字段值是否包含着特定值。
- 查询语句会询问每个文档的字段值与特定值的匹配程度如何。
- 一条查询语句会计算每个文档与查询语句的相关性,会给出一个相关性评分 _score,并且按照相关性对匹配到的文档进行排序。 这种评分方式非常适用于一个没有完全配置结果的全文本搜索。
- 一个简单的文档列表,快速匹配运算并存入内存是十分方便的, 每个文档仅需要1个字节。这些缓存的过滤结果集与后续请求的结合使用是非常高效的。
- 查询语句不仅要查找相匹配的文档,还需要计算每个文档的相关性,所以一般来说查询语句要比过滤语句更耗时,并且查询结果也不可缓存。
建议:
做精确匹配搜索时,最好用过滤语句,因为过滤语句可以缓存数据。
4. 中文分词
4.1 什么是分词
分词就是指将一个文本转化成一系列单词的过程,也叫文本分析,在Elasticsearch中称之为Analysis。
举例:我是中国人 –> 我/是/中国人
4.2 分词api
指定分词器进行分词
1 | POST /_analyze |
结果:
在结果中不仅可以看出分词的结果,还返回了该词在文本中的位置。
指定索引分词
1 | POST /itcast/_analyze |
4.3 中文分词
中文分词的难点在于,在汉语中没有明显的词汇分界点,如在英语中,空格可以作为分隔符,如果分隔不正确就会造成歧义。
如:
我/爱/炒肉丝
我/爱/炒/肉丝
常用中文分词器,IK、jieba、THULAC等,推荐使用IK分词器。
IK Analyzer是一个开源的,基于java语言开发的轻量级的中文分词工具包。从2006年12月推出1.0版开始,IKAnalyzer已经推出了3个大版本。最初,它是以开源项目Luence为应用主体的,结合词典分词和文法分析算法的中文分词组件。新版本的IK Analyzer 3.0则发展为面向Java的公用分词组件,独立于Lucene项目,同时提供了对Lucene的默认优化实现。
采用了特有的“正向迭代最细粒度切分算法“,具有80万字/秒的高速处理能力 采用了多子处理器分析模式,支持:英文字母(IP地址、Email、URL)、数字(日期,常用中文数量词,罗马数字,科学计数法),中文词汇(姓名、地名处理)等分词处理。 优化的词典存储,更小的内存占用。
IK分词器 Elasticsearch插件地址:https://github.com/medcl/elasticsearch-analysis-ik
1 | #安装方法:将下载到的elasticsearch-analysis-ik-6.5.4.zip解压到/elasticsearch/plugins/ik目录下即可。 |
测试:
1 | POST /_analyze |
结果:
1 | { |
可以看到,已经对中文进行了分词。
5. 全文搜索
全文搜索两个最重要的方面是:
- 相关性(Relevance) 它是评价查询与其结果间的相关程度,并根据这种相关程度对结果排名的一种能力,这种计算方式可以是 TF/IDF 方法、地理位置邻近、模糊相似,或其他的某些算法。
- 分词(Analysis) 它是将文本块转换为有区别的、规范化的 token 的一个过程,目的是为了创建倒排索引以及查询倒排索引。
5.1 构造数据
1 | PUT /itcast |
批量插入数据:
1 | POST http://172.16.55.185:9200/itcast/_bulk |
结果:
5.2 单词搜索
1 | POST /itcast/person/_search |
结果:
1 | { |
过程说明:
检查字段类型
爱好 hobby 字段是一个 text 类型( 指定了IK分词器),这意味着查询字符串本身也应该被分词。
分析查询字符串 。
将查询的字符串 “音乐” 传入IK分词器中,输出的结果是单个项 音乐。因为只有一个单词项,所以 match 查询执行的是单个底层 term 查询。
查找匹配文档 。
用 term 查询在倒排索引中查找 “音乐” 然后获取一组包含该项的文档,本例的结果是文档:3 、5 。
为每个文档评分 。
用 term 查询计算每个文档相关度评分 _score ,这是种将 词频(term frequency,即词 “音乐” 在相关文档的hobby 字段中出现的频率)和 反向文档频率(inverse document frequency,即词 “音乐” 在所有文档的hobby 字段中出现的频率),以及字段的长度(即字段越短相关度越高)相结合的计算方式。
5.3 多词搜索
1 | POST /itcast/person/_search |
结果:
1 | { |
可以看到,包含了“音乐”、“篮球”的数据都已经被搜索到了。
可是,搜索的结果并不符合我们的预期,因为我们想搜索的是既包含“音乐”又包含“篮球”的用户,显然结果返回的“或”的关系。
在Elasticsearch中,可以指定词之间的逻辑关系,如下:
1 | POST /itcast/person/_search |
结果:
可以看到结果符合预期。
前面我们测试了“OR” 和 “AND”搜索,这是两个极端,其实在实际场景中,并不会选取这2个极端,更有可能是选取这种,或者说,只需要符合一定的相似度就可以查询到数据,在Elasticsearch中也支持这样的查询,通过minimum_should_match来指定匹配度,如:70%;
示例:
1 | { |
相似度应该多少合适,需要在实际的需求中进行反复测试,才可得到合理的值。
5.4 组合搜索
在搜索时,也可以使用过滤器中讲过的bool组合查询,示例:
1 | POST /itcast/person/_search |
上面搜索的意思是:搜索结果中必须包含篮球,不能包含音乐,如果包含了游泳,那么它的相似度更高。
结果:
评分的计算规则
bool 查询会为每个文档计算相关度评分 _score , 再将所有匹配的 must 和 should 语句的分数 _score 求和,最后除以 must 和 should 语句的总数。
must_not 语句不会影响评分; 它的作用只是将不相关的文档排除。
默认情况下,should中的内容不是必须匹配的,如果查询语句中没有must,那么就会至少匹配其中一个。当然了,也可以通过minimum_should_match参数进行控制,该值可以是数字也可以的百分比。
示例:
1 | POST /itcast/person/_search |
minimum_should_match为2,意思是should中的三个词,至少要满足2个。
结果:
5.5 权重
有些时候,我们可能需要对某些词增加权重来影响该条数据的得分。如下:
搜索关键字为“游泳篮球”,如果结果中包含了“音乐”权重为10,包含了“跑步”权重为2。
1 | POST /itcast/person/_search |
结果:
如果不设置权重的查询结果是这样:
6. Elasticsearch集群
6.1 集群节点
ELasticsearch的集群是由多个节点组成的,通过cluster.name设置集群名称,并且用于区分其它的集群,每个节点通过node.name指定节点的名称。
在Elasticsearch中,节点的类型主要有4种:
- master节点
- 配置文件中node.master属性为true(默认为true),就有资格被选为master节点。
- master节点用于控制整个集群的操作。比如创建或删除索引,管理其它非master节点等。
- data节点
- 配置文件中node.data属性为true(默认为true),就有资格被设置成data节点。
- data节点主要用于执行数据相关的操作。比如文档的CRUD。
- 客户端节点
- 配置文件中node.master属性和node.data属性均为false。
- 该节点不能作为master节点,也不能作为data节点。
- 可以作为客户端节点,用于响应用户的请求,把请求转发到其他节点
- 部落节点
- 当一个节点配置tribe.*的时候,它是一个特殊的客户端,它可以连接多个集群,在所有连接的集群上执行搜索和其他操作。
6.2 搭建集群
1 | #启动3个虚拟机,分别在3台虚拟机上部署安装Elasticsearch |
创建索引:
查询集群状态:/_cluster/health
1 | { |
集群状态的三种颜色:
颜色 | 意义 |
---|---|
green | 所有主要分片和复制分片都可用 |
yellow | 所有主要分片可用,但不是所有复制分片都可用 |
red | 不是所有的主要分片都可用 |
6.3 分片和副本
为了将数据添加到Elasticsearch,我们需要索引(index)——一个存储关联数据的地方。实际上,索引只是一个用来指向一个或多个分片(shards)的“逻辑命名空间(logical namespace)”.
- 一个分片(shard)是一个最小级别“工作单元(worker unit)”,它只是保存了索引中所有数据的一部分。
- 我们需要知道是分片就是一个Lucene实例,并且它本身就是一个完整的搜索引擎。应用程序不会和它直接通信。
- 分片可以是主分片(primary shard)或者是复制分片(replica shard)。
- 索引中的每个文档属于一个单独的主分片,所以主分片的数量决定了索引最多能存储多少数据。
- 复制分片只是主分片的一个副本,它可以防止硬件故障导致的数据丢失,同时可以提供读请求,比如搜索或者从别的shard取回文档。
- 当索引创建完成的时候,主分片的数量就固定了,但是复制分片的数量可以随时调整。
6.4 故障转移
6.4.1 将data节点停止
这里选择将node02停止:
说明:
当前集群状态为黄色,表示主节点可用,副本节点不完全可用
过一段时间观察,发现节点列表中看不到node02,副本节点分配到了node01和node03,集群状态恢复到绿色。
将node02恢复:
1 | ./node02/bin/elasticsearch |
可以看到,node02恢复后,重新加入了集群,并且重新分配了节点信息。
6.4.2 将master节点停止
接下来,测试将node01停止,也就是将主节点停止。
从结果中可以看出,集群对master进行了重新选举,选择node03为master。并且集群状态变成黄色。
等待一段时间后,集群状态从黄色变为了绿色:
恢复node01节点:
1 | ./node01/bin/elasticsearch |
重启之后,发现node01可以正常加入到集群中,集群状态依然为绿色:
特别说明:
如果在配置文件中discovery.zen.minimum_master_nodes设置的不是N/2+1时,会出现脑裂问题,之前宕机的主节点恢复后不会加入到集群。
6.5 分布式文档
6.5.1 路由
首先,来看个问题:
如图所示:当我们想一个集群保存文档时,文档该存储到哪个节点呢? 是随机吗? 是轮询吗?
实际上,在ELasticsearch中,会采用计算的方式来确定存储到哪个节点,计算公式如下:
1 | shard = hash(routing) % number_of_primary_shards |
- outing值是一个任意字符串,它默认是_id但也可以自定义。
- 这个routing字符串通过哈希函数生成一个数字,然后除以主切片的数量得到一个余数(remainder),余数的范围永远是0到number_of_primary_shards - 1,这个数字就是特定文档所在的分片。
这就是为什么创建了主分片后,不能修改的原因。
6.5.2 文档的写操作
新建索引和删除请求都是写(write)操作,它们必须在主分片上成功完成才能复制到相关的复制分片上。
下面我们罗列在主分片和复制分片上成功新建索引或删除一个文档必要的顺序步骤:
- 客户端给 Node 1 发送新建索引或删除请求。
- 节点使用文档的 _id 确定文档属于分片 0 。它转发请求到 Node 3 ,分片 0 位于这个节点上。
- Node 3 在主分片上执行请求,如果成功,它转发请求到相应的位于 Node 1 和 Node 2 的复制节点上。当所有的复制节点报告成功, Node 3 报告成功到请求的节点,请求的节点再报告给客户端。
- 客户端接收到成功响应的时候,文档的修改已经被应用于主分片和所有的复制分片。你的修改生效了。
6.5.3 搜索文档(单个文档)
文档能够从主分片或任意一个复制分片被检索。
下面我们罗列在主分片或复制分片上检索一个文档必要的顺序步骤:
- 客户端给 Node 1 发送get请求。
- 节点使用文档的 _id 确定文档属于分片 0 。分片 0 对应的复制分片在三个节点上都有。此时,它转发请求到Node 2 。
- Node 2 返回文档(document)给 Node 1 然后返回给客户端。
对于读请求,为了平衡负载,请求节点会为每个请求选择不同的分片——它会循环所有分片副本。
可能的情况是,一个被索引的文档已经存在于主分片上却还没来得及同步到复制分片上。这时复制分片会报告文档未找到,主分片会成功返回文档。一旦索引请求成功返回给用户,文档则在主分片和复制分片都是可用的。
6.5.4 全文搜索
对于全文搜索而言,文档可能分散在各个节点上,那么在分布式的情况下,如何搜索文档呢?
搜索,分为2个阶段,搜索(query)+取回(fetch)。
搜索(query)
查询阶段包含以下三步:
- 客户端发送一个 search(搜索) 请求给 Node 3 , Node 3 创建了一个长度为 from+size 的空优先级队
- Node 3 转发这个搜索请求到索引中每个分片的原本或副本。每个分片在本地执行这个查询并且结果将结果到一个大小为 from+size 的有序本地优先队列里去。
- 每个分片返回document的ID和它优先队列里的所有document的排序值给协调节点 Node 3 。 Node 3 把这些值合并到自己的优先队列里产生全局排序结果。
取回(fetch)
分发阶段由以下步骤构成:
- 协调节点辨别出哪个document需要取回,并且向相关分片发出 GET 请求。
- 每个分片加载document并且根据需要丰富(enrich)它们,然后再将document返回协调节点。
- 一旦所有的document都被取回,协调节点会将结果返回给客户端。
7. Java客户端
在Elasticsearch中,为java提供了2种客户端,一种是REST风格的客户端,另一种是Java API的客户端。
https://www.elastic.co/guide/en/elasticsearch/client/index.html
7.1 REST客户端
Elasticsearch提供了2种REST客户端,一种是低级客户端,一种是高级客户端。
- Java Low Level REST Client:官方提供的低级客户端。该客户端通过http来连接Elasticsearch集群。用户在使用该客户端时需要将请求数据手动拼接成Elasticsearch所需JSON格式进行发送,收到响应时同样也需要将返回的JSON数据手动封装成对象。虽然麻烦,不过该客户端兼容所有的Elasticsearch版本。
- Java High Level REST Client:官方提供的高级客户端。该客户端基于低级客户端实现,它提供了很多便捷的API来解决低级客户端需要手动转换数据格式的问题。
7.2 构造数据
1 | POST /haoke/house/_bulk |
7.3 REST低级客户端
7.3.1 创建工程
创建工程itcast-elasticsearch:
1 |
|
7.3.2 编写测试用例
1 | public class TestESREST { |
从使用中,可以看出,基本和我们使用RESTful api使用几乎是一致的。
7.4 REST高级客户端
7.4.1 引入依赖
1 | <dependency> |
7.4.2 编写测试用例
1 | public class TestRestHighLevel { |
-------------本文结束感谢您的阅读-------------
本文标题: ElasticStack(一)
本文链接: https://wgy1993.gitee.io/archives/b4bf25de.html
版权声明: 本作品采用 CC BY-NC-SA 4.0 进行许可。转载请注明出处!
