ElasticSearch 适用场景

  1. 日志可视化 --ELK组合,方便查询定位业务问题
  2. 存储非结构化数据,有些场景存储复杂嵌套的关系类型,使用关系型数据库联合查询将会很繁琐,并且影响性能,这时ElasticSearch是个不错的选择。
  3. 全文搜索引擎,对于海量数据的准实时搜索场景,ES是个不错的选择

ElasticSearch的搜索过程

1、当索引一片文档时发生了什么

首先根据文档ID散列值选择一个主分片,并将文档发送给主分片,然后文档被发送到该主分片的所有副本进行索引,使得副本分片和主分片保持同步,副本分片可以服务于搜索请求,并在原主分片不可用时,升级为主分片。

kib 查看es的主分片 es查询分片数_字符串


2、搜索索引时发生了什么

搜索时,在索引的所有分片中进行查找,这些分片可以是主分片,也可以是副本分片,负载均衡,提升性能。接受请求的节点将请求转发到一组包含所有数据的分片,ES使用round-robin的轮询机制选择可用分片(主或副本分片),并将请求转发出去,然后从这些分片收集结果,然后将结果聚集在一起返回。

kib 查看es的主分片 es查询分片数_字符串_02

什么是分片

一个分片是lucence的索引,一个包含倒排索引的文件目录,倒排索引使得ES在不扫描所有文档的情况下,就能告诉你哪些文档包含特定的词条。

注:

1、也就是说一个ES 索引,包含多个分片,每个分片又是一个单独的Lucence索引

2、副本分片可以动态的增加和删除,主分片不可以

kib 查看es的主分片 es查询分片数_搜索_03

什么是倒排索引

Elasticsearch 使用一种称为 倒排索引 的结构,它适用于快速的全文搜索。一个倒排索引由文档中所有不重复词的列表构成,对于其中每个词,有一个包含它的文档列表。

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

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

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


kib 查看es的主分片 es查询分片数_搜索_04

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


kib 查看es的主分片 es查询分片数_搜索_05

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

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

  • 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 。

现在索引看上去像这样:


kib 查看es的主分片 es查询分片数_ElasticSearch_06

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

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