ElasticSearch 搜索原理，原来可以这样轻松上手

架构精进之路

发布于 2024-11-23 16:14:54

950

文章被收录于专栏：架构精进之路架构精进之路

提到Elasticsearch，做业务开发的同学是不是既陌生又熟悉呢？

说陌生，是因为它并不跟MySQL一样，天天拿来做存储查询数据用；

说熟悉，我们排查问题查询的ELK日志，文本分词检索等场景，好像又离不开它....

Elasticsearch 特别擅长处理各种各样的数据类型，不管是文本、数字，还是其他稀奇古怪的玩意儿，它就像一个超级收纳大师，把所有的数据都放在合适的位置，还能让你轻松地找到它们。

今天，我们就来一起揭开它搜索原理的神秘面纱吧~

摘要

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

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

内容

图解ElasticSearch

云上的集群

集群里的盒子

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

节点之间

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

索引里的小方块

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

Shard＝Lucene Index

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

Lucene是一个Full Text 搜索库（也有很多其他形式的搜索库），ElasticSearch是建立在Lucene之上的。接下来的故事要说的大部分内容实际上是ElasticSearch如何基于Lucene工作的。

图解Lucene

Mini索引——segment

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

Segment内部

有着许多数据结构

Inverted Index
Stored Fields
Document Values
Cache

最最重要的Inverted Index

Inverted Index主要包括两部分：

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

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

查询“the fury”

自动补全（AutoCompletion-Prefix）

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

昂贵的查找

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

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

问题的转化

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

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

解决拼写错误

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

Stored Field字段查找

当我们想要查找包含某个特定标题内容的文件时，Inverted Index就不能很好的解决这个问题，所以Lucene提供了另外一种数据结构Stored Fields来解决这个问题。本质上，Stored Fields是一个简单的键值对key-value。默认情况下，ElasticSearch会存储整个文件的JSON source。

Document Values为了排序，聚合

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

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

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

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

搜索发生时

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

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

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