1.缘起：

为啥想学习es，主要是在工作中会用到，但是因为不了解原理，所以用起来畏手畏脚的，就想了解下es是怎么存储数据，以及es是怎么搜索数据的，我们平时应该如何使用es，以及使用时候需要注意的方面。
es:https://github.com/elastic/elasticsearch
lucene:https://github.com/apache/lucene.git

2.es的一些基础概念

es是一个基于lucence的分布式的搜索引擎，它使用java编写，并提供了一套RESTful api，是一款流行的企业级搜索引擎

2.1 es的特点

1. 横向可扩展性: 作为大型分布式集群, 很容易就能扩展新的服务器到ES集群中; 也可运行在单机上作为轻量级搜索引擎使用.
2. 更丰富的功能: 与传统关系型数据库相比, ES提供了全文检索、同义词处理、相关度排名、复杂数据分析、海量数据的近实时处理等功能.
3. 分片机制提供更好地分布性: 同一个索引被分为多个分片(Shard), 利用分而治之的思想提升处理效率.
4. 高可用: 提供副本(Replica)机制, 一个分片可以设置多个副本, 即使在某些服务器宕机后, 集群仍能正常工作.
5. 开箱即用: 提供简单易用的API, 服务的搭建、部署和使用都很容易操作.

2.2 es的重要概念

1.cluster(集群)
可以通过为多个节点配置同一个集群名来创建集群，通过elasticsearch.yml文件配置。
2.node(节点)
运行了单个es实例的主机被成为节点，一个集群里会包含一个或者多个节点。可以用来存储数据，搜索数据，操作数据。有三个主节点，三个数据节点。

3.shard(分片)
一个索引会分成多个分片，并存储在不同的节点中。每个shard都是一个最小工作单元，承载部分数据，对应一个lucene实例，具有完整的建立索引和处理请求的能力。shard分为primary shard和replica shard，其中replica shard 负责容错，以及承担读请求负载。一个document只会存在一个primary shard及其replica shard中，而不会存在于多个primary shard中。shards:5*2，表示有五个primary shard 以及五个replica shard。一旦创建完成，其primary shard的数量将不可更改。

4.index（索引）
一堆类型数据结构相同的document的集合。类似于数据库中的表
5.document( 文档)
es中的最小数据单元。比如一条纠纷单的数据，存在es中就是一个document。但是存储格式为json。类似于数据库中的一行数据。
6.type
类型，一个索引会存在一个或者多个 type，一个type下的document有相同的field。7.x后废弃
7.field
一个field就是一个数据字段
8.term
field的内容在经过analyze后，会被分词为term，是数据中最小的存储单位
9.数据库和es概念类比Elasticsearch 关系型数据库

3.es是如何存储数据的

3.1 es写入数据过程

1. 用户发送的请求会随机打到某一node，此时这个node为coordinate node
2. coordinate node通过路由策略找到对应的主分片 shard = hash(routing) % number_of_primary_shards，其中routing为docId，如果docId不存在，es会生成一个id来实现路由。主分片也会把请求转发到副本分片，实现数据备份。索引的primary shards在索引创建后不可更改也是因为路由策略，举个例子，对于同一个docId，原本存在primary shard 0 中，但是primary shard num修改后，就被路由到primary shard 3，这样就出现数据查不到的情况了。
3. 主分片&副本分片会构建索引以及将索引落盘

3.2 es近实时特性的原理

1. 写请求将数据写入buffer中，此时数据是不能被搜索到的，此时会同时将写操作记录在translog中，translog的落盘如果配置成同步，此时就会落盘，如果配置成异步，会在配置间隔时间进行落盘。
2. 默认1s一次的refresh操作，es会将buffer里的数据存入os cache中，并把buffer中的数据转化成segment，此时document便可以被搜索到了。每次refresh都会生成一个segment，es会定期进行segment合并。refresh数据到os cache后，buffer会被清空。
3. 每隔30min或者segment达到512M 后，会把os cache中的segment写入到磁盘中，这个过程叫做flush。此时会生成一个commit point文件，用来唯一标识该segment。执行flush操作时，会把buffer和os cache里的数据清空，此时translog也会被落盘。原有的translog会被删除，会在内存中创建一个新的translog。

3.3 segment的数据结构以及索引的原理

segment是lucene的概念，也是实现搜索的关键。名称 扩展名 简要描述
Term Dictionary .tim term词典，存储term信息
Term Index .tip 指向term词典的索引
Frequencies .doc 包含了有term的频率的文档列表
Positions .pos 存储了每个出现在索引中的term的位置信息
Payloads .pay 存储了额外的每一个位置的元数据信息如一个字符偏移和用户的负载
Field Index .fdx 包含field data的指针
Field Data .fdt 存储docs里的field表1 segment文件

其中和倒排索引相关的是.tim、.tip、.doc、.pos、.pay文件，而和正向索引相关的是.fdx、.fdt文件。下面先讲下倒排索引

3.3.1 lucene的倒排索引结构

倒排索引，其实从字面意义上很容易理解错，但是看英文就会好理解一些，inverted index，反向的索引。为什么称之为反向的索引，那应该有正向索引，正向索引指的是文档id和文档内容的映射关系，mysql的主键索引就是一个正向索引，而倒排索引，就是把这种对应关系颠倒，指的是，索引词（关键词）和文档之间的对应关系，即通过一个关键词，可以得到包含这个关键词的所有文档的文档id。

1. 通过对查询语句的解析，得到需要查找的term，找到该term对应的.tip文件和.tim文件。lucene会默认为每一个term都创建对应的索引
2. term index主要由FSTIndex和indexStartFP组成，FST(Finite State Transducer)有限状态转移机。我觉得可以理解为一个词语前缀索引。通过对前缀索引的搜索，就可以缩小搜索的范围，提高搜索的效率。
3. indexStartFPn里存的是FSTIndexn的地址， 为啥要存indexStartFPn，是因为每个FSTIndexn的大小不一样，为了节省存储空间，密集存储FSTIndexn，但是这样就没办法快速查找FSTIndexn。因此使用空间换时间，存下每个FSTIndexn的起始地址，而indexStartFP的大小都一样，这样就可以通过indexStartFPn进行二分查找了。
4. 通过term的前缀匹配定位到该term可能存在的block，此时就需要到.tim文件里去查找。可以看到.tim文件我们比较关注的是三部分。一是suffix；二是TermStats；三是TermsMetaData。其中suffix里存放的就是该term的后缀长度和suffix的内容。TermStats里包含的是该Term在文档中的频率以及所有 Term的频率，这部分是为了计算相关性。
5. 第三部分TermsMetaData里存放的是该Term在.doc、.pos、.pay中的地址。.doc文件中存放的是docId信息，包括这个term所在的docId、频率等信息。.pos文件里包含该term在每个文档里的位置。通过.tim文件里存放的这些地址，就可以去对应的文件里得出该term所在的文档id、位置、频率这些重要的信息了。

3.3.2 lucene的正向索引结构

通过倒排索引拿到的docId后，如何去拿到文档的其他字段信息，这时候就需要用到正向索引了

● fdt文件里每个chunk里包含压缩后的doc信息。fdx文件里存放的是每组chunk的起始地址
● fdx文件较小，直接加载到内存
● 通过fdx文件拿到对应的docid所在chunk的地址，再加载doc的数据信息。
● 通过正向索引拿到doc的数据类似于mysql里的回表操作

3.3.3 和mysql索引的对比

● 默认设置情况下 lucene会为doc里的每个term都创建对应的倒排、正向索引，而mysql只会为你指定的列创建索引，因此对于复杂查询场景，使用es来查询更合适，mysql无法构建索引覆盖所有的查询情况
● mysql的索引是存放在磁盘里的，检索时需要分页加载到内存再检索；lucene的.tip文件很小，可以直接放入内存，在检索时候，通过term index来快速定位到term可能存在的block。相当于给索引（词典表.tim文件）又建立了一层索引，查询效率更高

4.es是如何搜索数据的

1. 用户发送的搜索请求会随机达到任意一个node上，该node即为coordinate node。
2. coordinate node会将请求转发到该索引对应的所有的primary shard或者replica shard中
3. 每个shard处理query请求，通过lucene的搜索能力，将搜索结果返回给coordinate node
4. coordinate node将所有的结果处理后，根据排序要求取topk，再返回给client。

每一个分片中发生的搜索过程

1. 对用户的请求语句进行词法、语法分析，生成查询语法树，把文本请求转换为Lucene理解的请求对象
2. 按照查询语法树，搜索索引获取最终匹配的文档id集合
3. 对查询结果进行相关性排序，获取Top N的文档id集合，获取文档原始数据后返回用户
   5.一些关于es的使用思考
4. 对于复杂的查询场景，es查询优于mysql，对于实时性要求高，或需要实现事务操作的场景，需要使用mysql。
5. 由于es是通过查询所有分片，合并后再给出最终查询结果，所以也和mysql一样，需要注意深分页的问题，不过这块es已经做了限制，默认只返回前1w条的查询结果
6. 索引过大也会导致查询慢，可以从上面讲的索引结构看出，虽然term index是可以加载到内存的，但是最终的term dict也是存在磁盘里的，对于具体term的查询需要花费很多时间。此时可以考虑重建索引，使用更多的分片来存储/查询数据。
7. 尽可能地使用filter来代替query，query需要对查询结果进行相关性排序，而filter则不需要。