ElasticSearch架构原理

ElasticStack数据流#

ElasticSearch#

基本概念与MySQL的对比#

ElasticSearch	MySQL
Index	Database
Type (未来将删除)	Table
Document	Row
Field	Column
Mapping	Schema
Everything is indexed	Index
Query DSL	SQL
GET HTTP	SELECT
PUT HTTP	UPDATE

倒排索引#

倒排索引项#

• 文档_id；
• 词频TF：token在文档中出现的次数，用于相关性评分；
• 位置Position：token在文档中分词的位置，用于match_phrase类型的查询；
• 偏移量Offset：记录token开始和结束的位置，实现高亮显示。

创建倒排索引#

对文档内容进行分词，形成一个个token（可以理解为单词），保存token和文档_id之间的关系。

检索倒排索引#

先对检索内容进行分词（适用于match查询方法，term/terms查询不分词），然后在倒排索引中寻找匹配的token，最后返回token对应的文档以及根据文档中token匹配情况给出的评分score。

分词器Analyzer#

在Elasticsearch中可通过内置分词器实现分词，也可以按需定制分词器。
Analyzer由三部分组成：

• Character Filters：原始文本处理，它的作用是整理字符串。如去除HTML，或者将&转化为and；
• Tokenizer：按照规则切分为单词。比如whitespace的分词器在遇到空格和标点的时候，可能会将文本进行拆分；
• Token Filters：对切分单词加工，如小写（lowercase token filter）、删除a，and和the等stopwords（stop token filter），增加同义词（synonym token filter）等。

利用ElasticSearch提供的webAPI可以查看索引中某一字段field对文本text的分词策略：

POST /[index]/_analyze
{
  "field": [field],
  "text": [text]
}

建立索引和类型#

• 在Elasticsearch集群中，节点是对等的，节点间会通过自己的一些规则选取集群的Master，Master节点会负责集群状态信息的改变，并同步给其他节点。
• 建立索引和类型的请求先发送到Master节点，Master建立完索引后，将集群状态同步至Slave节点。
• 只有建立索引和类型需要经过Master节点，数据的写入有一个简单的Routing规则，可以Route到集群中的任意节点，所以数据写入压力是分散在整个集群的。

分片内文档写入流程#

• In-memory Buffer
  在主分片节点上，文档会先被写入到内存（In-memory Buffer）中，此时数据还不能被搜索到。

• Refresh
  经过一段时间（refresh_interval）或者内存缓冲满了，Elasticsearch会将内存中的文档Refresh到文件系统缓存（Filesystem Cache）中，并清除内存中的对应文档。

• Filesystem Cache
  文档在文件系统缓存中被解析为Lucene的底层文件Segment中，同时建立倒排索引。这个时候文档是可以被搜索到的，因此减少了后续写入磁盘的大量时间，体现了Elasticsearch搜索的实时性（下图中的绿色和灰色图标分别代表已写入磁盘和未写入磁盘的文档）。
  

• Segment
  Lucene把每次生成的倒排索引，叫做一个段(Segment)，它无法被修改，只能被合并和删除。另外使用一个Commit文件，记录索引内所有的Segment。由于每次打开一个Segment就会消耗一个文件句柄，随着Segment越来越多，将导致查询性能越来越差。这时，ElasticSearch后台会有一个单独线程专门合并Segment，将零碎的小的Segment合并成一个大的Segment。
  
  

• Flush
  将Segment写入磁盘中，更新Commit文件并删除文档对应的Translog文件。

• Translog
  Elasticsearch在把数据写入到Index Buffer的同时，其实还另外记录了一个Translog日志。它是以顺序写文件的形式写入到磁盘中的，速度较快。如果发生异常，Elasticsearch会从Commit位置开始，恢复整个Translog文件中的记录，保证数据一致性。

多个分片的文档写入#

确定文档存储位置#

计算方式：

shard = hash(routing) % number_of_primary_shards

每个文档都有一个routing参数，默认情况下就使用其 _id 值。将其 _id 值计算哈希后，对索引的主分片数取余，就得到了文档实际应该存储到的分片。因此索引的主分片数不可以随意修改，一旦主分片数改变，所有文档的存储位置计算结果都会发生改变，索引数据就完全不可读了。

同步副本#

1. 客户端请求发送给Node 1节点，注意图中Node 1是Master节点，实际完全可以不是；
2. Node 1用文档的 _id 取余计算得到应该将数据存储到shard 0上。通过Cluster State信息发现shard 0的主分片已经分配到了Node 3上。Node 1转发请求数据给Node 3；
3. Node 3完成请求数据的索引过程，存入主分片 0。然后并行转发数据给分配有shard 0的副本分片的Node 1和Node 2。当收到任一节点汇报副本分片数据写入成功，Node 3即返回给初始的接收节点 Node 1，宣布数据写入成功。Node 1返回成功响应给客户端；
4. 当集群中某个节点宕机，该节点上所有分片中的数据全部丢失（既有主分片，又有副分片）。丢失的副分片对数据的完整性没有影响，丢失的主分片在其他节点上的副分片会被选举成主分片；所以整个索引的数据完整性没有被破坏。

注：图中P代表主分片（Primary Shard），R代表副本（Replica Shard）。

根据_id查询文档#

GET /[index]/_doc/[_id]

1. Elasticsearch集群中的任意节点都可以作为协调（Coordinating）节点接受请求，每个节点都知道集群中任一文档位置；
2. 协调节点对文档的_id进行路由，从而判断该数据在哪个Shard，然后将请求转发给对应的节点，此时会使用随机轮询算法，在Primary Shard和Replica Shard中随机选择一个，从而对请求负载均衡；
3. 处理请求的节点返回文档给协调节点；
4. 协调节点返回文档给客户端。

根据字段值检索数据#

GET /[index]/_search?q=[field]: [value]

1. Elasticsearch集群中的任意节点都可以作为协调（Coordinating）节点接受请求，每个节点都知道集群中任一文档位置；
2. 协调节点进行分词等操作后，向所有的shard节点发送检索请求；
3. ElasticSearch已建立字段的倒排索引，即可通过字段值检索到所在文档的_id。随后Shard将满足条件的数据（_id、排序字段等）信息返回给协调节点;
4. 协调节点将数据重新进行排序，获取到真正需要返回的文档的_id。协调节点再次向对应的Shard发起请求（此时已经有_id 了，可以直接定位到对应的Shard）;
5. Shard将_id对应的文档的完整内容返回给协调节点；
6. 协调节点获取到全部检索结果，返回给客户端。

上述流程和根据_id查询文档相比，只是多了一个从倒排索引中根据字段值寻找文档_id的过程，其中的4~6步与其完全相同。