ElasticSearch 7.x with Springboot 2.3.x - 前言

这是ES应用系列分享的第一部分，目标是基于这几个分享结束，在工程中实际运用ES不再会有大的问题（不可能几篇分享看完就能解决所有问题，生产环境的挑战正是在于情况的复杂，这种复杂也正是乐趣所在）。

在分享中我们会掌握如下关键内容

• ES的一些基础知识及简单实现原理
• ES环境的搭建与准备（本分享基于Docker单节点）
• 如何在Kibana中对ES进行数据操作
• 如何在Springboot的项目中使用ES

对于完全没有相关知识基础的小伙伴们可以参考文档中的文档进行学习，ES提供的接口以及Springboot与Spring data elasticsearch所做的封装，大幅简化了应用的开发，让应用开发者可以更少关注底层，而将经历更多专注于进行业务的实现，节省下来的时间可以喝一个下午茶并思考如何创新。

环境与工具准备（可根据自己情况与差异替换）

环境/工具	备注
JDK 1.8
Intellij IDEA 202001 社区版	安装Spring Assistant插件
Docker Desktop Windows	使用docker比较方便。为了降低失败国内最好添加国内镜像库。
ES7.7.1 Docker 镜像	文档地址
Kibana7.7.1 Docker 镜像	版本必须与ES一样 文档地址
Springboot 2.3.1
Spring Data Elastic 4.0.1	pom文件不用专门声明版本号

前言

前言部分主要是一些基本概念的简单科普，已经掌握的小伙伴大可直接跳过，也欢迎对于其中的疏漏与不足进行指正。

全文检索

简单来讲，全文检索就是将数据的内容进行分析提取、重新组织，以新的规则进行存储，让用户能通过数据内容的关键字（或者说关键信息），通过内部的算法获取返回用户想要的数据。

这么一看可能有人会问，我在RDBMS使用LIKE关键字不也能有这样的效果吗？从结果来看确实如此，但是使用过LIKE的小伙伴都知道这样的性能是让人捉急的，那么全文技术又是如何解决这个问题的呢？

上面的谜题我们在接下来大概讲一下反向索引(倒排索引)后一并解密。

反向索引(Inverted index)

在讲概念之前，我们先来看一个例子，你听到一首歌，只记得一句歌词“淡黄的长裙”，然后在搜索引擎里面一搜，通过这一句歌词把这首歌找到了。

这样的场景虽然已经习以为常，但是细品，你细品，你在mysql或oracle里面设计数据库的时候，你会怎么设计？我们可能会把歌名、歌手做成索引，然后我们就能通过歌名、歌手名字快速找到这首歌了。但是这个“淡黄的长裙”好像是歌词。

如果把歌词建成索引？嗯？那样的话我估计DBA的内心是酱婶儿的

]

那这到底是怎么回事呢？新机子哇一直摸亿多姿，那就是全文检索与反向索引了，我们来看看如何做吧。

1. 一首歌有歌名和歌词，分别存入数据库；

2. 对歌词根据关键字进行分词，英文默认以空格进行分词，中文默认以一个一个汉字分词（实际应用中文不能以此为逻辑分词，可以使用新的分词器去分词）；

3. 对歌词分词后，针对歌词建立索引（体会一下，和RDBMS的不一样，将一个字段基于关键词建了索引，而不是针对整个字段），索引标注了该关键字出自哪首歌；

4. 到了这里，想一想是不是找到感觉了？领悟了？
   

5. 真的懂了吗？(是的)不，(我懂了)你不懂。没关系，下面我们来张数据存储到建立索引的简单的流程图帮助理解。

6. 

7. 用户输入想要检索的关键字；

8. 数据库对关键字进行词法分析与语法分析
   (这里面的知识很有趣也很专业，想要深入了解的小伙伴建议前往官网查看官方文档 ----> lucene)

9. 引擎根据关键字检索索引，再从索引库的文档链表获取对应文档ID；

10. 取出相应文档并根据相关度排序，最终返回结果集给到用户。
    

存储，词法分析、检索、相关度排序等知识，有兴趣的小伙伴请前往 官方文档 深入研究，这里不做展开。

到此为止，我想大家对全文检索与反向索引如何进行sao操作已经有个概念了，虽然不了解好像也不影响使用？不管怎么样，上面这段讲解装B装的还可以吧。

RESTful

我们为什么在这里强调一下RESTful呢？因为和ES交互，我们基本都是基于其接口进行交互的。
在日常工作中，很多小伙伴可能每天都在写接口，虽然是每天都在做的事，但是对于什么是接口什么是RESTful并没有概念，觉得就是提供一个http调用的地址，从结果上是没错的。那我们为什么还要在设计接口的时候去尽量遵从RESTful规范呢？我相信有小朋友的内心里在说，我的接口和这个RESTful有啥不一样？
我的接口和RESTful [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-oJwbnhMW-1592823978138)(https://timgsa.baidu.com/timg?image&quality=80&size=b9999_10000&sec=1592804210754&di=72d987f729bb1492cbccf9e419f2a490&imgtype=0&src=http%3A%2F%2Fb-ssl.duitang.com%2Fuploads%2Fitem%2F201804%2F09%2F20180409222150_LVRUE.thumb.224_0.jpeg)]

首先我们快速理解3个基础概念：

1. REST => Representational State Transfer, 表现层状态转化:

   1. Representational(表现层): 表现层是资源展现的具体形式，通过URI指向一个资源（数据、静态页面、图片），通过状态转换后进行呈现；
   2. State Transfer（状态转换）：用户在客户端输入一个车牌号，然后返回了该车牌号对应的下载地址、简单介绍、和一些截图。计算机处理用户输入，最终返回用户想要的资源的过程就是状态转换。

2. URI => Uniform Resource Identifier, 统一资源标识符：

   我们来看一段URI: cars/sw-331 , 这段URI指向了一个资源的位置，它不关注你要怎么展示它使用它，它就是告诉你这个资源在这里，剩下的你自己看着办。

1. HTTP基本交互方式：
   • GET: 获取资源
   • POST: 创建资源（注意幂等）
   • PUT: 更新资源（注意幂等）
   • DELETE: 删除资源（注意带上条件，保险一点禁用不指定具体资源的删除，至于是否需要幂等？都已经删了还存在反复鞭shi的可能性吗？）

在这里不对RESTful做太多扩展，虽然看到具体项目中很多使用的非最佳实践，后面可以再来一个关于RESTful的专门介绍，包括建议的实现方式、安全性、并发等等。

这里大家只要基本理解，我们在使用ES时，会通过不同的HTTP交互方式，通过RESTful的URL获取ES中的数据转换成我们想要的展示效果即可（特别是通过kibana操作时），这就像是一种共识，先记住就好。

ES与其他数据库的简单异同

这里我们从通俗的角度选了几个各自比较有代表性的，为什么是通俗的角度呢？因为严格的角度来说比如ES更偏向于搜索引擎，但是这里放在一起比较是从一般使用者的角度，就像透明性原则一样，你知道你用的是ES就好，ES帮你隔离和包装的底层，就假装视而不见吧。

• MYSQL: 关系型数据的代表，数据字段规整不经常变化，通过SQL进行数据操作，良好的持久化以及对事务的支持。（MYSQL也可以支持全文检索，有兴趣小伙伴可以自己研究）；

• MongoDB：NoSQL数据库的典型代表，是文档型数据库，没有严格的表结构，适合存储灵活变化的数据，但是这些数据不应该具有特别复杂的逻辑关系；

• Redis：KV内存数据库，高性能的读写，简单的基础数据结构，我们对其的使用应尽量保持简单整洁，不要将特别复杂的数据塞入其中，也不要依赖其处理复杂具有复杂逻辑关系的数据；

• Hbase：Hadoop的存储部件，良好的横向扩展使得其具备理论上无限扩展的容量，良好的分片与自我复制使得其能胜任大数据的处理，但是其列族存储的模式以及查询对key的依赖，以及Hadoop生态相对较重，都使得其更适合用于OLAP场景；

• TiDB：这是一个比较新也比较有趣的数据库，对MySQL有良好的支持，同时具备关系型数据库与非关系型数据库的一些特点，同时可用于OLTP与OLAP场景；

• ES：全文检索、反向索引，自动分片，但是其写入性能一般，占用资源比较厉害。

在一般项目中，用MySQL就可以，对于复杂项目，可能会基于不同场景选择不同数据库，这些数据库都很优秀，没有好坏，只是有不同的适用场景而已，在项目中可以酌情选择。

准备好学习什么情况下选用什么数据库了吗？

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NGh9Kjip-1592823978147)(https://ss1.bdstatic.com/70cFuXSh_Q1YnxGkpoWK1HF6hhy/it/u=1794551523,3031662900&fm=26&gp=0.jpg)]

但是什么时候用什么数据库不是这里的重点，我们将要开始对ES的安装与使用了。

参考文档

• ES 7.7

• Kibana 7.7

• Springboot 2.3

• Spring data elasticsearch 4.0.1