[ElasticSearch] ElasticSearch的初识与基本操作-海口c网

🌸个人主页:https://blog.csdn.net/2301_80050796?spm=1000.2115.3001.5343
🏵️热门专栏:
🧊 Java基本语法(97平均质量分)https://blog.csdn.net/2301_80050796/category_12615970.html?spm=1001.2014.3001.5482
🍕 Collection与数据结构 (93平均质量分)https://blog.csdn.net/2301_80050796/category_12621348.html?spm=1001.2014.3001.5482
🧀线程与网络(97平均质量分) https://blog.csdn.net/2301_80050796/category_12643370.html?spm=1001.2014.3001.5482
🍭MySql数据库(96平均质量分)https://blog.csdn.net/2301_80050796/category_12629890.html?spm=1001.2014.3001.5482
🍬算法(97平均质量分)https://blog.csdn.net/2301_80050796/category_12676091.html?spm=1001.2014.3001.5482
🍃 Spring(97平均质量分)https://blog.csdn.net/2301_80050796/category_12724152.html?spm=1001.2014.3001.5482
🎃Redis(97平均质量分)https://blog.csdn.net/2301_80050796/category_12777129.html?spm=1001.2014.3001.5482
🐰RabbitMQ(97平均质量分) https://blog.csdn.net/2301_80050796/category_12792900.html?spm=1001.2014.3001.5482
💻 项目总结(97平均质量分) https://blog.csdn.net/2301_80050796/category_12936070.html?spm=1001.2014.3001.5482
🎈JVM(97平均质量分) https://blog.csdn.net/2301_80050796/category_12976744.html?spm=1001.2014.3001.5482
感谢点赞与关注~~~

在这里插入图片描述

1. 倒排索引
- 1.1 正向索引
- 1.2 倒排索引
- - 1.3 正向和倒排
2. 基础概念
- 2.1 文档和字段
- 2.2 索引和映射
- 2.3 MySQL与elasticSearch
- 3. IK分词器
- 3.1 使用IK分词器
- 3.2 拓展字典
- 3.3 总结
4. 索引库操作
- 4.1 Mapping映射属性
- 4.2 索引库的CRUD
- - 4.2.1创建索引库和映射
  - 4.2.2 查询索引库
  - 4.2.3 修改索引库
  - 2.2.4 删除索引库
5. 文档操作
- 5.1 新增文档
- 5.2 查询文档
- 5.3 删除文档
- 5.4 修改文档
- - 5.4.1 全量修改
  - 5.4.2 局部修改
- 5.5 批处理

1. 倒排索引

elasticsearch之所以有如此高性能的搜索表现，正是得益于底层的倒排索引技术。那么什么是倒排索引呢？
倒排索引的概念是基于MySQL这样的正向索引而言的.

1.1 正向索引

我们先来回顾一下正向索引
例如我们有一张名为tb_goods的表:
在这里插入图片描述
其中的id字段已经创建了索引,由于索引底层采用了b+树结构,因此我们根据id搜索的速度会非常快,但是其他的字段,例如title,之在叶子结点上存在.
因此要根据title字段搜索的时候只能遍历树中的每一个叶子结点,判断title数据是否符合要求.
比如用户的sql语句为:

select * from tb_goods where title like '%手机%';

那搜索的大概流程如图:
在这里插入图片描述
说明:

检查到搜索条件为like '%手机%',需要找到title中包含手机的数据.
逐条遍历每行数据(每个叶子结点),比如第一次拿到id为1的数据.
判断数据中的title字段的值是否符合条件.
如果符合则放入结果集,不符合则丢弃.
回到步骤1

综上,根据id精确匹配时,可以走索引,查询效率较高,而当搜索条件为模糊匹配时,由于索引无法生效,导致从索引查询退化为全表扫描,效率很差.
因此,正向索引适合于根据搜索字段的精确搜索,不适合基于部分词条的模糊匹配.
而倒排索引恰好解决的就是根据部分词条模糊匹配的问题.

1.2 倒排索引

倒排索引中有两个非常重要的概念:

文档: 用来搜索的数据,其中的每一条数据就是一个文档,例如一个网页,一个商品信息.
词条: 对文档数据或者用户搜索数据,利用某种算法进行分词,得到的具备含义的词语就是词条.例如: 我是中国人,就可以分为,我,是,中国人.

创建倒排索引是对正向索引的一种特殊处理和应用,流程如下:

将每个文档的数据利用分词算法根据语义拆分,得到一个个词条
创建表,每行数据包括词条,词条所在文档id,位置等信息.
因为词条唯一性,可以给词条创建正向索引.

此时形成的这张以词条为索引的表,就是倒排索引表,两者对比如下:
在这里插入图片描述
倒排索引的搜索流程如下(搜索:华为手机为例),如图:

流程描述:

用户输入条件"华为手机"进行搜索.
对用户输入条件分词,得到词条: 华为,手机.
拿着词条在倒排索引查找(由于词条有索引,查询效率很高),即可得到包含词条的文档id: 1,2,3.
拿着文档id到正向索引中查找具体文档即可(由于id也有索引,查询效率也很高).

虽然要先查询倒排索引,再查询倒排索引,但是无论是词条,还是文档id都建立了索引,查询速度非常快,无需全表扫描.

1.3 正向和倒排

那么为什么一个叫做正向索引,一个叫做倒排索引呢?

正向索引是最传统的,根据id索引的方式,但根据词条查询时,必须先逐条获取每个文档,然后判断文档中是否包含所需要的词条,是根据文档找词条的过程.
而倒排索引则相反, 是先找到用户要搜索的词条,根据词条得到保护词条的文档id,然后根据id获取文档,是根据词条找文档的过程.

正向索引和倒排索引的查询结果恰好是反过来的.他两的优缺点如下:

正向索引优点:
- 可以给多个字段创建索引
- 根据索引字段搜索,查询速度非常快.
正向索引缺点:
- 根据非索引字段,或者索引字段中的部分词条查找时,只能全表扫描.
倒排索引优点:
- 根据词条搜索,模糊搜索时,速度非常快
倒排索引缺点:
- 只能给词条创建索引,而不是字段
- 无法根据字段做排序

2. 基础概念

elasticSearch中有很多独有的概念,与MySQL中略有差别,但是也有相似之处.

2.1 文档和字段

elasticSearch是面相文档存储的,可以是数据库中的一条商品数据,一个订单信息,文档数据会被序列化为json格式后存储在elasticSearch中:
在这里插入图片描述

{"id": 1,"title": "小米手机","price": 3499
}
{"id": 2,"title": "华为手机","price": 4999
}
{"id": 3,"title": "华为小米充电器","price": 49
}
{"id": 4,"title": "小米手环","price": 299
}

因此,原本数据库中的一行数据就是es中的一个json文档,而数据库中每行数据都包含很多列,这些列就转换为json文档中的字段.

2.2 索引和映射

随着业务的发展,需要在es中存储的文档也会越来越多,比如有商品的文档,用户的文档,订单文档等等:

在这里插入图片描述
所有文档都散乱存放显然非常混乱,也不方便管理.
因此,我们要将类型相同的文档集中在一起管理,称为索引(index).
例如:
商品索引

{"id": 1,"title": "小米手机","price": 3499
}{"id": 2,"title": "华为手机","price": 4999
}{"id": 3,"title": "三星手机","price": 3999
}

用户索引

{"id": 101,"name": "张三","age": 21
}{"id": 102,"name": "李四","age": 24
}{"id": 103,"name": "麻子","age": 18
}

订单索引

{"id": 10,"userId": 101,"goodsId": 1,"totalFee": 294
}{"id": 11,"userId": 102,"goodsId": 2,"totalFee": 328
}

所有用户文档,就可以组织在一起,称为用户的索引
所有商品的文档,可以组织在一起,称为商品的索引
所有订单的文档,可以组织在一起,称为订单的索引

因此,我们可以把索引当做是数据库中的表.就像我们上面那张图一样,把一张正向索引的表转换为了json数据,每个索引组织成一组json数据,即一张表.
数据库的表会有约束信息,用来定义表的结构,字段的名称,类型等信息,因此,索引库中就有映射(mapping),是索引中文档的字段约束信息,类似表的结构约束.

2.3 MySQL与elasticSearch

我们统一的把MySQL与elasticsearch的概念做一下对比:

MySQL	ElasticSearch	说明
Table	Index	索引(Index),就是文档的集合,类似于数据库的表(table)
Row	Document	文档(Document),就是一条一条的数据,类似于数据库的行(row),文档都是json格式
Column	Field	字段(Field),就是json文档中的字段,类似数据库中的列(Column)
Schema	Mapping	Mapping(映射)是索引中文档的约束,例如字段类型的约束,类似数据库的表结构(schema)
SQL	DSL	DSL是elasticSearch提供的json风格的请求语句,用来操作elasticSearch,实现CRUD

如图:
在这里插入图片描述
在企业中,往往是把两者结合使用:

对数据安全性要求较高的写操作,使用MySQL实现.
对查询性能要求较高的搜索需求,使用elasticSearch实现.
两者再基于某种方式,实现数据的同步,保证一致性.

在这里插入图片描述

3. IK分词器

ElasticSearch的关键就是倒排索引,而倒排索引依赖于对文档内容的分词,而分词则需要高效,精准的分词算法,IK分词器就是这样一个中文分词的算法.

3.1 使用IK分词器

IK分词器包含两种模式:

ik_smart: 智能语义切分
ik_max_word: 最细粒度切分

我们在kibana的devtools上来测试分词器,首先测试elasticSearch官方提供的标准分词器:

POST /_analyze
{"analyzer": "standard","text": "黑马程序员学习java太棒了"
}

结果如下:

{"tokens" : [{"token" : "黑","start_offset" : 0,"end_offset" : 1,"type" : "<IDEOGRAPHIC>","position" : 0},{"token" : "马","start_offset" : 1,"end_offset" : 2,"type" : "<IDEOGRAPHIC>","position" : 1},{"token" : "程","start_offset" : 2,"end_offset" : 3,"type" : "<IDEOGRAPHIC>","position" : 2},{"token" : "序","start_offset" : 3,"end_offset" : 4,"type" : "<IDEOGRAPHIC>","position" : 3},{"token" : "员","start_offset" : 4,"end_offset" : 5,"type" : "<IDEOGRAPHIC>","position" : 4},{"token" : "学","start_offset" : 5,"end_offset" : 6,"type" : "<IDEOGRAPHIC>","position" : 5},{"token" : "习","start_offset" : 6,"end_offset" : 7,"type" : "<IDEOGRAPHIC>","position" : 6},{"token" : "java","start_offset" : 7,"end_offset" : 11,"type" : "<ALPHANUM>","position" : 7},{"token" : "太","start_offset" : 11,"end_offset" : 12,"type" : "<IDEOGRAPHIC>","position" : 8},{"token" : "棒","start_offset" : 12,"end_offset" : 13,"type" : "<IDEOGRAPHIC>","position" : 9},{"token" : "了","start_offset" : 13,"end_offset" : 14,"type" : "<IDEOGRAPHIC>","position" : 10}]
}

我们看到,标准分词器只能一字一条,无法正确对中文做分词.
我们再此时IK分词器:

POST /_analyze
{"analyzer": "ik_smart","text": "黑马程序员学习java太棒了"
}

执行结果如下:

{"tokens" : [{"token" : "黑马","start_offset" : 0,"end_offset" : 2,"type" : "CN_WORD","position" : 0},{"token" : "程序员","start_offset" : 2,"end_offset" : 5,"type" : "CN_WORD","position" : 1},{"token" : "学习","start_offset" : 5,"end_offset" : 7,"type" : "CN_WORD","position" : 2},{"token" : "java","start_offset" : 7,"end_offset" : 11,"type" : "ENGLISH","position" : 3},{"token" : "太棒了","start_offset" : 11,"end_offset" : 14,"type" : "CN_WORD","position" : 4}]
}

3.2 拓展字典

随着互联网发展,“造词运动"越发频繁,出现了很多新词语,在原有的词汇列表中并不存在,比如"泰裤辣”,"嘤嘤嘤"等.
IK分词器无法对这些词汇分词,测试一下:

POST /_analyze
{"analyzer": "ik_max_word","text": "传智播客开设大学,真的泰裤辣！"
}

结果:

{"tokens" : [{"token" : "传","start_offset" : 0,"end_offset" : 1,"type" : "CN_CHAR","position" : 0},{"token" : "智","start_offset" : 1,"end_offset" : 2,"type" : "CN_CHAR","position" : 1},{"token" : "播","start_offset" : 2,"end_offset" : 3,"type" : "CN_CHAR","position" : 2},{"token" : "客","start_offset" : 3,"end_offset" : 4,"type" : "CN_CHAR","position" : 3},{"token" : "开设","start_offset" : 4,"end_offset" : 6,"type" : "CN_WORD","position" : 4},{"token" : "大学","start_offset" : 6,"end_offset" : 8,"type" : "CN_WORD","position" : 5},{"token" : "真的","start_offset" : 9,"end_offset" : 11,"type" : "CN_WORD","position" : 6},{"token" : "泰","start_offset" : 11,"end_offset" : 12,"type" : "CN_CHAR","position" : 7},{"token" : "裤","start_offset" : 12,"end_offset" : 13,"type" : "CN_CHAR","position" : 8},{"token" : "辣","start_offset" : 13,"end_offset" : 14,"type" : "CN_CHAR","position" : 9}]
}

可以看到,"传智博客"和"泰裤辣"都无法正确分词.
所以要想正确分词,IL分词器的词库也需要不断更新,IK分词器提供了扩展词汇的功能.

打开IK分词器config目录:

注意,如果采用在线安装的通过,默认是没有config目录的,需要把课前资料提供的IK下的config上传到对应的目录.
在IKAnalyzer.cfg.xml配置文件内容中添加:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
<properties><comment>IK Analyzer 扩展配置</comment><!--用户可以在这里配置自己的扩展字典 *** 添加扩展词典--><entry key="ext_dict">ext.dic</entry>
</properties>

在IK分词器的config目录新建一个ext.dic,可以参考config目录下复制一个配置文件进行修改.

传智播客
泰裤辣

重启elasticSearch
再次测试,可以发现"传智播客"和"泰裤辣"都正确分词了:

{"tokens" : [{"token" : "传智播客","start_offset" : 0,"end_offset" : 4,"type" : "CN_WORD","position" : 0},{"token" : "开设","start_offset" : 4,"end_offset" : 6,"type" : "CN_WORD","position" : 1},{"token" : "大学","start_offset" : 6,"end_offset" : 8,"type" : "CN_WORD","position" : 2},{"token" : "真的","start_offset" : 9,"end_offset" : 11,"type" : "CN_WORD","position" : 3},{"token" : "泰裤辣","start_offset" : 11,"end_offset" : 14,"type" : "CN_WORD","position" : 4}]
}

3.3 总结

分词器的作用是什么?

创建倒排索引时,对文档分词
用户搜索时,对输入的内容分词

IK分词器有几种模式:

ik_smart: 智能切分,粗粒度
ik_max_word: 最细切分,细粒度

IK分词器如何拓展词条? 如何停用词条?

利用config目录的IkAnalyzer.cfg.xml文件添加拓展字段和停用字典.
在词典中添加拓展词条或者停用词条

4. 索引库操作

Index就类似于数据库表,Mapping映射就类似表的结构,我们要向es中存储数据,必须先创建Index和Mapping

4.1 Mapping映射属性

Mapping是对索引库中文档的约束,常见的Mapping属性包括:

type: 字段数据类型,常见的简单类型有:
- 字符串: text(可分词的文本),keyword(精确值,例如: 品牌,国家,IP地址)
- 数值: long、integer、short、byte、double、float
- 布尔: boolean
- 日期: date
- 对象: object
Index: 是否创建索引,默认为true
analyzer: 使用那种分词器
properties: 该字段的子字段

例如下面的json文档:

{"age": 21,"weight": 52.1,"isMarried": false,"info": "黑马程序员Java讲师","email": "zy@itcast.cn","score": [99.1, 99.5, 98.9],"name": {"firstName": "云","lastName": "赵"}
}

对应的每个字段映射Mapping:
在这里插入图片描述

4.2 索引库的CRUD

由于ElasticSearch采用的是Restful风格的API,因此其请求的方式和路径相对都比较规范,而且请求参数也都采用JSON风格.
我们直接基于kibana的devTools来编写请求做测试,由于有语法提示,会非常方便.

4.2.1创建索引库和映射

基本语法:

请求方式: PUT
请求路径: /索引库名,可以自定义
请求参数: mapping映射

格式:

PUT /索引库名称
{"mappings": {"properties": {"字段名":{"type": "text","analyzer": "ik_smart"},"字段名2":{"type": "keyword","index": "false"},"字段名3":{"properties": {"子字段": {"type": "keyword"}}},// ...略}}
}

4.2.2 查询索引库

基本语法:

请求方式: GET
请求路径: /索引库名
请求参数: 无

格式:

GET /索引库名

4.2.3 修改索引库

倒排索引结构虽然不复杂,但是一旦数据结构改变(比如改变了分词器),就需要重新创建倒排索引,这简直是灾难, 因此索引库一旦创建,无法修改mapping.
虽然无法修改mapping中已有的字段,但是却允许添加新的字段到mapping中,因为不会对倒排索引产生影响,因此修改该索引库能做的就是向索引库中添加新字段,或者更新索引库的基础属性.

语法说明:

PUT /索引库名/_mapping
{"properties": {"新字段名":{"type": "integer"}}
}

2.2.4 删除索引库

语法:

请求方式: delete
请求路径: /索引库名
请求参数: 无

格式:

DELETE /索引库名

可以看到,对索引库的操作基本遵循Restful的风格,因此API接口非常统一,方便记忆.

5. 文档操作

有了索引库,接下来就可以向索引库中添加数据了.
ElasticSearch中的数据其实就是json风格的文档,操作文档自然保护增,删,改,查等几种常见的操作,我们分别来学习.

5.1 新增文档

语法:

POST /索引库名/_doc/文档id
{"字段1": "值1","字段2": "值2","字段3": {"子属性1": "值3","子属性2": "值4"},
}

5.2 查询文档

根据rest风格,新增是post,查询应该是get,不过查询一般都需要条件,这里我们把文档id带上.

GET /{索引库名称}/_doc/{id}

5.3 删除文档

使用删除delete请求,同样,需要根据id进行删除:
语法:

DELETE /{索引库名}/_doc/id值

5.4 修改文档

修改方式有两种方式:

全量修改: 直接覆盖原来的文档
局部修改: 修改文档中的部分字段

5.4.1 全量修改

全量修改是覆盖原来的文档,其本质是两部操作:

根据指定的id删除文档
新增一个相同的id文档

注意:== 如果根据id删除时,id不存在,第二部的新增也会执行,也就从修改变成了新增操作了==.
语法:

PUT /{索引库名}/_doc/文档id
{"字段1": "值1","字段2": "值2",// ... 略
}

5.4.2 局部修改

局部修改只是修改指定id匹配的文档中的部分字段.
语法:

POST /{索引库名}/_update/文档id
{"doc": {"字段名": "新的值",}
}

局部修改,由put变为post,_doc变为_update.

5.5 批处理

批处理采用post请求,基本语法如下:

POST _bulk
{ "index" : { "_index" : "test", "_id" : "1" } }
{ "field1" : "value1" }
{ "delete" : { "_index" : "test", "_id" : "2" } }
{ "create" : { "_index" : "test", "_id" : "3" } }
{ "field1" : "value3" }
{ "update" : {"_id" : "1", "_index" : "test"} }
{ "doc" : {"field2" : "value2"} }

Index代表新增操作(如果存在则覆盖)
- _index: 指定索引库名
- _id: 指定要操作的文档id
- { "field1" : "value1" }: 要新增的文档字段.
delete代表删除操作
- _index: 指定索引库名
- _id: 指定要操作的文档id
create代表新增操作(如果已存在则失败)
- _index: 指定索引库名
- _id: 指定要操作的文档id
update代表更新操作
- _index: 指定索引库名
- _id: 指定要操作的文档id
- { "doc" : {"field2" : "value2"} }: 要更新的文档字段.doc表示部分更新.