ES（elasticsearch），基于Lucene的全文搜索工具，常用作关系型数据库查询优化方案、分布式log检索方案。而ES之所以快则是依赖于Lucene的倒排索引结构。
以下内容基于理论学习，未进行源码探究及搭建配置实践。
目录
一、倒排索引
正常的索引是先知道文章，再去文章里找关键词。倒排索引正好反过来，知道关键词，要找到包含该关键词的文章。
1. 分词（Term）
这种情况下，如果要想快速地检索到目标文章，则必须将文章分割成一个个关键字，再将关键词与文章建立索引关系。Elasticsearch里分词关键字称作term。
例：i am happy用elasticsearch标准分词器切分的关键字结果是i,am,happy
2. 倒排列表（posting list）
根据切分好的关键字，将关键字与包含该关键字的文档进行关联，组成的结构称为倒排列表，即倒排索引。
如文档doc1包含内容i am happy，文档doc2包含内容i am your father，拆解成的倒排列表如下：
| Term | Posting list |
| i | doc1(id:88), doc2(id:103), ... |
| am | doc1(id:88), doc2(id:103), ... |
| happy | doc1(id:88), ... |
| your | doc2(id:103), ... |
| father | doc2(id:103), ... |
Posting list存储的是文档id，然而一个文档有无数个关键词，这意味着一个文档id会在多个posting list中重复出现，所以如果不进行压缩，将会非常占用磁盘空间。
这里posting list是一个有序的整形数组，支持通过增量编码（delta-encode）这种方式进行压缩。
如posting list[88, 103, 150, 303, ...(1987结尾), 2048, 2100]，将id转换成相对前一个id增量值[88, 15, 47, 153, ..., 61, 52]。这个例子中每个id值都小于255，故每个id只需要1个字节（8bit）存储。
而为了进一步压缩，ES还会将增量编码后的posting list按最大256个文档一块拆分成块，再进一步对块进行位压缩。
3. Term Dictionary和Term Index
Term Dictionary是posting list的索引，使用B+树索引指向索引数据。Term Index则是Term Dictionary的索引，使用FST结构。两者与posting list的索引关系和存储位置如图：
全文索引几乎每个文档全文都是关键词（Term），故Term Dictionary将会特别庞大，放在内存中必定OOM，故存储在磁盘中。为解决磁盘io慢的问题，加入了Term Index对磁盘的Term Dictionary进行索引。Term Index是一颗FST结构的字典树，其不包含完整的term，而是使用term 的公共前缀做索引，类似单词表，按a开头找到abandon单词。
到这里可以看到ES（实际是Lucene）的倒排索引大概是个什么样子了：
实际上Term Dictionary在磁盘上存储时还用了公共前缀压缩，即a开头的abandon省去了a，只存储了bandon。
然后图跟网上所能找到的图差不多，也有个同样的弊病，就是没能体现出Term Index的FST结构对term后缀的共用，以及Term Dictionary的B+树结构在检索时是怎么起作用的。这一块还有待探究。
4. filter cache
ES对不涉及文档评分操作的filter过滤查询做的优化，缓存匹配结果，提升查询性能。其使用了对查询性能影响较小的Roaring Bitmaps位压缩算法。
学习借鉴：https://zhuanlan.zhihu.com/p/419863514
二、集群分工
1. 角色分工
常用节点的角色有master、data、coordinating
（1）master节点
主要负责集群中索引的创建、删除、节点发现以及数据的Rebalance等操作。
master角色功能节点：
ES分布式集群时，集群内一般有多个master节点，这时候会进行选举，推选出唯一的一个活跃的Master节点进行工作。
这里假设有7个master节点，突然有3个节点与active master失去网络连接，或产生高网络延迟，但3个节点间通信正常，active master会认为这3个节点宕机下线。同时这3个节点也会认为active master挂了，会发起重新选举，推选出另一个active master，这时候双master节点处于当选（活跃）状态，将导致集群调度异常。
这种集群多master活跃问题被称为脑裂。为防止脑裂问题的产生，一般配置master节点个数为奇数，设为N，配置参数discovery.zen.minimum_master_nodes=N/2+1，当发现master节点数大于等于minimum_master_nodes时才会发起master选举。即7个master节点，分割出来的3个失联的节点，由于3 < 7/2 + 1，节点数量不足，不足以重新发起选举，避免了脑裂现象。ES7以上已取消minimum_master_nodes参数，系统会自动做配置。
（2）Data节点
主要负责集群中数据的索引和检索，一般压力比较大。建议和Master节点分开，避免因为Data Node节点出问题影响到Master节点。
角色配置：node.roles: [data]
（3）Coordinating Node
该节点和检索应用创建连接、接受检索请求。ES默认所有节点均可作为协作节点。
如果要将节点作为专用协作节点，将该节点所有角色功能全部关闭即可。此时该节点不占用io、cpu和内存。
（4）角色组合示意
（5）单节点及简单集群
默认所有角色功能即可。
2. 分片与副本
（1）分片
在集群下，ES将数据按照一定的hash规则，将一份数据拆分成多个不同的分片，再打散分布到不同机器上分布式存储。
当发起数据检索时，ES根据文档id进行hash，计算出数据分布的分片，并向分片所在机器发起数据请求，最后将各分片返回数据进行汇总计算，返回计算结果。这解决了大数据量下单节点数据处理能力有限的问题。在创建索引时用户可以根据业务需要指定分片数。
（2）副本
主分片建立时，会根据设定建立指定数量的副本。副本一般分布在主分片所在机器以外的不同机器上。
数据查询请求发起时，会在主分片和副本做负载均衡，提高系统的吞吐量。若主分片丢失或所在机器宕机，会在副本之间重新筛选主分片，保证系统的可靠性。在创建索引时用户可以根据业务需要指定副本数。
（3）弊端
分片新建或数据更新时，如果副本过多，将会加大数据同步的性能开销。在机器节点较少，副本数量较多时，可能出现分片与副本数据集中分布于单台机器的现象，由于当台机器处理能力有限，可能达不到负载均衡的预期效果，甚至影响机器性能。分片同理。
3. 读写请求
写入：
读取：
node：机器节点
primary：主本
replica：副本
三、数据来源
1. Log
ES做log检索，数据的来源是elastic stack家族中的Logstash采集上报给elasticsearch的，或beats上报给Logstash再上报ES，再通过kibana可视化展示。
2. 业务查询
业务数据写库时，同步或异步写入ES，或检测数据库binlog，根据信息同步到 ES。
Binlog较为复杂，简单的方案是写库时往MQ丢一笔数据，等消费时同步ES。
以上内容仅基于理论学习，仅用于加深理解，可能存在不准确的地方。实际实现细节以源码及实战应用为准。
482
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
