【ElasticSearch】ElasticSearch，kibana安装，索引，文档，类型，倒排索引

不念不忘少年蓝@ 2022-11-17 10:15 208阅读 0赞

> > 公众号上线啦！  
> > 搜一搜【国服冰】  
> > 使命：尽自己所能给自学后端开发的小伙伴提供一个少有弯路的平台  
> > 回复：国服冰，即可领取我为大家准备的资料，里面包含整体的Java学习路线，电子书，以及史上最全的面试题！

### ElasticSearch ###

*   *  一、ElasticSearch安装
     *  二、kibana安装
     *  三、ES核心概念
     *   *  1、索引
         *  2、文档
         *  3、类型
         *  4、倒排索引

1、什么是ElasticSearch？

`Elasticsearch`是一个基于`Lucene`的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于`RESTful web` 接口。`Elasticsearch`是用`Java`语言开发的，并作为`Apache`许可条款下的开放源码发布，是一种流行的企业级搜索引擎。`Elasticsearch`用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。

2、ElasticSearch有什么用？

*  分布式的搜索引擎和数据分析引擎
 *  全文检索，结构化检索，数据分析
 *  对海量数据进行近实时的处理

3、Elasticsearch的特点？

（1）可以作为一个大型分布式集群（数百台服务器）技术，处理`PB`级数据，服务大公司；也可以运行在单机上，服务小公司。

（2）`Elasticsearch`不是什么新技术，主要是将全文检索、数据分析以及分布式技术，合并在了一起，才形成了独一无二的ES。`lucene`（全文检索），商用的数据分析软件（也是有的），分布式数据库`（mycat）`。

（3）对用户而言，是开箱即用的，非常简单，作为中小型的应用，直接3分钟部署一下`ES`，就可以作为生产环境的系统来使用了，数据量不大，操作不是太复杂。

（4）数据库的功能面对很多领域是不够用的（事务，还有各种联机事务型的操作）；特殊的功能，比如全文检索，同义词处理，相关度排名，复杂数据分析，海量数据的近实时处理；`Elasticsearch`作为传统数据库的一个补充，提供了数据库所不能提供的很多功能。

## 一、ElasticSearch安装 ##

1、下载 [ElasticSearch 7.6.1][]

2、安装启动ElasticSearch head （需要有node.js环境）

下载 [ElasticSearch-head][]

启动：

npm install
    npm run start

解决跨域问题 配置 **elasticsearch.yml**：

http.cors.enabled: true
    http.cors.allow-origin: "*"

重启`elasticserach`服务

![elasticserach head][]

## 二、kibana安装 ##

1、什么是`Kibanna`？

`Kibana`是为`Elasticsearch`设计的开源分析和可视化平台。你可以使用 `Kibana` 来搜索，查看存储在 `Elasticsearch` 索引中的数据并与之交互。你可以很容易实现高级的数据分析和可视化，以图表的形式展现出来。

2、下载`kibana`

[kibana 7.6.1][]

3、访问 `http://localhost:5601/` ， 默认端口`5601`  
![Kibana][]

4、`Kibana`汉化，更改`kibana.yml`：

i18n.locale: "zh-CN"

更改配置文件后重启

## 三、ES核心概念 ##

> ElasticSearch是面向文档，关系型数据库与ElasticSearch对比，一切都是Json

<table> 
 <thead> 
  <tr> 
   <th>Relationl DB</th> 
   <th>ElasticSearch</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>数据库（DataBase）</td> 
   <td>索引（indices）</td> 
  </tr> 
  <tr> 
   <td>表（Tables）</td> 
   <td>Type</td> 
  </tr> 
  <tr> 
   <td>行（Rows）</td> 
   <td>Documents</td> 
  </tr> 
  <tr> 
   <td>字段（Columns）</td> 
   <td>Fileds</td> 
  </tr> 
 </tbody> 
</table>

物理设计：

`ElasticSearch`在后台把索引分成多个分片，每个分片可以在不同服务器中迁移

`ElasticSearch`一个人就是一只军队，默认的集群名字叫**elasticsearch**

![elasticsearch默认集群][elasticsearch]

逻辑设计：

一个索引类型中，包含多个文档，比如说`文档1`，`文档2`。当我们索引一篇文档时，可以通过这样的顺序找到它：`索引` =>`类型` =>`文档ID`，通过这个组合我们就能索引到某个具体的文档。 注意：`ID`不必是整数，实际上它是个字符串。

### 1、索引 ###

可理解为数据库，索引是映射类型的容器，`Elasticsearch`中的索引是一个非常大的文档集合。索引存储了映射类型中的字段和其他设置。然后他们被保存到了各个分片上。

> 物理设计：节点和分片 如何工作？

> 一个集群至少有一个节点，而一个节点就是一个`Elasticsearch`进程，节点可以有多个索引默认的，如果你创建一个索引，那么索引将会有5个分片（主分片），每一个分片会有一个副本（赋值分片）。

### 2、文档 ###

`es`是面向文档的，文档是`es`中可搜索的最小单位，`es`的文档由一个或多个字段组成，类似于关系型数据库中的一行记录，但`es`的文档是以`JSON`进行序列化并保存的，每个`JSON`对象由一个或多个字段组成，字段类型可以是布尔，数值，字符串、二进制、日期等数据类型。

`es`每个文档都有唯一的`id`,这个`id`可以由我们自己指定，也可以由`es`自动生成。

### 3、类型 ###

**类型是文档的逻辑容器**，就像关系型数据库，表格是行的容器。类型中对于字段的定义称为**映射**，比如`name`映射为字符串类型。文档是无模式的，它不需要有映射中定义的所有字段。

### 4、倒排索引 ###

> 一切设计都是为了提高搜索的性能

倒排索引`（Inverted Index）`也叫反向索引，有反向索引必有正向索引。通俗地来讲，正向索引是通过`key`找`value`，反向索引则是通过`value`找`key`。

例如，假设我们有两个文档，每个文档的 `content` 域包含如下内容：

> 1、The quick brown fox jumped over the lazy dog

> 2、Quick brown foxes leap over lazy dogs in summer

为了创建倒排索引，我们首先将每个文档的 `content` 域拆分成单独的 词（我们称它为 `词条` 或 `tokens` ），创建一个包含所有不重复词条的排序列表，然后列出每个词条出现在哪个文档。结果如下所示：

Term      Doc_1  Doc_2
    -------------------------
    Quick   |       |  X
    The     |   X   |
    brown   |   X   |  X
    dog     |   X   |
    dogs    |       |  X
    fox     |   X   |
    foxes   |       |  X
    in      |       |  X
    jumped  |   X   |
    lazy    |   X   |  X
    leap    |       |  X
    over    |   X   |  X
    quick   |   X   |
    summer  |       |  X
    the     |   X   |
    ------------------------

现在，如果我们想搜索 `quick brown` ，我们只需要查找包含每个词条的文档：

Term      Doc_1  Doc_2
    -------------------------
    brown   |   X   |  X
    quick   |   X   |
    ------------------------
    Total   |   2   |  1

两个文档都匹配，但是第一个文档比第二个匹配度更高。如果我们使用仅计算匹配词条数量的简单 ***相似性算法*** ，那么，我们可以说，对于我们查询的相关性来讲，第一个文档比第二个文档更佳。

但是，我们目前的倒排索引有一些问题：

*  `Quick` 和 `quick` 以独立的词条出现，然而用户可能认为它们是相同的词。
 *  `fox` 和 `foxes` 非常相似, 就像 `dog` 和 `dogs` ；他们有相同的词根。
 *  `jumped` 和 `leap`, 尽管没有相同的词根，但他们的意思很相近。他们是同义词。

使用前面的索引搜索 `+Quick +fox` 不会得到任何匹配文档。（记住，`+` 前缀表明这个词必须存在。）只有同时出现 `Quick` 和 `fox` 的文档才满足这个查询条件，但是第一个文档包含 `quick fox` ，第二个文档包含 `Quick foxes` 。

我们的用户可以合理的期望两个文档与查询匹配。我们可以做的更好。

如果我们将词条规范为标准模式，那么我们可以找到与用户搜索的词条不完全一致，但具有足够相关性的文档。例如：

*  `Quick` 可以小写化为 `quick` 。
 *  `foxes` 可以 *词干提取* 变为**词根的格式**为 `fox` 。类似的， `dogs` 可以为提取为 `dog` 。
 *  `jumped` 和 `leap` 是同义词，可以索引为相同的单词 `jump` 。

现在索引看上去像这样：

Term      Doc_1  Doc_2
    -------------------------
    brown   |   X   |  X
    dog     |   X   |  X
    fox     |   X   |  X
    in      |       |  X
    jump    |   X   |  X
    lazy    |   X   |  X
    over    |   X   |  X
    quick   |   X   |  X
    summer  |       |  X
    the     |   X   |  X
    ------------------------

这还远远不够。我们搜索 `+Quick +fox` *仍然* 会失败，因为在我们的索引中，已经没有 `Quick` 了。但是，如果我们对搜索的字符串使用与 `content` 域相同的标准化规则，会变成查询 `+quick +fox` ，这样两个文档都会匹配！

> 这非常重要。你只能搜索在索引中出现的词条，所以索引文本和查询字符串必须标准化为相同的格式。

[ElasticSearch 7.6.1]: https://mirrors.huaweicloud.com/elasticsearch/?C=N&O=D
[ElasticSearch-head]: https://github.com/mobz/elasticsearch-head
[elasticserach head]: /images/20221022/6163e63e188443d08ab55bd590356424.png
[kibana 7.6.1]: https://mirrors.huaweicloud.com/kibana/7.6.1/
[Kibana]: /images/20221022/5d641d37e898471c8c92533bf6f76f9a.png
[elasticsearch]: /images/20221022/d3f9b59308764802a18100ff699fa2f8.png