Elasticsearch中的一些概念整理：文档、类型、索引、倒排索引

╰半夏微凉° 2021-12-24 09:43 346阅读 0赞

# Elasticsearch中的一些概念整理 #

### 1. ES是什么？能干什么？ ###

Elasticsearch是一个实时分布式搜索和分析引擎。它让你以前所未有的速度处理大数据成为可能。

### 2. 一些名词解释 ###

*  文档：

Elasticsearch是面向文档(document oriented)的，这意味着它可以存储整个对象或文档(document)。然而它不仅仅是存储，还会索引(index，注意这里是动词的意思)每个文档的内容使之可以被搜索。在Elasticsearch中，你可以对文档（而非成行成列的数据）进行索引、搜索、排序、过滤。这种理解数据的方式与以往完全不同，这也是Elasticsearch能够执行复杂的全文搜索的原因之一。

*  索引：

在Elasticsearch中存储数据的行为就叫做索引(indexing, 动词)，不过在索引之前，我们需要明确数据应该存储在哪里，同样，存储在索引(indices, 名词)中。

> 「索引」含义的区分
> 
> 你可能已经注意到索引(index)这个词在Elasticsearch中有着不同的含义，所以有必要在此做一下区分:
> 
>  *  索引（名词） 如上文所述，一个索引(index)就像是传统关系数据库中的数据库，它是相关文档存储的地方，index的复数是indices 或indexes。
>  *  索引（动词） 「索引一个文档」表示把一个文档存储到索引（名词）里，以便它可以被检索或者查询。这很像SQL中的INSERT关键字，差别是，如果文档已经存在，新的文档将覆盖旧的文档。
>  *  倒排索引 传统数据库为特定列增加一个索引，例如B-Tree索引来加速检索。Elasticsearch和Lucene使用一种叫做倒排索引(inverted index)的数据结构来达到相同目的。

*  类型

文档归属于一种类型(type),而这些类型存在于索引(index)中，我们可以画一些简单的对比图来类比传统关系型数据库：

Relational DB -> Databases -> Tables -> Rows -> Columns
    Elasticsearch -> Indices   -> Types  -> Documents -> Fields

Elasticsearch集群可以包含多个索引(indices)（数据库），每一个索引可以包含多个类型(types)（表），每一个类型包含多个文档(documents)（行），然后每个文档包含多个字段(Fields)（列）。

*  分析

分析(analysis)是这样一个过程：  
首先， 标记化一个文本块为适用于倒排索引单独的词(term)  
然后标准化这些词为标准形式， 提高它们的“可搜索性”或“查全率”

要快速检索的字段，分析以后，生成倒排索引。检索的时候，输入的字符串也会经过同样规则的分析，这样可以提高“可搜索性”

### 3. 倒排索引 ###

Elasticsearch使用一种叫做倒排索引(inverted index)的结构来做快速的全文搜索。 倒排索引由在文档中出现的唯一的单词列表， 以及对于每个单词在文档中的位置组成。

例如， 我们有两个文档， 每个文档 content 字段包含：

1. The quick brown fox jumped over the lazy dog
    2. Quick brown foxes leap over lazy dogs in summer

为了创建倒排索引， 我们首先切分每个文档的 content 字段为单独的单词（ 我们把它们叫做词(terms)或者表征(tokens))， 把所有的唯一词放入列表并排序， 结果是这个样子的：(我的理解是按照ascII码顺序排序的，先大写字母再小写，从A-z, a-z)  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMwNDE2NDI_size_16_color_FFFFFF_t_70]  
现在， 如果我们想搜索 “quick brown” ， 我们只需要找到每个词在哪个文档中出现即可：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMwNDE2NDI_size_16_color_FFFFFF_t_70 1]  
两个文档都匹配， 但是第一个比第二个有更多的匹配项。 如果我们加入简单的相似度算法(similarity algorithm)， 计算匹配单词的数目， 这样我们就可以说第一个文档比第二个匹配度更高——对于我们的查询具有更多相关性。但是在我们的倒排索引中还有些问题：

1.  “Quick” 和 “quick” 被认为是不同的单词， 但是用户可能认为它们是相同的。
2.  “fox” 和 “foxes” 很相似， 就像 “dog” 和 “dogs” ——它们都是同根词。
3.  “jumped” 和 “leap” 不是同根词， 但意思相似——它们是同义词。

上面的索引中， 搜索 “+Quick +fox” 不会匹配任何文档（ 记住， 前缀 + 表示单词必须匹配到） 。 只有 “Quick” 和 “fox” 都在同一文档中才可以匹配查询， 但是第一个文档包含 “quick fox” 且第二个文档包含 “Quick foxes” .（ 说白了就是单复数和同义词没法匹配）用户可以合理地希望两个文档都能匹配查询， 我们也可以做得更好。  
如果我们将词为统一为标准格式， 这样就可以找到不是确切匹配查询， 但是足以相似从而可以关联的文档。 例如：

1.  “Quick” 可以转为小写成为 “quick” 。
2.  “foxes” 可以被转为根形式 “fox” 。 同理 “dogs” 可以被转为 “dog” 。
3.  “jumped” 和 “leap” 同义就可以只索引为单个词 “jump”

现在的索引：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMwNDE2NDI_size_16_color_FFFFFF_t_70 2]  
但我们还未成功。 我们的搜索 “+Quick +fox” 依旧失败， 因为 “Quick” 的确切值已经不在索引里， 不过， 如果我们使用相同的标准化规则处理查询字符串的 content 字段， 查询将变成 “+quick +fox” ， 这样就可以匹配到两个文档。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMwNDE2NDI_size_16_color_FFFFFF_t_70]: /images/20211223/27ec63ef76714638bb1b94581e3c7d05.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMwNDE2NDI_size_16_color_FFFFFF_t_70 1]: /images/20211223/61683d89b849488abccdfe8d1c4beae8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTMwNDE2NDI_size_16_color_FFFFFF_t_70 2]: /images/20211223/9eee1680d086457fbe9858b9caa8b896.png