[ElasticSearch] ElasticSearch的初识与基本操作

🌸个人主页: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表示部分更新.