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

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

版本

elasticsearch版本: elasticsearch-2.2.0

云上的集群

集群里的盒子

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

节点之间

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

索引里的小方块

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

Shard＝Lucene Index

一个ElasticSearch的Shard实质上是一个Lucene Index。这篇 ElasticSearch 具体应用教程，外部分享时被老大褒扬了

Lucene是一个Full Text 搜寻库（也有很多其余模式的搜寻库），ElasticSearch是建设在Lucene之上的。接下来的故事要说的大部分内容实际上是ElasticSearch如何基于Lucene工作的。超具体 116 页 Elasticsearch 实战文档！高清可下载

图解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，从而查找到与搜寻相干的文件内容。Elasticsearch 查问数据的工作原理是什么？

查问“the fury”

主动补全（AutoCompletion-Prefix）

如果想要查找以字母“c”结尾的字母，能够简略的通过二分查找（Binary Search）在Inverted Index表中找到例如“choice”、“coming”这样的词（Term）。ElasticSearch 亿级数据检索案例实战！

低廉的查找

如果想要查找所有蕴含“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也会将所有的信息做缓存，这大大提高了它的查问效率。
缓存的故事

当ElasticSearch索引一个文件的时候，会为文件建设相应的缓存，并且会定期（每秒）刷新这些数据，而后这些文件就能够被搜寻到。

随着工夫的减少，咱们会有很多segments，

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

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

举个栗子

有两个segment将会merge

这两个segment最终会被删除，而后合并成一个新的segment

这时这个新的segment在缓存中处于cold状态，然而大多数segment依然放弃不变，处于warm状态。

以上场景常常在Lucene Index外部产生的。

在Shard中搜寻

ElasticSearch从Shard中搜寻的过程与Lucene Segment中搜寻的过程相似。

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

须要留神的是：

1次搜寻查找2个shard ＝ 2次别离搜寻shard

对于日志文件的解决

当咱们想搜寻特定日期产生的日志时，通过依据工夫戳对日志文件进行分块与索引，会极大进步搜寻效率。

当咱们想要删除旧的数据时也十分不便，只需删除老的索引即可。

在上种状况下，每个index有两个shards

如何Scale

shard不会进行更进一步的拆分，然而shard可能会被转移到不同节点上

所以，如果当集群节点压力增长到肯定的水平，咱们可能会思考减少新的节点，这就会要求咱们对所有数据进行从新索引，这是咱们不太心愿看到的，所以咱们须要在布局的时候就思考分明，如何去均衡足够多的节点与有余节点之间的关系。

节点调配与Shard优化
  • 为更重要的数据索引节点，调配性能更好的机器
  • 确保每个shard都有正本信息replica

路由Routing

每个节点，每个都存留一份路由表，所以当申请到任何一个节点时，ElasticSearch都有能力将申请转发到冀望节点的shard进一步解决。

一个实在的申请

Query

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

Aggregation

依据作者进行聚合，失去top10的hits的top10作者的信息

申请散发

这个申请可能被散发到集群里的任意一个节点

上帝节点

这时这个节点就成为以后申请的协调者（Coordinator），它决定：

  • 依据索引信息，判断申请会被路由到哪个外围节点
  • 以及哪个正本是可用的
  • 等等
路由

在实在搜寻之前

ElasticSearch 会将Query转换成Lucene Query

而后在所有的segment中执行计算

对于Filter条件自身也会有缓存

但queries不会被缓存，所以如果雷同的Query反复执行，应用程序本人须要做缓存

所以，

  • filters能够在任何时候应用
  • query只有在须要score的时候才应用
返回

搜寻完结之后，后果会沿着上行的门路向上逐层返回。

起源：https://www.cnblogs.com/richa...