内容
- 图解ElasticSearch
- 图解Lucene
- 搜索发生时
- 缓存的故事
- 在Shard中搜索
- 如何Scale
- 一个真实的请求
参考

摘要

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

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

版本

elasticsearch版本: elasticsearch-2.2.0

内容

图解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。