整理：ES索引存储原理

Posted 2022-12-14 阿征new

ES索引存储原理

不变性

写到磁盘的倒序索引是不变的：自从写到磁盘就再也不变。 这会有很多好处：

不需要添加锁。不存在写操作，因此不存在多线程更改数据。
提高读性能。一旦索引被内核的文件系统做了Cache，绝大多数的读操作会直接从内存而不需要经过磁盘。
提升其他缓存（例如fiter cache）的性能。其他的缓存在该索引的生命周期内保持有效，减少磁盘I/O和计算消耗。

当然，索引的不变性也有缺点。如果你想让新修改过的文档可以被搜索到，你必须重新构建整个索引。这在一个index可以容纳的数据量和一个索引可以更新的频率上都是一个限制。

如何在不丢失不变形的好处下让倒序索引可以更改？答案是：使用不只一个的索引。 新添额外的索引来反映新的更改来替代重写所有倒序索引的方案。 Lucene引进了per-segment搜索的概念。一个segment是一个完整的倒序索引的子集，所以现在index在Lucene中的含义就是一个segments的集合，每个segment都包含一些提交点(commit point)。

segment工作流程

1.新的文档在内存中组织。
2.每隔一段时间，buffer将会被提交： 生成一个新的segment(一个额外的新的倒序索引)并被写到磁盘，同时一个
  新的提交点(commit point)被写入磁盘，包含新的segment的名称。 磁盘fsync，所有在内核文件系统中的数据等待被写入到磁盘，来保障它们被物理写入。
3.新的segment被打开，使它包含的文档可以被索引。
4.内存中的buffer将被清理，准备接收新的文档。

当一个新的请求来时，会遍历所有的segments。词条分析程序会聚合所有的segments来保障每个文档和词条相关性的准确。通过这种方式，新的文档轻量的可以被添加到对应的索引中。

删除和更新

segments是不变的，所以文档不能从旧的segments中删除，也不能在旧的segments中更新来映射一个新的文档版本。取之的是，每一个提交点都会包含一个.del文件，列举了哪一个segmen的哪一个文档已经被删除了。 当一个文档被”删除”了，它仅仅是在.del文件里被标记了一下。被”删除”的文档依旧可以被索引到，但是它将会在最终结果返回时被移除掉。

文档的更新同理：当文档更新时，旧版本的文档将会被标记为删除，新版本的文档在新的segment中建立索引。也许新旧版本的文档都会本检索到，但是旧版本的文档会在最终结果返回时被移除。

实时索引

在上述的per-segment搜索的机制下，新的文档会在分钟级内被索引，但是还不够快。 瓶颈在磁盘。将新的segment提交到磁盘需要fsync来保障物理写入。但是fsync是很耗时的。它不能在每次文档更新时就被调用，否则性能会很低。 现在需要一种轻便的方式能使新的文档可以被索引，这就意味着不能使用fsync来保障。 在ES和物理磁盘之间是内核的文件系统缓存。之前的描述中,在内存中索引的文档会被写入到一个新的segment。但是现在我们将segment首先写入到内核的文件系统缓存，这个过程很轻量，然后再flush到磁盘，这个过程很耗时。但是一旦一个segment文件在内核的缓存中，它可以被打开被读取。

更新持久化

不使用fsync将数据flush到磁盘，我们不能保障在断电后或者进程死掉后数据不丢失。ES是可靠的，它可以保障数据被持久化到磁盘。一个完全的提交会将segments写入到磁盘，并且写一个提交点，列出所有已知的segments。当ES启动或者重新打开一个index时，它会利用这个提交点来决定哪些segments属于当前的shard。 如果在提交点时，文档被修改会怎么样？

translog日志提供了一个所有还未被flush到磁盘的操作的持久化记录。当ES启动的时候，它会使用最新的commit point从磁盘恢复所有已有的segments，然后将重现所有在translog里面的操作来添加更新，这些更新发生在最新的一次commit的记录之后还未被fsync。

translog日志也可以用来提供实时的CRUD。当你试图通过文档ID来读取、更新、删除一个文档时，它会首先检查translog日志看看有没有最新的更新，然后再从响应的segment中获得文档。这意味着它每次都会对最新版本的文档做操作，并且是实时的。

Segment合并

通过每隔一秒的自动刷新机制会创建一个新的segment，用不了多久就会有很多的segment。segment会消耗系统的文件句柄，内存，CPU时钟。最重要的是，每一次请求都会依次检查所有的segment。segment越多，检索就会越慢。

ES通过在后台merge这些segment的方式解决这个问题。小的segment merge到大的，大的merge到更大的。。。

这个过程也是那些被”删除”的文档真正被清除出文件系统的过程，因为被标记为删除的文档不会被拷贝到大的segment中。

Segment：

Inverted Index

Inverted Index主要包括两部分：

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

Stored Fields：

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

Document Values

官网：https://www.elastic.co/guide/cn/elasticsearch/guide/current/docvalues.html#docvalues

即使这样，我们发现以上结构仍然无法解决诸如：排序、聚合、facet，因为我们可能会要读取大量不需要的信息。
所以，另一种数据结构解决了此种问题：Document Values。这种结构本质上就是一个列式的存储，它高度优化了具有相同类型的数据的存储结构。

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

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

Cache

当一个真实请求来的时候，如下所示：

存储索引的流程
从数据到索引，数据的流向如下：

数据生成索引存入内存Buffer，同时存入TranSlog
内存中的数据每隔一秒以segment的形式写入系统文件缓存
每隔一段时间，文件缓存中的数据存入硬盘，同时清除对应的translog

Lucene 工作流程

如何创建索引
找出文档

文件一：Students should be allowed to Go out with their friends, but not allowed to drink beer.

文件二：My friend Jerry went to school to see his students but found them drunk which is not allowed.

将原文档传给分次组件(Tokenizer)

分词组件(Tokenizer)会做以下几件事情( 此过程称为Tokenize) ：

将文档分成一个一个单独的单词。
去除标点符号。
去除停词(Stop word) 。
所谓停词(Stop word)就是一种语言中最普通的一些单词，由于没有特别的意义，因而大多数情况下不能成为搜索的关键词，因而创建索引时，这种词会被去掉而减少索引的大小。经过分词(Tokenizer) 后得到的结果称为词元(Token) 。
在我们的例子中，便得到以下词元(Token)：
“Students”，“allowed”，“go”，“their”，“friends”，“allowed”，“drink”，“beer”，“My”，“friend”，“Jerry”，“went”，“school”，“see”，

将得到的词元(Token)传给语言处理组件(Linguistic Processor)

语言处理组件(linguistic processor)主要是对得到的词元(Token)做一些同语言相关的处理。
对于英语，语言处理组件(Linguistic Processor) 一般做以下几点：

变为小写(Lowercase) 。
将单词缩减为词根形式，如“cars ”到“car ”等。这种操作称为：stemming 。
将单词转变为词根形式，如“drove ”到“drive ”等。这种操作称为：lemmatization 。
在我们的例子中，经过语言处理，得到的词(Term)如下：
“student”，“allow”，“go”，“their”，“friend”，“allow”，“drink”，“beer”，“my”，“friend”，“jerry”，“go”，“school”，“see”，“his”，“student”，“find”，“them

将得到的词(Term)传给索引组件(Indexer)

索引 组件(Indexer)主要做以下几件事情：

1. 利用得到的词(Term)创建一个字典。
2. 对字典按字母顺序进行排序。
3. 合并相同的词(Term) 成为文档倒排(Posting List) 链表。
4. 到此为止索引已经建好。

如何检索数据：

1. 用户输入查询语句
2. 对查询语句进行词法分析，语法分析，及语言处理
3. 词法分析主要用来识别单词和关键字。
4. 语法分析主要是根据查询语句的语法规则来形成一棵语法树。
5. 语言处理同索引过程中的语言处理几乎相同。
6. 如learned变成learn,tables 变成table等。
7. 搜索索引，得到符合语法树的文档。

此步骤有分几小步：

1. 首先，在反向索引表中，分别找出包含lucene，learn，hadoop的文档链表。
2. 其次，对包含lucene，learn的链表进行合并操作，得到既包含lucene又包含learn的文档链表。
3. 然后，将此链表与hadoop的文档链表进行差操作，去除包含hadoop的文档，从而得到既包含lucene又包含learn而且不包含hadoop的文档链表。

此文档链表就是我们要找的文档。

根据得到的文档和查询语句的相关性，对结果进行排序

1. 首先，一个文档有很多词(Term)组成
2. 其次对于文档之间的关系，不同的Term重要性不同
3. 找出词(Term) 对文档的重要性的过程称为计算词的权重(Term weight) 的过程。
4. 判断词(Term) 之间的关系从而得到文档相关性的过程应用一种叫做向量空间模型的算法

计算权重的过程：
影响一个词(Term)在一篇文档中的重要性主要有两个因素：

1. Term Frequency (tf)：即此Term在此文档中出现了多少次。tf 越大说明越重要。
2. Document Frequency (df)：即有多少文档包含次Term。df 越大说明越不重要。
    

这仅仅只term weight计算公式的简单典型实现。实现全文检索系统的人会有自己的实现，Lucene就与此稍有不同。

判断Term之间的关系从而得到文档相关性的过程，也即向量空间模型的算法(VSM)
我们把文档看作一系列词(Term)，每一个词(Term)都有一个权重(Term weight)，不同的词(Term)根据自己在文档中的权重来影响文档相关性的打分计算。

于是我们把所有此文档中词(term)的权重(term weight) 看作一个向量。

Document = term1, term2, …… ,term N

Document Vector = weight1, weight2, …… ,weight N

同样我们把查询语句看作一个简单的文档，也用向量来表示。

Query = term1, term 2, …… , term N

Query Vector = weight1, weight2, …… , weight N

我们把所有搜索出的文档向量及查询向量放到一个N维空间中，每个词(term)是一维。

我们认为两个向量之间的夹角越小，相关性越大。

所以我们计算夹角的余弦值作为相关性的打分，夹角越小，余弦值越大，打分越高，相关性越大。

有人可能会问，查询语句一般是很短的，包含的词(Term)是很少的，因而查询向量的维数很小，而文档很长，包含词(Term)很多，文档向量维数很大。你的图中两者维数怎么都是N呢？

在这里，既然要放到相同的向量空间，自然维数是相同的，不同时，取二者的并集，如果不含某个词(Term)时，则权重(Term Weight)为0。

举个例子，查询语句有11个Term，共有三篇文档搜索出来。其中各自的权重(Term weight)，如下.

于是文档二相关性最高，先返回，其次是文档一，最后是文档三。

到此为止，我们可以找到我们最想要的文档了。

总结

索引过程：

1) 有一系列被索引文件

2) 被索引文件经过语法分析和语言处理形成一系列词(Term) 。

3) 经过索引创建形成词典和反向索引表。

4) 通过索引存储将索引写入硬盘。

搜索过程：

a) 用户输入查询语句。

b) 对查询语句经过语法分析和语言分析得到一系列词(Term) 。

c) 通过语法分析得到一个查询树。

d) 通过索引存储将索引读入到内存。

e) 利用查询树搜索索引，从而得到每个词(Term) 的文档链表，对文档链表进行交，差，并得到结果文档。

f) 将搜索到的结果文档对查询的相关性进行排序。

g) 返回查询结果给用户。
————————————————
版权声明：本文为CSDN博主「guoyuguang0」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/guoyuguang0/article/details/76769184