Elasticsearch-尚硅谷笔记

第2章 Elasticsearch 入门
2.1 Elasticsearch 安装
2.1.1 下载软件
Elasticsearch 的官方地址:https://www.elastic.co/cn/
下载地址:https://www.elastic.co/cn/downloads/past-releases#elasticsearch
2.1.2 安装软件
Windows 版的 Elasticsearch 的安装很简单,解压即安装完毕
解压后,进入 bin 文件目录,点击 elasticsearch.bat 文件启动 ES 服务
注意:9300 端口为 Elasticsearch 集群间组件的通信端口,9200 端口为浏览器访问的 http
协议 RESTful 端口。
打开浏览器(推荐使用谷歌浏览器),输入地址:http://localhost:9200,测试结果
2.1.3 问题解决
双击启动窗口闪退,通过路径访问追踪错误,如果是“空间不足”,请修改
config/jvm.options 配置文件

设置 JVM 初始内存为 1G。此值可以设置与-Xmx 相同,以避免每次垃圾回收完成后 JVM 重新分配内存

Xms represents the initial size of total heap space

设置 JVM 最大可用内存为 1G

Xmx represents the maximum size of total heap space

-Xms1g
-Xmx1g
2.2 Elasticsearch 基本操作
2.2.4 HTTP 操作
2.2.4.1 索引操作

  1. 创建索引
    对比关系型数据库,创建索引就等同于创建数据库
    在 Postman 中,向 ES 服务器发 PUT 请求 :http://127.0.0.1:9200/shopping
    如果重复添加索引,会返回错误信息
  2. 查看所有索引
    在 Postman 中,向 ES 服务器发 GET 请求 :http://127.0.0.1:9200/_cat/indices?v
  3. 查看单个索引
    在 Postman 中,向 ES 服务器发 GET 请求 :http://127.0.0.1:9200/shopping
  4. 删除索引
    在 Postman 中,向 ES 服务器发 DELETE 请求 :http://127.0.0.1:9200/shopping
    2.2.4.2 文档操作
  5. 创建文档
    在 Postman 中,向 ES 服务器发 POST 请求 :http://127.0.0.1:9200/shopping/_doc
    请求体内容为:
    {
    “title”:“小米手机”,
    “category”:“小米”,
    “images”:“http://www.gulixueyuan.com/xm.jpg”,
    “price”:3999.00
    }
    此处发送请求的方式必须为 POST,不能是 PUT,否则会发生错误
    上面的数据创建后,由于没有指定数据唯一性标识(ID),默认情况下,ES 服务器会随机
    生成一个。
    如果想要自定义唯一性标识,需要在创建时指定:http://127.0.0.1:9200/shopping/_doc/1
  6. 查看文档
    查看文档时,需要指明文档的唯一性标识,类似于 MySQL 中数据的主键查询
    在 Postman 中,向 ES 服务器发 GET 请求 :http://127.0.0.1:9200/shopping/_doc/1
  7. 修改文档
    和新增文档一样,输入相同的 URL 地址请求,如果请求体变化,会将原有的数据内容覆盖
    在 Postman 中,向 ES 服务器发 POST 请求 :http://127.0.0.1:9200/shopping/_doc/1
  8. 修改字段
    修改数据时,也可以只修改某一给条数据的局部信息
    在 Postman 中,向 ES 服务器发 POST 请求 :http://127.0.0.1:9200/shopping/_update/1
    请求体内容为:
    {
    “doc”: {
    “price”:3000.00
    }
    }
  9. 删除文档
    删除一个文档不会立即从磁盘上移除,它只是被标记成已删除(逻辑删除)。
    在 Postman 中,向 ES 服务器发 DELETE 请求 :http://127.0.0.1:9200/shopping/_doc/1
  10. 条件删除文档
    一般删除数据都是根据文档的唯一性标识进行删除,实际操作时,也可以根据条件对多条数
    据进行删除
    向 ES 服务器发 POST 请求 :http://127.0.0.1:9200/shopping/_delete_by_query
    {
    “query”: {
    “match”: {
    “price”: 4000
    }
    }
    }
    2.2.4.3 映射操作
    有了索引库,等于有了数据库中的 database。
    接下来就需要建索引库(index)中的映射了,类似于数据库(database)中的表结构(table)。
    创建数据库表需要设置字段名称,类型,长度,约束等;索引库也一样,需要知道这个类型
    下有哪些字段,每个字段有哪些约束信息,这就叫做映射(mapping)。
  11. 创建映射
    在 Postman 中,向 ES 服务器发 PUT 请求 :http://127.0.0.1:9200/student/_mapping
    请求体内容为:
    {
    “properties”: {
    “name”: {
    “type”: “text”,
    “index”: true
    },
    “sex”: {
    “type”: “text”,
    “index”: false
    },
    “age”: {
    “type”: “long”,
    “index”: false
    }
    }
    }
    映射数据说明:
     字段名:任意填写,下面指定许多属性,例如:title、subtitle、images、price
     type:类型,Elasticsearch 中支持的数据类型非常丰富,说几个关键的:

    String 类型,又分两种:
    text:可分词
    keyword:不可分词,数据会作为完整字段进行匹配

    Numerical:数值类型,分两类
    基本数据类型:long、integer、short、byte、double、float、half_float

浮点数的高精度类型:scaled_float
 Date:日期类型
 Array:数组类型
 Object:对象

index:是否索引,默认为 true,也就是说你不进行任何配置,所有字段都会被索引。
true:字段会被索引,则可以用来进行搜索
false:字段不会被索引,不能用来搜索

store:是否将数据进行独立存储,默认为 false
原始的文本会存储在_source 里面,默认情况下其他提取出来的字段都不是独立存储
的,是从_source 里面提取出来的。当然你也可以独立的存储某个字段,只要设置
“store”: true 即可,获取独立存储的字段要比从_source 中解析快得多,但是也会占用
更多的空间,所以要根据实际业务需求来设置。

analyzer:分词器,这里的 ik_max_word 即使用 ik 分词器,

  1. 查看映射
    在 Postman 中,向 ES 服务器发 GET 请求 :http://127.0.0.1:9200/student/_mapping
  2. 索引映射关联
    在 Postman 中,向 ES 服务器发 PUT 请求 :http://127.0.0.1:9200/student1
    {
    “settings”: {},
    “mappings”: {
    “properties”: {
    “name”: {
    “type”: “text”,
    “index”: true
    },
    “sex”: {
    “type”: “text”,
    “index”: false
    },
    “age”: {
    “type”: “long”,
    “index”: false
    }
    }
    }
    }
    2.2.4.4 高级查询
    Elasticsearch 提供了基于 JSON 提供完整的查询 DSL 来定义查询
  3. 查询所有文档
    在 Postman 中,向 ES 服务器发 GET 请求 :http://127.0.0.1:9200/student/_search
    {
    “query”: {
    “match_all”: {}
    }
    }

“query”:这里的 query 代表一个查询对象,里面可以有不同的查询属性

“match_all”:查询类型,例如:match_all(代表查询所有), match,term , range 等等

{查询条件}:查询条件会根据类型的不同,写法也有差异

  1. 匹配查询
    match 匹配类型查询,会把查询条件进行分词,然后进行查询,多个词条之间是 or 的关系
    在 Postman 中,向 ES 服务器发 GET 请求 :http://127.0.0.1:9200/student/_search
    {
    “query”: {
    “match”: {
    “name”: “zhangsan”
    }
    }
    }
  2. 字段匹配查询
    multi_match 与 match 类似,不同的是它可以在多个字段中查询。
    在 Postman 中,向 ES 服务器发 GET 请求 :http://127.0.0.1:9200/student/_search
    {
    “query”: {
    “multi_match”: {
    “query”: “zhangsan”,
    “fields”: [
    “name”,
    “nickname”
    ]
    }
    }
    }
  3. 关键字精确查询
    term 查询,精确的关键词匹配查询,不对查询条件进行分词。
    在 Postman 中,向 ES 服务器发 GET 请求 :http://127.0.0.1:9200/student/_search
    {
    “query”: {
    “term”: {
    “name”: {
    “value”: “zhangsan”
    }
    }
    }
    }
  4. 多关键字精确查询
    terms 查询和 term 查询一样,但它允许你指定多值进行匹配。
    如果这个字段包含了指定值中的任何一个值,那么这个文档满足条件,类似于 mysql 的 in
    在 Postman 中,向 ES 服务器发 GET 请求 :http://127.0.0.1:9200/student/_search
    {
    “query”: {
    “terms”: {
    “name”: [
    “zhangsan”,
    “lisi”
    ]
    }
    }
    }
  5. 指定查询字段
    默认情况下,Elasticsearch 在搜索的结果中,会把文档中保存在_source 的所有字段都返回。
    如果我们只想获取其中的部分字段,我们可以添加_source 的过滤
    在 Postman 中,向 ES 服务器发 GET 请求 :http://127.0.0.1:9200/student/_search
    {
    “_source”: [
    “name”,
    “nickname”
    ],
    “query”: {
    “terms”: {
    “nickname”: [
    “zhangsan”
    ]
    }
    }
    }
  6. 过滤字段
    我们也可以通过:
     includes:来指定想要显示的字段
     excludes:来指定不想要显示的字段
    在 Postman 中,向 ES 服务器发 GET 请求 :http://127.0.0.1:9200/student/_search
    {
    “_source”: {
    “includes”: [
    “name”,
    “nickname”
    ]
    },
    “query”: {
    “terms”: {
    “nickname”: [
    “zhangsan”
    ]
    }
    }
    }

在 Postman 中,向 ES 服务器发 GET 请求 :http://127.0.0.1:9200/student/_search
{
“_source”: {
“excludes”: [
“name”,
“nickname”
]
},
“query”: {
“terms”: {
“nickname”: [
“zhangsan”
]
}
}
}
8) 组合查询
bool把各种其它查询通过must(必须 )、must_not(必须不)、should(应该)的方
式进行组合
在 Postman 中,向 ES 服务器发 GET 请求 :http://127.0.0.1:9200/student/_search
{
“query”: {
“bool”: {
“must”: [
{
“match”: {
“name”: “zhangsan”
}
}
],
“must_not”: [
{
“match”: {
“age”: “40”
}
}
],
“should”: [
{
“match”: {
“sex”: “男”
}
}
]
}
}
}
9) 范围查询
range 查询找出那些落在指定区间内的数字或者时间。range 查询允许以下字符
操作符
说明
gt 大于>
gte 大于等于>=
lt 小于<
lte 小于等于<=
在 Postman 中,向 ES 服务器发 GET 请求 :http://127.0.0.1:9200/student/_search
{
“query”: {
“range”: {
“age”: {
“gte”: 30,
“lte”: 35
}
}
}
}
10) 模糊查询
返回包含与搜索字词相似的字词的文档。
编辑距离是将一个术语转换为另一个术语所需的一个字符更改的次数。这些更改可以包括:
 更改字符(box → fox)
 删除字符(black → lack)
 插入字符(sic → sick)
 转置两个相邻字符(act → cat)
为了找到相似的术语,fuzzy 查询会在指定的编辑距离内创建一组搜索词的所有可能的变体
或扩展。然后查询返回每个扩展的完全匹配。
通过 fuzziness 修改编辑距离。一般使用默认值 AUTO,根据术语的长度生成编辑距离。
在 Postman 中,向 ES 服务器发 GET 请求 :http://127.0.0.1:9200/student/_search
{
“query”: {
“fuzzy”: {
“title”: {
“value”: “zhangsan”
}
}
}
}
在 Postman 中,向 ES 服务器发 GET 请求 :http://127.0.0.1:9200/student/_search
{
“query”: {
“fuzzy”: {
“title”: {
“value”: “zhangsan”,
“fuzziness”: 2
}
}
}
}
11) 单字段排序
sort 可以让我们按照不同的字段进行排序,并且通过 order 指定排序的方式。desc 降序,asc 升序。
在 Postman 中,向 ES 服务器发 GET 请求 :http://127.0.0.1:9200/student/_search
{
“query”: {
“match”: {
“name”: “zhangsan”
}
},
“sort”: [
{
“age”: {
“order”: “desc”
}
}
]
}
12) 多字段排序
假定我们想要结合使用 age 和 _score 进行查询,并且匹配的结果首先按照年龄排序,然后按照相关性得分排序
在 Postman 中,向 ES 服务器发 GET 请求 :http://127.0.0.1:9200/student/_search
{
“query”: {
“match_all”: {}
},
“sort”: [
{
“age”: {
“order”: “desc”
}
},
{
“_score”: {
“order”: “desc”
}
}
]
}
13) 高亮查询
在进行关键字搜索时,搜索出的内容中的关键字会显示不同的颜色,称之为高亮。
Elasticsearch 可以对查询内容中的关键字部分,进行标签和样式(高亮)的设置。
在使用 match 查询的同时,加上一个 highlight 属性:
 pre_tags:前置标签
 post_tags:后置标签
 fields:需要高亮的字段
 title:这里声明 title 字段需要高亮,后面可以为这个字段设置特有配置,也可以空
在 Postman 中,向 ES 服务器发 GET 请求 :http://127.0.0.1:9200/student/_search
{
“query”: {
“match”: {
“name”: “zhangsan”
}
},
“highlight”: {
“pre_tags”: “”,
“post_tags”: “
”,
“fields”: {
“name”: {}
}
}
}
14) 分页查询
from:当前页的起始索引,默认从 0 开始。 from = (pageNum - 1) * size
size:每页显示多少条
在 Postman 中,向 ES 服务器发 GET 请求 :http://127.0.0.1:9200/student/_search
{
“query”: {
“match_all”: {}
},
“sort”: [
{
“age”: {
“order”: “desc”
}
}
],
“from”: 0,
“size”: 2
}
15) 聚合查询
聚合允许使用者对 es 文档进行统计分析,类似与关系型数据库中的 group by,当然还有很
多其他的聚合,例如取最大值、平均值等等。
 对某个字段取最大值 max
在 Postman 中,向 ES 服务器发 GET 请求 :http://127.0.0.1:9200/student/_search
{
“aggs”: {
“max_age”: {
“max”: {
“field”: “age”
}
}
},
“size”: 0
}

 对某个字段取最小值 min
在 Postman 中,向 ES 服务器发 GET 请求 :http://127.0.0.1:9200/student/_search
{
“aggs”: {
“min_age”: {
“min”: {
“field”: “age”
}
}
},
“size”: 0
}

 对某个字段求和 sum
在 Postman 中,向 ES 服务器发 GET 请求 :http://127.0.0.1:9200/student/_search
{
“aggs”: {
“sum_age”: {
“sum”: {
“field”: “age”
}
}
},
“size”: 0
}

 对某个字段取平均值 avg
在 Postman 中,向 ES 服务器发 GET 请求 :http://127.0.0.1:9200/student/_search
{
“aggs”: {
“avg_age”: {
“avg”: {
“field”: “age”
}
}
},
“size”: 0
}

 对某个字段的值进行去重之后再取总数
在 Postman 中,向 ES 服务器发 GET 请求 :http://127.0.0.1:9200/student/_search
{
“aggs”: {
“distinct_age”: {
“cardinality”: {
“field”: “age”
}
}
},
“size”: 0
}

 State 聚合
stats 聚合,对某个字段一次性返回 count,max,min,avg 和 sum 五个指标
在 Postman 中,向 ES 服务器发 GET 请求 :http://127.0.0.1:9200/student/_search
{
“aggs”: {
“stats_age”: {
“stats”: {
“field”: “age”
}
}
},
“size”: 0
}

  1. 桶聚合查询
    桶聚和相当于 sql 中的 group by 语句
     terms 聚合,分组统计
    在 Postman 中,向 ES 服务器发 GET 请求 :http://127.0.0.1:9200/student/_search
    {
    “aggs”: {
    “age_groupby”: {
    “terms”: {
    “field”: “age”
    }
    }
    },
    “size”: 0
    }
     在 terms 分组下再进行聚合
    在 Postman 中,向 ES 服务器发 GET 请求 :http://127.0.0.1:9200/student/_search
    {
    “aggs”: {
    “age_groupby”: {
    “terms”: {
    “field”: “age”
    }
    }
    },
    “size”: 0
    }

2.2.5 Java API 操作
2.2.5.2 客户端对象
2.2.5.3 索引操作
2.2.5.4 文档操作
5) 批量操作
2.2.5.5 高级查询
第3章 Elasticsearch 环境
3.1 相关概念
3.1.1 单机 & 集群
配置服务器集群时,集群中节点数量没有限制,大于等于 2 个节点就可以看做是集群了。一
般出于高性能及高可用方面来考虑集群中节点数量都是 3 个以上。
3.1.2 集群 Cluster
一个集群就是由一个或多个服务器节点组织在一起,共同持有整个的数据,并一起提供
索引和搜索功能。一个 Elasticsearch 集群有一个唯一的名字标识,这个名字默认就
是”elasticsearch”。这个名字是重要的,因为一个节点只能通过指定某个集群的名字,来加入
这个集群。
3.1.3 节点 Node
集群中包含很多服务器,一个节点就是其中的一个服务器。作为集群的一部分,它存储
数据,参与集群的索引和搜索功能。

一个节点也是由一个名字来标识的

一个节点可以通过配置集群名称的方式来加入一个指定的集群。默认情况下,每个节点
都会被安排加入到一个叫做“elasticsearch”的集群中,这意味着,如果你在你的网络中启动了
若干个节点,并假定它们能够相互发现彼此,它们将会自动地形成并加入到一个叫做
“elasticsearch”的集群中。

在一个集群里,只要你想,可以拥有任意多个节点。而且,如果当前你的网络中没有运
行任何 Elasticsearch 节点,这时启动一个节点,会默认创建并加入一个叫做“elasticsearch”的集群。
3.2 Windows 集群
3.2.1 部署集群

  1. 创建 elasticsearch-cluster 文件夹,在内部复制三个 elasticsearch 服务
  2. 修改集群文件目录中每个节点的 config/elasticsearch.yml 配置文件
     node-1001 节点
    #节点 1 的配置信息:
    #集群名称,节点之间要保持一致
    cluster.name: my-elasticsearch
    #节点名称,集群内要唯一
    node.name: node-1001
    node.master: true
    node.data: true
    #ip 地址
    network.host: localhost
    #http 端口
    http.port: 1001
    #tcp 监听端口
    transport.tcp.port: 9301
    #discovery.seed_hosts: [“localhost:9301”, “localhost:9302”,“localhost:9303”]
    #discovery.zen.fd.ping_timeout: 1m
    #discovery.zen.fd.ping_retries: 5
    #集群内的可以被选为主节点的节点列表
    #cluster.initial_master_nodes: [“node-1”, “node-2”,“node-3”]
    #跨域配置
    #action.destructive_requires_name: true
    http.cors.enabled: true
    http.cors.allow-origin: “*”
    3.2.2 启动集群
  3. 启动前先删除每个节点中的 data 目录中所有内容(如果存在)
  4. 分别双击执行 bin/elasticsearch.bat, 启动节点服务器,启动后,会自动加入指定名称的
    集群
    3.2.3 测试集群
    3.3 Linux 单机
    3.3.1 软件下载
    3.3.2 软件安装
  5. 解压软件
    将下载的软件解压缩
  6. 创建用户
    因为安全问题,Elasticsearch 不允许 root 用户直接运行,所以要创建新用户,在 root 用
    户中创建新用户
  7. 修改配置文件
    修改/opt/module/es/config/elasticsearch.yml 文件
    修改/etc/security/limits.conf

在文件末尾中增加下面内容

每个进程可以打开的文件数的限制

es soft nofile 65536
es hard nofile 65536
修改/etc/security/limits.d/20-nproc.conf

在文件末尾中增加下面内容

每个进程可以打开的文件数的限制

es soft nofile 65536
es hard nofile 65536
3.3.3 启动软件
使用 ES 用户启动
cd /opt/module/es/
#启动
bin/elasticsearch
#后台启动
bin/elasticsearch -d
启动时,会动态生成文件,如果文件所属用户不匹配,会发生错误,需要重新进行修改用户
和用户组
3.3.3 测试软件
浏览器中输入地址:http://linux1:9200/
3.4 Linux 集群(同windows)
第4章 Elasticsearch 进阶
4.1 核心概念
4.1.1 索引(Index)
相当于数据库
4.1.2 类型(Type) 已弃用
在一个索引中,你可以定义一种或多种类型。
一个类型是你的索引的一个逻辑上的分类/分区,其语义完全由你来定。通常,会为具
有一组共同字段的文档定义一个类型
4.1.3 文档(Document)
一个文档是一个可被索引的基础信息单元,也就是一条数据
文档以 JSON格式来表示
4.1.4 字段(Field)
相当于是数据表的字段,对文档数据根据不同属性进行的分类标识
4.1.5 映射(Mapping)
mapping 是处理数据的方式和规则方面做一些限制,如:某个字段的数据类型、默认值、
分析器、是否被索引等等。这些都是映射里面可以设置的,其它就是处理 ES 里面数据的一些使用规则设置也叫做映射,按着最优规则处理数据对性能提高很大,因此才需要建立映射,并且需要思考如何建立映射才能对性能更好。
4.1.6 分片(Shards)
提供了将索引划分成多份的能力,每一份就称之为分片。当你创建一个索引的时候,你可以指定你想要的分片的数量。每个分片本身也是一个功能完善并且独立的“索引”,这个“索引”可以被放置到集群中的任何节点上。
分片很重要,主要有两方面的原因:
1)允许你水平分割 / 扩展你的内容容量。
2)允许你在分片之上进行分布式的、并行的操作,进而提高性能/吞吐量。
至于一个分片怎样分布,它的文档怎样聚合和搜索请求,是完全由 Elasticsearch 管理的,
对于作为用户的你来说,这些都是透明的,无需过分关心。
4.1.7 副本(Replicas)
在一个网络 / 云的环境里,失败随时都可能发生,在某个分片/节点不知怎么的就处于
离线状态,或者由于任何原因消失了,这种情况下,有一个故障转移机制是非常有用并且是
强烈推荐的。为此目的,Elasticsearch 允许你创建分片的一份或多份拷贝,这些拷贝叫做复
制分片(副本)。
复制分片之所以重要,有两个主要原因:
在分片/节点失败的情况下,提供了高可用性。因为这个原因,注意到复制分片从不与
原/主要(original/primary)分片置于同一节点上是非常重要的。
扩展你的搜索量/吞吐量,因为搜索可以在所有的副本上并行运行。

默认情况下,Elasticsearch 中的每个索引被分片 1 个主分片和 1 个复制,这意味着,如果你的集群中至少有两个节点,你的索引将会有 1 个主分片和另外 1 个复制分片(1 个完全拷贝),这样的话每个索引总共就有 2 个分片,我们需要根据索引需要确定分片个数
4.1.8 分配(Allocation)
将分片分配给某个节点的过程,包括分配主分片或者副本。如果是副本,还包含从主分
片复制数据的过程。这个过程是由 master 节点完成的。
4.2 系统架构

一个运行中的 Elasticsearch 实例称为一个节点,而集群是由一个或者多个拥有相同
cluster.name 配置的节点组成,它们共同承担数据和负载的压力。当有节点加入集群中或者
从集群中移除节点时,集群将会重新平均分布所有的数据。

当一个节点被选举成为主节点时,它将负责管理集群范围内的所有变更,例如增加、
删除索引,或者增加、删除节点等。 而主节点并不需要涉及到文档级别的变更和搜索等操
作,所以当集群只拥有一个主节点的情况下,即使流量的增加它也不会成为瓶颈。 任何节
点都可以成为主节点。我们的示例集群就只有一个节点,所以它同时也成为了主节点。

作为用户,我们可以将请求发送到集群中的任何节点 ,包括主节点。 每个节点都知道
任意文档所处的位置,并且能够将我们的请求直接转发到存储我们所需文档的节点。 无论
我们将请求发送到哪个节点,它都能负责从各个包含我们所需文档的节点收集回数据,并将
最终结果返回給客户端。 Elasticsearch 对这一切的管理都是透明的。
4.3 分布式集群
4.3.1 单节点集群
我们在包含一个空节点的集群内创建名为 users 的索引,为了演示目的,我们将分配 3
个主分片和一份副本(每个主分片拥有一个副本分片)
{
“settings” : {
“number_of_shards” : 3,
“number_of_replicas” : 1
}
}
4.3.2 故障转移
当集群中只有一个节点在运行时,意味着会有一个单点故障问题——没有冗余。 幸运
的是,我们只需再启动一个节点即可防止数据丢失。当你在同一台机器上启动了第二个节点
时,只要它和第一个节点有同样的 cluster.name 配置,它就会自动发现集群并加入到其中。
但是在不同机器上启动节点的时候,为了加入到同一集群,你需要配置一个可连接到的单播
主机列表。之所以配置为使用单播发现,以防止节点无意中加入集群。只有在同一台机器上
运行的节点才会自动组成集群。
如果启动了第二个节点,我们的集群将会拥有两个节点的集群 : 所有主分片和副本分
片都已被分配
4.3.3 水平扩容
怎样为我们的正在增长中的应用程序按需扩容呢?当启动了第三个节点,我们的集群将
会拥有三个节点的集群 : 为了分散负载而对分片进行重新分配

主分片的数目在索引创建时就已经确定了下来。实际上,这个数目定义了这个索引能够
存储 的最大数据量。(实际大小取决于你的数据、硬件和使用场景。) 但是,读操作——
搜索和返回数据——可以同时被主分片 或 副本分片所处理,所以当你拥有越多的副本分片
时,也将拥有越高的吞吐量。
4.3.4 应对故障
我们关闭第一个节点,这时集群的状态为:关闭了一个节点后的集群

我们关闭的节点是一个主节点。而集群必须拥有一个主节点来保证正常工作,所以发生
的第一件事情就是选举一个新的主节点: Node 2 。在我们关闭 Node 1 的同时也失去了主
分片 1 和 2 ,并且在缺失主分片的时候索引也不能正常工作。 如果此时来检查集群的状况,我们看到的状态将会为 red :不是所有主分片都在正常工作
4.4 路由计算
当索引一个文档的时候,文档会被存储到一个主分片中。 Elasticsearch 如何知道一个
文档应该存放到哪个分片中呢?当我们创建文档时,它如何决定这个文档应当被存储在分片
1 还是分片 2 中呢?首先这肯定不会是随机的,否则将来要获取文档的时候我们就不知道
从何处寻找了。实际上,这个过程是根据下面这个公式决定的:

routing 是一个可变值,默认是文档的 _id ,也可以设置成一个自定义的值。 routing 通过
hash 函数生成一个数字,然后这个数字再除以 number_of_primary_shards (主分片的数量)
后得到余数 。这个分布在 0 到 number_of_primary_shards-1 之间的余数,就是我们所寻求
的文档所在分片的位置。

这就解释了为什么我们要在创建索引的时候就确定好主分片的数量 并且永远不会改变
这个数量:因为如果数量变化了,那么所有之前路由的值都会无效,文档也再也找不到了。
所有的文档 API( get 、 index 、 delete 、 bulk 、 update 以及 mget )都接受一
个叫做 routing 的路由参数 ,通过这个参数我们可以自定义文档到分片的映射。一个自定
义的路由参数可以用来确保所有相关的文档——例如所有属于同一个用户的文档——都被
存储到同一个分片中。
4.5 分片控制
我们假设有一个集群由三个节点组成。 它包含一个叫 emps 的索引,有两个主分片,
每个主分片有两个副本分片。相同分片的副本不会放在同一节点。

我们可以发送请求到集群中的任一节点。 每个节点都有能力处理任意请求。
每个节点都知 道集群中任一文档位置,所以可以直接将请求转发到需要的节点上。 在下面的例子中,将所有的请求发送到 Node 1,我们将其称为 协调节点(coordinating node) 。

当发送请求的时候, 为了扩展负载,更好的做法是轮询集群中所有的节点
4.5.1 写流程
新建、索引和删除 请求都是 写 操作, 必须在主分片上面完成之后才能被复制到相关的副本分片
新建,索引和删除文档所需要的步骤顺序:

  1. 客户端向 Node 1 发送新建、索引或者删除请求。
  2. 节点使用文档的 _id 确定文档属于分片 0 。请求会被转发到 Node 3,因为分片 0 的
    主分片目前被分配在 Node 3 上。
  3. Node 3 在主分片上面执行请求。如果成功了,它将请求并行转发到 Node 1 和 Node 2
    的副本分片上。一旦所有的副本分片都报告成功, Node 3 将向协调节点报告成功,协调
    节点向客户端报告成功。
    在客户端收到成功响应时,文档变更已经在主分片和所有副本分片执行完成,变更是安全的。
    有一些可选的请求参数允许您影响这个过程,可能以数据安全为代价提升性能。这些选项很
    少使用,因为 Elasticsearch 已经很快,但是为了完整起见,请参考下面表格:

新索引默认有 1 个副本分片,这意味着为满足规定数量应该需要两个活动的分片副本。 但是,这些默认的设置会阻止我们在单一节点上做任何事情。为了避免这个问题,要求只有当 number_of_replicas 大于 1 的时候,规定数量才会执行。
4.5.2 读流程
我们可以从主分片或者从其它任意副本分片检索文档
从主分片或者副本分片检索文档的步骤顺序:

  1. 客户端向 Node 1 发送获取请求。
  2. 节点使用文档的 _id 来确定文档属于分片 0 。分片 0 的副本分片存在于所有的三个
    节点上。 在这种情况下,它将请求转发到 Node 2 。
  3. Node 2 将文档返回给 Node 1 ,然后将文档返回给客户端。
    在处理读取请求时,协调结点在每次请求的时候都会通过轮询所有的副本分片来达到负载均
    衡。在文档被检索时,已经被索引的文档可能已经存在于主分片上但是还没有复制到副本分
    片。 在这种情况下,副本分片可能会报告文档不存在,但是主分片可能成功返回文档。 一
    旦索引请求成功返回给用户,文档在主分片和副本分片都是可用的
    4.5.3 更新流程
    部分更新一个文档结合了先前说明的读取和写入流程
    部分更新一个文档的步骤如下:
  4. 客户端向 Node 1 发送更新请求。
  5. 它将请求转发到主分片所在的 Node 3 。
  6. Node 3 从主分片检索文档,修改 _source 字段中的 JSON ,并且尝试重新索引主分片
    的文档。如果文档已经被另一个进程修改,它会重试步骤 3 ,超过 retry_on_conflict 次
    后放弃。
  7. 如果 Node 3 成功地更新文档,它将新版本的文档并行转发到 Node 1 和 Node 2 上的
    副本分片,重新建立索引。一旦所有副本分片都返回成功, Node 3 向协调节点也返回
    成功,协调节点向客户端返回成功。

当主分片把更改转发到副本分片时, 它不会转发更新请求。 相反,它转发完整文档的新版本。请记住, 这些更改将会异步转发到副本分片,并且不能保证它们以发送它们相同的顺序到达。 如果 Elasticsearch 仅 转发更改请求,则可能以错误的顺序应用更改,导致得到损坏的文档。
4.5.4 多文档操作流程
mget 和 bulk API 的模式类似于单文档模式。区别在于协调节点知道每个文档存在于
哪个分片中。它将整个多文档请求分解成 每个分片 的多文档请求,并且将这些请求并行转
发到每个参与节点。
协调节点一旦收到来自每个节点的应答,就将每个节点的响应收集整理成单个响应,返
回给客户端

用单个 mget 请求取回多个文档所需的步骤顺序:

  1. 客户端向 Node 1 发送 mget 请求。
  2. Node 1 为每个分片构建多文档获取请求,然后并行转发这些请求到托管在每个所需的
    主分片或者副本分片的节点上。一旦收到所有答复, Node 1 构建响应并将其返回给客
    户端。
    可以对 docs 数组中每个文档设置 routing 参数。
    bulk API, 允许在单个批量请求中执行多个创建、索引、删除和更新请求。
    bulk API 按如下步骤顺序执行:
  3. 客户端向 Node 1 发送 bulk 请求。
  4. Node 1 为每个节点创建一个批量请求,并将这些请求并行转发到每个包含主分片的节
    点主机。
  5. 主分片一个接一个按顺序执行每个操作。当每个操作成功时,主分片并行转发新文档(或
    删除)到副本分片,然后执行下一个操作。 一旦所有的副本分片报告所有操作成功,
    该节点将向协调节点报告成功,协调节点将这些响应收集整理并返回给客户端。
    4.6 分片原理
    4.6.1 倒排索引
    4.6.3 动态更新索引
    通过增加新的补充索引来反映新近的修改,而不是直接重写整
    个倒排索引。每一个倒排索引都会被轮流查询到,从最早的开始查询完后再对结果进行合并。
    Elasticsearch 基于 Lucene, 这个 java 库引入了按段搜索的概念。 每一 段 本身都是一
    个倒排索引, 但索引在 Lucene 中除表示所有段的集合外, 还增加了提交点的概念 — 一
    个列出了所有已知段的文件
    按段搜索会以如下流程执行:
  6. 新文档被收集到内存索引缓存
  7. 不时地, 缓存被 提交
    (1) 一个新的段—一个追加的倒排索引—被写入磁盘。
    (2) 一个新的包含新段名字的 提交点 被写入磁盘
    (3) 磁盘进行 同步 — 所有在文件系统缓存中等待的写入都刷新到磁盘,以确保它们
    被写入物理文件
  8. 新的段被开启,让它包含的文档可见以被搜索
  9. 内存缓存被清空,等待接收新的文档

当一个查询被触发,所有已知的段按顺序被查询。词项统计会对所有段的结果进行聚合,以
保证每个词和每个文档的关联都被准确计算。 这种方式可以用相对较低的成本将新文档添
加到索引。

段是不可改变的,所以既不能从把文档从旧的段中移除,也不能修改旧的段来进行反映文档
的更新。 取而代之的是,每个提交点会包含一个 .del 文件,文件中会列出这些被删除文档
的段信息。
当一个文档被 “删除” 时,它实际上只是在 .del 文件中被 标记 删除。一个被标记删除的
文档仍然可以被查询匹配到, 但它会在最终结果被返回前从结果集中移除

文档更新也是类似的操作方式:当一个文档被更新时,旧版本文档被标记删除,文档的新版
本被索引到一个新的段中。 可能两个版本的文档都会被一个查询匹配到,但被删除的那个
旧版本文档在结果集返回前就已经被移除。
4.6.4 近实时搜索(*)
随着按段(per-segment)搜索的发展,一个新的文档从索引到可被搜索的延迟显著降低
了。新文档在几分钟之内即可被检索,但这样还是不够快。磁盘在这里成为了瓶颈。提交
(Commiting)一个新的段到磁盘需要一个 fsync 来确保段被物理性地写入磁盘,这样在断
电的时候就不会丢失数据。 但是 fsync 操作代价很大; 如果每次索引一个文档都去执行一
次的话会造成很大的性能问题。

我们需要的是一个更轻量的方式来使一个文档可被搜索,这意味着 fsync 要从整个过程中
被移除。在 Elasticsearch 和磁盘之间是文件系统缓存。 像之前描述的一样, 在内存索引缓冲区中的文档会被写入到一个新的段中。 但是这里新段会被先写入到文件系统缓存—这一步代价会比较低,稍后再被刷新到磁盘—这一步代价比较高。不过只要文件已经在缓存中, 就可以像其它文件一样被打开和读取了。

Lucene 允许新段被写入和打开—使其包含的文档在未进行一次完整提交时便对搜索可见。
这种方式比进行一次提交代价要小得多,并且在不影响性能的前提下可以被频繁地执行

在 Elasticsearch 中,写入和打开一个新段的轻量的过程叫做 refresh 。 默认情况下每个分
片会每秒自动刷新一次。这就是为什么我们说 Elasticsearch 是 近 实时搜索: 文档的变化
并不是立即对搜索可见,但会在一秒之内变为可见。

这些行为可能会对新用户造成困惑: 他们索引了一个文档然后尝试搜索它,但却没有搜到。
这个问题的解决办法是用 refresh API 执行一次手动刷新: /users/_refresh

尽管刷新是比提交轻量很多的操作,它还是会有性能开销。当写测试的时候, 手动刷新很有用,但是不要在生产环境下每次索引一个文档都去手动刷新。 相反,你的应用需要意识到 Elasticsearch 的近实时的性质,并接受它的不足。

并不是所有的情况都需要每秒刷新。可能你正在使用 Elasticsearch 索引大量的日志文件,
你可能想优化索引速度而不是近实时搜索, 可以通过设置 refresh_interval , 降低每个索
引的刷新频率
{
“settings”: {
“refresh_interval”: “30s”
}
}

4.6.5 持久化变更 (*)
如果没有用 fsync 把数据从文件系统缓存刷(flush)到硬盘,我们不能保证数据在断
电甚至是程序正常退出之后依然存在。为了保证 Elasticsearch 的可靠性,需要确保数据变
化被持久化到磁盘。在 动态更新索引,我们说一次完整的提交会将段刷到磁盘,并写入一
个包含所有段列表的提交点。Elasticsearch 在启动或重新打开一个索引的过程中使用这个提
交点来判断哪些段隶属于当前分片。

即使通过每秒刷新(refresh)实现了近实时搜索,我们仍然需要经常进行完整提交来确
保能从失败中恢复。但在两次提交之间发生变化的文档怎么办?我们也不希望丢失掉这些数
据。Elasticsearch 增加了一个 translog ,或者叫事务日志,在每一次对 Elasticsearch 进行
操作时均进行了日志记录

整个流程如下:

  1. 一个文档被索引之后,就会被添加到内存缓冲区,并且追加到了 translog
  2. 刷新(refresh)使分片每秒被刷新(refresh)一次:
    这些在内存缓冲区的文档被写入到一个新的段中,且没有进行 fsync 操作。
    这个段被打开,使其可被搜索
    内存缓冲区被清空
  3. 这个进程继续工作,更多的文档被添加到内存缓冲区和追加到事务日志
  4. 每隔一段时间—例如 translog 变得越来越大—索引被刷新(flush);一个新的 translog
    被创建,并且一个全量提交被执行
    所有在内存缓冲区的文档都被写入一个新的段。
    缓冲区被清空。
    一个提交点被写入硬盘。
    文件系统缓存通过 fsync 被刷新(flush)。
    老的 translog 被删除。

translog 提供所有还没有被刷到磁盘的操作的一个持久化纪录。当 Elasticsearch 启动的时
候, 它会从磁盘中使用最后一个提交点去恢复已知的段,并且会重放 translog 中所有在最
后一次提交后发生的变更操作。

translog 也被用来提供实时 CRUD 。当你试着通过 ID 查询、更新、删除一个文档,它会
在尝试从相应的段中检索之前, 首先检查 translog 任何最近的变更。这意味着它总是能够
实时地获取到文档的最新版本。

执行一个提交并且截断 translog 的行为在 Elasticsearch 被称作一次 flush
分片每 30 分钟被自动刷新(flush),或者在 translog 太大的时候也会刷新

你很少需要自己手动执行 flush 操作;通常情况下,自动刷新就足够了。这就是说,在
重启节点或关闭索引之前执行 flush 有益于你的索引。当 Elasticsearch 尝试恢复或重新打
开一个索引, 它需要重放 translog 中所有的操作,所以如果日志越短,恢复越快。

translog 的目的是保证操作不会丢失,在文件被 fsync 到磁盘前,被写入的文件在重启
之后就会丢失。默认 translog 是每 5 秒被 fsync 刷新到硬盘, 或者在每次写请求完成之
后执行(e.g. index, delete, update, bulk)。这个过程在主分片和复制分片都会发生。最终, 基
本上,这意味着在整个请求被 fsync 到主分片和复制分片的 translog 之前,你的客户端不会得到一个 200 OK 响应。

在每次请求后都执行一个 fsync 会带来一些性能损失,尽管实践表明这种损失相对较
小(特别是 bulk 导入,它在一次请求中平摊了大量文档的开销)。

但是对于一些大容量的偶尔丢失几秒数据问题也并不严重的集群,使用异步的 fsync
还是比较有益的。比如,写入的数据被缓存到内存中,再每 5 秒执行一次 fsync 。如果你
决定使用异步 translog 的话,你需要 保证 在发生 crash 时,丢失掉 sync_interval 时间段
的数据也无所谓。请在决定前知晓这个特性。如果你不确定这个行为的后果,最好是使用默
认的参数( “index.translog.durability”: “request” )来避免数据丢失。
4.6.6 段合并
由于自动刷新流程每秒会创建一个新的段 ,这样会导致短时间内的段数量暴增。而段
数目太多会带来较大的麻烦。 每一个段都会消耗文件句柄、内存和 cpu 运行周期。更重要
的是,每个搜索请求都必须轮流检查每个段;所以段越多,搜索也就越慢。

Elasticsearch 通过在后台进行段合并来解决这个问题。小的段被合并到大的段,然后这些大
的段再被合并到更大的段。

段合并的时候会将那些旧的已删除文档从文件系统中清除。被删除的文档(或被更新文档的
旧版本)不会被拷贝到新的大段中。
启动段合并不需要你做任何事。进行索引和搜索时会自动进行。

  1. 当索引的时候,刷新(refresh)操作会创建新的段并将段打开以供搜索使用。
  2. 合并进程选择一小部分大小相似的段,并且在后台将它们合并到更大的段中。这并不会
    中断索引和搜索
  3. 一旦合并结束,老的段被删除
    新的段被刷新(flush)到了磁盘。 ** 写入一个包含新段且排除旧的和较小的段
    的新提交点。
    新的段被打开用来搜索。
    老的段被删除。
    4.7 文档分析
    分析 包含下面的过程:
    将一块文本分成适合于倒排索引的独立的 词条
    将这些词条统一化为标准格式以提高它们的“可搜索性”,或者 recall
    分析器执行上面的工作。分析器实际上是将三个功能封装到了一个包里:
    字符过滤器
    首先,字符串按顺序通过每个 字符过滤器 。他们的任务是在分词前整理字符串。一个
    字符过滤器可以用来去掉 HTML,或者将 & 转化成 and。
    分词器
    其次,字符串被 分词器 分为单个的词条。一个简单的分词器遇到空格和标点的时候,
    可能会将文本拆分成词条。
    Token 过滤器
    最后,词条按顺序通过每个 token 过滤器 。这个过程可能会改变词条(例如,小写化
    Quick ),删除词条(例如, 像 a, and, the 等无用词),或者增加词条(例如,像 jump
    和 leap 这种同义词)。
    4.7.1 内置分析器
    Elasticsearch 还附带了可以直接使用的预包装的分析器。接下来我们会列出最重要的分
    析器。
    标准分析器
    简单分析器
    空格分析器
    语言分析器
    特定语言分析器可用于 很多语言。它们可以考虑指定语言的特点
    4.7.2 分析器使用场景
    4.7.3 测试分析器
    4.7.4 指定分析器
    有时候你想要一个字符串域就是一个字符串域—不使用分析,直接索引你传入的精确值,例如用户 ID 或者一个内部的状态域或标签。要做到这一点,我们必须手动指定这些域的映射
    4.7.5 IK 分词器
    下载地址为:
    https://github.com/medcl/elasticsearch-analysis-ik/releases/tag/v7.8.0
    将解压后的后的文件夹放入 ES 根目录下的 plugins 目录下,重启 ES 即可使用
    查询参数"analyzer":“ik_max_word”

GET http://localhost:9200/_analyze

{
“text”:“测试单词”,
“analyzer”:“ik_max_word”
}
ik_max_word:会将文本做最细粒度的拆分
ik_smart:会将文本做最粗粒度的拆分

ES 中也可以进行扩展词汇
我们需要做的就是使分词器识别到弗雷尔卓德也是一个词 语
首先进入 ES 根目录中的 plugins 文件夹下的 ik 文件夹,进入 config 目录,创建 custom.dic 文件,写入弗雷尔卓德。同时打开 IKAnalyzer.cfg.xml 文件,将新建的 custom.dic 配置其中, 重启 ES 服务器。
4.7.6 自定义分析器
你可以通过在一个适合你的特定数据的设置之中组合字符过滤器、分词器、词汇单
元过滤器来创建自定义的分析器。在 分析与分析器 我们说过,一个 分析器 就是在一个包
里面组合了三种函数的一个包装器, 三种函数按照顺序被执行
字符过滤器
分词器
词单元过滤器
4.8 文档处理
4.8.1 文档冲突
4.8.2 乐观并发控制
每个文档都有一个 _version(版本)号,当文档被修改时版本号递增。 Elasticsearch 使用这个 version 号来确保变更以正确顺序得到执行
4.8.3 外部系统版本控制
4.5 Kibana

第5章 Elasticsearch 集成
5.1 Spring Data 框架集成
5.2 Spark Streaming 框架集成
5.3 Flink 框架集成
第6章 Elasticsearch 优化
6.1 硬件选择
6.2 分片策略
6.2.1 合理设置分片数
一个分片并不是没有代价的。需要了解:
一个分片的底层即为一个 Lucene 索引,会消耗一定文件句柄、内存、以及 CPU 运转。
每一个搜索请求都需要命中索引中的每一个分片,如果每一个分片都处于不同的节点还好, 但如果
多个分片都需要在同一个节点上竞争使用相同的资源就有些糟糕了。
用于计算相关度的词项统计信息是基于分片的。如果有许多分片,每一个都只有很少的数据会导致很
低的相关度。

一般来说,我们遵循一些原则:
控制每个分片占用的硬盘容量不超过 ES 的最大 JVM 的堆空间设置(一般设置不超过 32G,参考下文 的 JVM 设置原则),因此,如果索引的总容量在 500G 左右,那分片大小在 16 个左右即可;当然,
最好同时考虑原则 2。
考虑一下 node 数量,一般一个节点有时候就是一台物理机,如果分片数过多,大大超过了节点数,
很可能会导致一个节点上存在多个分片,一旦该节点故障,即使保持了 1 个以上的副本,同样有可能
会导致数据丢失,集群无法恢复。所以, 一般都设置分片数不超过节点数的 3 倍。
主分片,副本和节点最大数之间数量,我们分配的时候可以参考以下关系:
节点数<=主分片数*(副本数+1)
6.2.2 推迟分片分配
6.3 路由选择
当我们查询文档的时候,Elasticsearch 如何知道一个文档应该存放到哪个分片中呢?它
其实是通过下面这个公式来计算出来:
shard = hash(routing) % number_of_primary_shards
routing 默认值是文档的 id,也可以采用自定义值,比如用户 id

不带 routing 查询
在查询的时候因为不知道要查询的数据具体在哪个分片上,所以整个过程分为 2 个步骤
分发:请求到达协调节点后,协调节点将查询请求分发到每个分片上。
聚合: 协调节点搜集到每个分片上查询结果,在将查询的结果进行排序,之后给用户返回结果。
带 routing 查询
查询的时候,可以直接根据 routing 信息定位到某个分配查询,不需要查询所有的分配,经
过协调节点排序。
向上面自定义的用户查询,如果 routing 设置为 userid 的话,就可以直接查询出数据来,
效率提升很多
6.4 写入速度优化
ES 的默认配置,是综合了数据可靠性、写入速度、搜索实时性等因素。实际使用时,
我们需要根据公司要求,进行偏向性的优化。
针对于搜索性能要求不高,但是对写入要求较高的场景,我们需要尽可能的选择恰当写
优化策略。综合来说,可以考虑以下几个方面来提升写索引的性能:
加大 Translog Flush ,目的是降低 Iops、Writeblock。
增加 Index Refresh 间隔,目的是减少 Segment Merge 的次数。
调整 Bulk 线程池和队列。
优化节点间的任务分布。
优化 Lucene 层的索引建立,目的是降低 CPU 及 IO。
6.4.1 批量数据提交
ES 提供了 Bulk API 支持批量操作,当我们有大量的写任务时,可以使用 Bulk 来进
行批量写入
6.4.2 优化存储设备
ES 是一种密集使用磁盘的应用,在段合并的时候会频繁操作磁盘,所以对磁盘要求较
高,当磁盘速度提升之后,集群的整体性能会大幅度提高
6.4.3 合理使用合并
Lucene 以段的形式存储数据。当有新的数据写入索引时,Lucene 就会自动创建一个新
的段。
随着数据量的变化,段的数量会越来越多,消耗的多文件句柄数及 CPU 就越多,查询
效率就会下降。
由于 Lucene 段合并的计算量庞大,会消耗大量的 I/O,所以 ES 默认采用较保守的策
略,让后台定期进行段合并
6.4.4 减少 Refresh 的次数
Lucene 在新增数据时,采用了延迟写入的策略,默认情况下索引的 refresh_interval 为
1 秒。
Lucene 将待写入的数据先写到内存中,超过 1 秒(默认)时就会触发一次 Refresh,
然后 Refresh 会把内存中的的数据刷新到操作系统的文件缓存系统中。
如果我们对搜索的实效性要求不高,可以将 Refresh 周期延长,例如 30 秒。
这样还可以有效地减少段刷新次数,但这同时意味着需要消耗更多的 Heap 内存。
6.4.5 加大 Flush 设置
Flush 的主要目的是把文件缓存系统中的段持久化到硬盘,当 Translog 的数据量达到
512MB 或者 30 分钟时,会触发一次 Flush。
index.translog.flush_threshold_size 参数的默认值是 512MB,我们进行修改。
增加参数值意味着文件缓存系统中可能需要存储更多的数据,所以我们需要为操作系统
的文件缓存系统留下足够的空间。
6.4.6 减少副本的数量
ES 为了保证集群的可用性,提供了 Replicas(副本)支持,然而每个副本也会执行分
析、索引及可能的合并过程,所以 Replicas 的数量会严重影响写索引的效率。
当写索引时,需要把写入的数据都同步到副本节点,副本节点越多,写索引的效率就越
慢。 如 果 我 们 需 要 大 批 量 进 行 写 入 操 作 , 可 以 先 禁 止 Replica 复 制 , 设 置 index.number_of_replicas: 0 关闭副本。在写入完成后,Replica 修改回正常的状态
6.5 内存设置
因为 ES 堆内存的分配需要满足以下两个原则:

  1. 不要超过物理内存的 50%:Lucene 的设计目的是把底层 OS 里的数据缓存到内存中。
    Lucene 的段是分别存储到单个文件中的,这些文件都是不会变化的,所以很利于缓存,同时操作系统也会把这些段文件缓存起来,以便更快的访问。
    如果我们设置的堆内存过大,Lucene 可用的内存将会减少,就会严重影响降低 Lucene 的全文本查询性能。

  2. 堆内存的大小最好不要超过 32GB:在 Java 中,所有对象都分配在堆上,然后有一个 Klass Pointer 指针指向它的类元数据。
    这个指针在 64 位的操作系统上为 64 位,64 位的操作系统可以使用更多的内存(2^64)。在 32 位的系统上为 32 位,32 位的操作系统的最大寻址空间为 4GB(2^32)。
    但是 64 位的指针意味着更大的浪费,因为你的指针本身大了。浪费内存不算,更糟糕的是,更大的指针在主内存和缓存器(例如 LLC, L1 等)之间移动数据的时候,会占用更多的带宽。
    最终我们都会采用 31 G 设置
    -Xms 31g
    -Xmx 31g
    假设你有个机器有 128 GB 的内存,你可以创建两个节点,每个节点内存分配不超过 32 GB。 也就是说不超过 64 GB 内存给 ES 的堆内存,剩下的超过 64 GB 的内存给 Lucene
    6.6 重要配置
    第7章 Elasticsearch 面试题 (*)

7.4 Elasticsearch 索引文档的流程?

协调节点默认使用文档 ID 参与计算(也支持通过 routing),以便为路由提供合适的分片:
shard = hash(document_id) % (num_of_primary_shards)

当分片所在的节点接收到来自协调节点的请求后,会将请求写入到 Memory Buffer,然后定时(默认 是每隔 1 秒)写入到 Filesystem Cache,这个从 Memory Buffer 到 Filesystem Cache 的过程就叫做 refresh;

当然在某些情况下,存在 Momery Buffer 和 Filesystem Cache 的数据可能会丢失,ES 是通过 translog 的机制来保证数据的可靠性的。其实现机制是接收到请求后,同时也会写入到 translog 中,当 Filesystem cache 中的数据写入到磁盘中时,才会清除掉,这个过程叫做 flush;

在 flush 过程中,内存中的缓冲将被清除,内容被写入一个新段,段的 fsync 将创建一个新的提交点,并将内容刷新到磁盘,旧的 translog 将被删除并开始一个新的 translog。

flush 触发的时机是定时触发(默认 30 分钟)或者 translog 变得太大(默认为 512M)时;
7.5 Elasticsearch 更新和删除文档的流程?

删除和更新也都是写操作,但是 Elasticsearch 中的文档是不可变的,因此不能被删除或者改动以展示其变更;

磁盘上的每个段都有一个相应的.del 文件。当删除请求发送后,文档并没有真的被删除,而是在.del文件中被标记为删除。该文档依然能匹配查询,但是会在结果中被过滤掉。当段合并时,在.del 文件中被标记为删除的文档将不会被写入新段。

在新的文档被创建时,Elasticsearch 会为该文档指定一个版本号,当执行更新时,旧版本的文档在.del文件中被标记为删除,新版本的文档被索引到一个新段。旧版本的文档依然能匹配查询,但是会在结果中被过滤掉。
7.6 Elasticsearch 搜索的流程?

搜索被执行成一个两阶段过程,我们称之为 Query Then Fetch;

在初始查询阶段时,查询会广播到索引中每一个分片拷贝(主分片或者副本分片)。 每个分片在本地执行搜索并构建一个匹配文档的大小为 from + size 的优先队列。PS:在搜索的时候是会查询Filesystem Cache 的,但是有部分数据还在 Memory Buffer,所以搜索是近实时的。

每个分片返回各自优先队列中 所有文档的 ID 和排序值 给协调节点,它合并这些值到自己的优先队列中来产生一个全局排序后的结果列表。

接下来就是取回阶段,协调节点辨别出哪些文档需要被取回并向相关的分片提交多个 GET 请求。每个分片加载并丰富文档,如果有需要的话,接着返回文档给协调节点。一旦所有的文档都被取回了,协调节点返回结果给客户端。

Query Then Fetch 的搜索类型在文档相关性打分的时候参考的是本分片的数据,这样在文档数量较少的时候可能不够准确,DFS Query Then Fetch 增加了一个预查询的处理,询问 Term 和 Document frequency,这个评分更准确,但是性能会变差。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值