图解 ElasticSearch 原理

超、凢脫俗 2021-09-03 08:42 453阅读 0赞

点击上方 [Java后端][Java]，选择 设为星标

优质文章，及时送达

--------------------

> 来源：Richaaaard

Elasticsearch 是一款功能强大的开源分布式搜索与数据分析引擎，目前国内诸多互联网大厂都在使用，包括携程、滴滴、今日头条、饿了么、360 安全、小米、vivo 等。

除了搜索之外，结合 Kibana、Logstash、Beats，Elastic Stack 还被广泛运用在大数据近实时分析领域，包括日志分析、指标监控、信息安全等多个领域。

它可以帮助你探索海量结构化、非结构化数据，按需创建可视化报表，对监控数据设置报警阈值，甚至通过使用机器学习技术，自动识别异常状况。

今天，我们先自上而下，后自底向上的介绍ElasticSearch的底层工作原理，并试图回答以下问题：

*  为什么我的搜索 \*foo-bar\* 无法匹配 foo-bar ？
 *  为什么增加更多的文件会压缩索引（Index）？
 *  为什么 ElasticSearch 占用很多内存？

**图解 ElasticSearch**

**elasticsearch 版本: **elasticsearch-2.2.0。

#### **①云上的集群** ####

如下图：

![format_png][]

#### **②集群里的盒子** ####

云里面的每个白色正方形的盒子代表一个节点——Node。

![format_png 1][]

#### **③节点之间** ####

在一个或者多个节点直接，多个绿色小方块组合在一起形成一个 ElasticSearch 的索引。

![format_png 2][]

#### **④索引里的小方块** ####

在一个索引下，分布在多个节点里的绿色小方块称为分片——Shard。

![format_png 3][]

#### **⑤Shard＝Lucene Index** ####

一个 ElasticSearch 的 Shard 本质上是一个 Lucene Index。

![format_png 4][]

Lucene 是一个 Full Text 搜索库（也有很多其他形式的搜索库），ElasticSearch 是建立在 Lucene 之上的。

接下来的故事要说的大部分内容实际上是 ElasticSearch 如何基于 Lucene 工作的。

**图解 Lucene**

**Mini 索引：Segment**

在 Lucene 里面有很多小的 Segment，我们可以把它们看成 Lucene 内部的 mini-index。

![format_png 5][]

**Segment 内部**

![format_png 6][]

Segment 内部有着许多数据结构，如上图：

*  **Inverted Index**
 *  **Stored Fields**
 *  **Document Values**
 *  **Cache**

**最最重要的 Inverted Index**

如下图：

![format_png 7][]

Inverted Index 主要包括两部分：

*  一个有序的数据字典 Dictionary（包括单词 Term 和它出现的频率）。
 *  与单词 Term 对应的 Postings（即存在这个单词的文件）。

当我们搜索的时候，首先将搜索的内容分解，然后在字典里找到对应 Term，从而查找到与搜索相关的文件内容。

![format_png 8][]

##### **①查询“the fury”** #####

如下图：

![format_png 9][]

##### **②自动补全（AutoCompletion-Prefix）** #####

如果想要查找以字母“c”开头的字母，可以简单的通过二分查找（Binary Search）在 Inverted Index 表中找到例如“choice”、“coming”这样的词（Term）。

![format_png 10][]

##### **③昂贵的查找** #####

如果想要查找所有包含“our”字母的单词，那么系统会扫描整个 Inverted Index，这是非常昂贵的。

![format_png 11][]

在此种情况下，如果想要做优化，那么我们面对的问题是如何生成合适的 Term。

#####     #####

##### **④问题的转化** #####

如下图：

![format_png 12][]

对于以上诸如此类的问题，我们可能会有几种可行的解决方案：

*  \* suffix→xiffus \*，如果我们想以后缀作为搜索条件，可以为 Term 做反向处理。
 *  (60.6384, 6.5017)→ u4u8gyykk，对于 GEO 位置信息，可以将它转换为 GEO Hash。
 *  123→\{1-hundreds, 12-tens, 123\}，对于简单的数字，可以为它生成多重形式的 Term。

##### **⑤解决拼写错误** #####

#####     #####

一个 Python 库为单词生成了一个包含错误拼写信息的树形状态机，解决拼写错误的问题。

![format_png 13][]

#### **⑥Stored Field 字段查找** ####

####     ####

#### 当我们想要查找包含某个特定标题内容的文件时，Inverted Index 就不能很好的解决这个问题，所以 Lucene 提供了另外一种数据结构 Stored Fields 来解决这个问题。 ####

####     ####

#### 本质上，Stored Fields 是一个简单的键值对 key-value。默认情况下，ElasticSearch 会存储整个文件的 JSON source。 ####

![format_png 14][]

#### **⑦Document Values 为了排序，聚合** ####

####     ####

#### 即使这样，我们发现以上结构仍然无法解决诸如：排序、聚合、facet，因为我们可能会要读取大量不需要的信息。 ####

####     ####

#### 所以，另一种数据结构解决了此种问题：Document Values。这种结构本质上就是一个列式的存储，它高度优化了具有相同类型的数据的存储结构。 ####

![format_png 15][]

为了提高效率，ElasticSearch 可以将索引下某一个 Document Value 全部读取到内存中进行操作，这大大提升访问速度，但是也同时会消耗掉大量的内存空间。

总之，这些数据结构 Inverted Index、Stored Fields、Document Values 及其缓存，都在 segment 内部。

**搜索发生时**

搜索时，Lucene 会搜索所有的 Segment 然后将每个 Segment 的搜索结果返回，最后合并呈现给客户。

Lucene 的一些特性使得这个过程非常重要：

*  **Segments 是不可变的（immutable）：**Delete？当删除发生时，Lucene 做的只是将其标志位置为删除，但是文件还是会在它原来的地方，不会发生改变。
    
    Update？所以对于更新来说，本质上它做的工作是：先删除，然后重新索引（Re-index）。
 *  **随处可见的压缩：**Lucene 非常擅长压缩数据，基本上所有教科书上的压缩方式，都能在 Lucene 中找到。
 *  **缓存所有的所有：**Lucene 也会将所有的信息做缓存，这大大提高了它的查询效率。

**缓存的故事**

###     ###

### 当 ElasticSearch 索引一个文件的时候，会为文件建立相应的缓存，并且会定期（每秒）刷新这些数据，然后这些文件就可以被搜索到。 ###

![format_png 16][]

随着时间的增加，我们会有很多 Segments，如下图：

![format_png 17][]

所以 ElasticSearch 会将这些 Segment 合并，在这个过程中，Segment 会最终被删除掉。

![format_png 18][]

这就是为什么增加文件可能会使索引所占空间变小，它会引起 Merge，从而可能会有更多的压缩。

**举个栗子**

#### 有两个 Segment 将会 Merge： ####

![format_png 19][]

这两个 Segment 最终会被删除，然后合并成一个新的 Segment，如下图：

![format_png 20][]

这时这个新的 Segment 在缓存中处于 Cold 状态，但是大多数 Segment 仍然保持不变，处于 Warm 状态。

以上场景经常在 Lucene Index 内部发生的，如下图：

![format_png 21][]

**在 Shard 中搜索**

###     ###

### ElasticSearch 从 Shard 中搜索的过程与 Lucene Segment 中搜索的过程类似。 ###

![format_png 22][]

与在 Lucene Segment 中搜索不同的是，Shard 可能是分布在不同 Node 上的，所以在搜索与返回结果时，所有的信息都会通过网络传输。

**需要注意的是：**1 次搜索查找 2 个 Shard＝2 次分别搜索 Shard。

![format_png 23][]

#### **对于日志文件的处理：**当我们想搜索特定日期产生的日志时，通过根据时间戳对日志文件进行分块与索引，会极大提高搜索效率。 ####

####     ####

#### 当我们想要删除旧的数据时也非常方便，只需删除老的索引即可。 ####

![format_png 24][]

在上种情况下，每个 Index 有两个 Shards。

**如何 Scale**

如下图：

![format_png 25][]

Shard 不会进行更进一步的拆分，但是 Shard 可能会被转移到不同节点上。

![format_png 26][]

所以，如果当集群节点压力增长到一定的程度，我们可能会考虑增加新的节点，这就会要求我们对所有数据进行重新索引，这是我们不太希望看到的。

所以我们需要在规划的时候就考虑清楚，如何去平衡足够多的节点与不足节点之间的关系。

#### 节点分配与 Shard 优化： ####

*  为更重要的数据索引节点，分配性能更好的机器。
 *  确保每个 Shard 都有副本信息 Replica。

![format_png 27][]

#### **路由 Routing：**每个节点，每个都存留一份路由表，所以当请求到任何一个节点时，ElasticSearch 都有能力将请求转发到期望节点的 Shard 进一步处理。 ####

![format_png 28][]

**一个真实的请求**

如下图：

![format_png 29][]

#### **①Query** ####

####     ####

#### 如下图： ####

![format_png 30][]

Query 有一个类型 filtered，以及一个 multi\_match 的查询。

####     ####

#### **②Aggregation** ####

####     ####

#### 如下图： ####

![format_png 31][]

根据作者进行聚合，得到 top10 的 hits 的 top10 作者的信息。

####     ####

#### **③请求分发** ####

####     ####

#### 这个请求可能被分发到集群里的任意一个节点，如下图： ####

![format_png 32][]

#### **④上帝节点** ####

如下图：

![format_png 33][]

这时这个节点就成为当前请求的协调者（Coordinator），它决定：

*  根据索引信息，判断请求会被路由到哪个核心节点。
 *  以及哪个副本是可用的。
 *  等等。

#### **⑤路由** ####

如下图：

![format_png 34][]

#### **⑥在真实搜索之前** ####

####     ####

#### ElasticSearch 会将 Query 转换成 Lucene Query，如下图： ####

![format_png 35][]

然后在所有的 Segment 中执行计算，如下图：

![format_png 36][]

对于 Filter 条件本身也会有缓存，如下图：

![format_png 37][]

但 Queries 不会被缓存，所以如果相同的 Query 重复执行，应用程序自己需要做缓存。

![format_png 38][]

所以：

*  Filters 可以在任何时候使用。
 *  Query 只有在需要 Score 的时候才使用。

#### **⑦返回** ####

####     ####

#### 搜索结束之后，结果会沿着下行的路径向上逐层返回，如下图： ####

![format_png 39][] ![format_png 40][] ![format_png 41][] ![format_png 42][] ![format_png 43][]

- END -
    最近整理一份资料《Java技术学习手册》，覆盖了 Java技术、面试题精选、操作系统基础知识、计算机基础知识、Linux教程、计算机网络等等。获取方式：1. 扫描下方二维码 2. 关注 [逛逛GitHub] 后自动推送下载链接

[Java]: http://mp.weixin.qq.com/s?__biz=Mzg2MjEwMjI1Mg%3D%3D&chksm=ce0da17bf97a286df119047a25b7de51621fe542816673bb4aa3ebd8ab97b09a86ed7db2e2ee&idx=3&mid=2247489272&scene=21&sn=ce74938072fc73a808d83ccb474db46d#wechat_redirect
[format_png]: /images/20210730/9e066e8ef6654986a002d8c4eab7ec1a.png
[format_png 1]: /images/20210730/8879b2d8e7174bbd8521e6638c574f75.png
[format_png 2]: /images/20210730/706446ba6e5345ac8761de88a45ba354.png
[format_png 3]: /images/20210730/84f99ba71cfa4139bc5aef53314f9ef7.png
[format_png 4]: /images/20210730/c4d32fb1854344ba993f069b75a874da.png
[format_png 5]: /images/20210730/1cfee4b0c78e48c5945607b881bbc3be.png
[format_png 6]: /images/20210730/999f6abc52a249b79e5dde4b4c582148.png
[format_png 7]: /images/20210730/2cc37a1195f94cf59c74770cdfa46c97.png
[format_png 8]: /images/20210730/2ac6097b67704c3e91a98775f9999471.png
[format_png 9]: /images/20210730/781c5510d2d34b23ab5ca3307a4fb96c.png
[format_png 10]: /images/20210730/f12179ac0ded4802899991764d1a2e03.png
[format_png 11]: /images/20210730/72afd5326af44c86aded698b9b0f9637.png
[format_png 12]: /images/20210730/b25cb706a21248c99e7b580916a037a8.png
[format_png 13]: /images/20210730/8091e572967e4c7db5cbca5f5c152973.png
[format_png 14]: /images/20210730/75136b64b7494f48be4cdb0dded4c2fb.png
[format_png 15]: /images/20210730/3bad2375e45749478e42ec8592715b23.png
[format_png 16]: /images/20210730/ca9e0f59c8864c0488556b3a093637d0.png
[format_png 17]: /images/20210730/1d6372ef888f49dbac503d201831d014.png
[format_png 18]: /images/20210730/fffda3b2dfe245688d6a2ff957440285.png
[format_png 19]: /images/20210730/4a7b8c785e8d47a0ae90f133592b80ac.png
[format_png 20]: /images/20210730/1648ce1787784fcca880dce5f436f5bc.png
[format_png 21]: /images/20210730/7aabf7ef7a564ae8a774d22c4c33fe7a.png
[format_png 22]: /images/20210730/25d489e80b6844ab9af910fac5164990.png
[format_png 23]: /images/20210730/000ffdd50e41490bb5e4f48af84fecc7.png
[format_png 24]: /images/20210730/e7238fcd8df04483a684eca6e5bf9a5d.png
[format_png 25]: /images/20210730/c7c8bdef915e4b66b1d0232e342e624b.png
[format_png 26]: /images/20210730/69645bf261f44970881a75bd9e9de8a7.png
[format_png 27]: /images/20210730/b26159e4c95e41138d27a4629855fb67.png
[format_png 28]: /images/20210730/47d979a16d1b4a0a88fd8a2b200f97db.png
[format_png 29]: /images/20210730/79228fcd310543189d7bf77c0526f761.png
[format_png 30]: /images/20210730/cb2ffca20aaf41d4bba6877d1ea6628a.png
[format_png 31]: /images/20210730/2d27cbeeb0634ecaa9a533ca621c7219.png
[format_png 32]: /images/20210730/c64c29edcee940278203215be9e75b9a.png
[format_png 33]: /images/20210730/cf8d479aafb84e22909656a98234a8c4.png
[format_png 34]: /images/20210730/160f94de18b5441b842635f6854507f4.png
[format_png 35]: /images/20210730/05549bdf458a4b0eb9ab31949c90233f.png
[format_png 36]: /images/20210730/6efcc11806154285a16b1395cdc1c46a.png
[format_png 37]: /images/20210730/5918abe9669940b28d9db255909ef9b0.png
[format_png 38]: /images/20210730/456886c07f3141e7ae8734ed0fb8e116.png
[format_png 39]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X2pwZy9BNjZsQUFKMURYMlJubXc2NW5pYWJYOFJnUDVCQXZuMERpYTMzODhzRHdLcmliQmljSFVzNDRiTmNLS2NEbE9jUnN4dHBuNXVWVGx1SEFpYXViRGRCVlZuTGV3LzY0MA?x-oss-process=image/format,png
[format_png 40]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X2pwZy9BNjZsQUFKMURYMlJubXc2NW5pYWJYOFJnUDVCQXZuMER3RmczcmhrY1JPR2NSUTNOS0EyaWJaRFRZWDJvejQ5T2pMcmlhTDJ4aWJ2YkFtbWFYdVR3Wk9FZWcvNjQw?x-oss-process=image/format,png
[format_png 41]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X2pwZy9BNjZsQUFKMURYMlJubXc2NW5pYWJYOFJnUDVCQXZuMEQ4R1l3ZmVTMDRWZ0g4ZGJ5OG9INjBXRm56UjFrV3M0aDFLejZ4dzNaTUFTMkVEeHQxU0VrWWcvNjQw?x-oss-process=image/format,png
[format_png 42]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9tbWJpei5xcGljLmNuL21tYml6X2pwZy9BNjZsQUFKMURYMlJubXc2NW5pYWJYOFJnUDVCQXZuMERtQk5PMzBGaFFPTlZ2ZWFlcGJ0Q0R1ZEJlUk1aM2ljbll4Vnc3MkJnRjdweDFPZFdkQ2F1TXdBLzY0MA?x-oss-process=image/format,png
[format_png 43]: /images/20210730/d8a4864994e441b5904eafad7c7a576b.png