ElasticSearch原理怎么就可以实现高亮搜索
1.介绍
Elasticsearch 是一个分布式可扩展的实时搜索和分析引擎,一个建立在全文搜索引擎 Apache Lucene™ 基础上的搜索引擎.当然 Elasticsearch 并不仅仅是 Lucene 那么简单，它不仅包括了全文搜索功能，还可以进行以下工作:
分布式实时文件存储，并将每一个字段都编入索引，使其可以被搜索。
实时分析的分布式搜索引擎。
可以扩展到上百台服务器，处理PB级别的结构化或非结构化数据。
2.基本概念
先说Elasticsearch的文件存储，Elasticsearch是面向文档型数据库，一条数据在这里就是一个文档，用JSON作为文档序列化的格式，比如下面这条用户数据：
{
“name” : “John”,
“sex” : “Male”,
“age” : 25,
“birthDate”: “1990/05/01”,
“about” : “I love to go rock climbing”,
“interests”: [ “sports”, “music” ]
}
用Mysql这样的数据库存储就会容易想到建立一张User表，有balabala的字段等，在Elasticsearch里这就是一个文档，当然这个文档会属于一个User的类型，各种各样的类型存在于一个索引当中。这里有一份简易的将Elasticsearch和关系型数据术语对照表:
关系数据库 ⇒ 数据库 ⇒ 表 ⇒ 行 ⇒ 列(Columns)
Elasticsearch ⇒ 索引(Index) ⇒ 类型(type) ⇒ 文档(Docments) ⇒ 字段(Fields)
一个 Elasticsearch 集群可以包含多个索引(数据库)，也就是说其中包含了很多类型(表)。这些类型中包含了很多的文档(行)，然后每个文档中又包含了很多的字段(列)。Elasticsearch的交互，可以使用Java API，也可以直接使用HTTP的Restful API方式，比如我们打算插入一条记录，可以简单发送一个HTTP的请求：
PUT /megacorp/employee/1
{
“name” : “John”,
“sex” : “Male”,
“age” : 25,
“about” : “I love to go rock climbing”,
“interests”: [ “sports”, “music” ]
}
更新，查询也是类似这样的操作，具体操作可以看官方文档
3.索引
es索引的精髓：
一切设计都是为了提高搜索的性能，即为了提高搜索的性能，会牺牲某些其他方面，如插入/更新。如es在插入一条记录时，其实就是PUT一个json对象，这个对象中有多个fields，在插入这些数据到es的同时，es会为这些字段建立索引-倒排索引。
Elasticsearch是如何做到快速索引的呢？
什么是B-Tree索引？
二叉树查找效率是logN，同时插入新的节点不必移动全部节点，所以用树型结构存储索引，能同时兼顾插入和查询的性能。因此在这个基础上，再结合磁盘的读取特性(顺序读/随机读)，传统关系型数据库采用了B-Tree/B+Tree这样的数据结构：
为了提高查询的效率，减少磁盘寻道次数，将多个值作为一个数组通过连续区间存放，一次寻道读取多个数据，同时也降低树的高度。
4.什么是倒排索引？
Elasticsearch分别为每个field都建立了一个倒排索引，Kate, John, 24, Female这些叫term，而[1,2]就是Posting List。Posting list就是一个int的数组，存储了所有符合某个term的文档id。通过posting list这种索引方式似乎可以很快进行查找，比如要找age=24的同学。
Term Dictionary
Elasticsearch为了能快速找到某个term，将所有的term排个序，二分法查找term，logN的查找效率，就像通过字典查找一样，这就是Term Dictionary。现在再看起来，似乎和传统数据库通过B-Tree的方式类似啊，那么为什么说比B-Tree的查询快呢？
Term Index
B-Tree通过减少磁盘寻道次数来提高查询性能，Elasticsearch也是采用同样的思路，直接通过内存查找term，不读磁盘，但是如果term太多，term dictionary也会很大，放内存不现实，于是有了Term Index，就像字典里的索引页一样，A开头的有哪些term，分别在哪页，可以理解term index是一颗树：
这棵树不会包含所有的term，它包含的是term的一些前缀。通过term index可以快速地定位到term dictionary的某个offset，然后从这个位置再往后顺序查找。
所以term index不需要存下所有的term，而仅仅是他们的一些前缀与Term Dictionary的block之间的映射关系，再结合FST(Finite State Transducers)的压缩技术，可以使term index缓存到内存中。从term index查到对应的term dictionary的block位置之后，再去磁盘上找term，大大减少了磁盘随机读的次数。
假设我们现在要将mop, moth, pop, star, stop and top(term index里的term前缀)映射到序号：0，1，2，3，4，5(term dictionary的block位置)。最简单的做法就是定义个Map，大家找到自己的位置对应入座就好了，但从内存占用少的角度想想，还有没有更优的方法呢？答案是：FST。
⭕️ 表示一种状态
–> 表示状态的变化过程，上面的字母/数字表示状态变化和权重
将单词分成单个字母通过⭕️和–>表示出来，0权重不显示。如果⭕️后面出现分支，就标记权重，最后整条路径上的权重加起来就是这个单词对应的序号。
FST以字节的方式存储所有的term，这种压缩方式可以有效的缩减存储空间，使得term index足以放进内存，但这种方式也会导致查找时需要更多的CPU资源。
5.设计阶段调优
1）根据业务增量需求，采取基于日期模板创建索引，通过roll over API滚动索引；
2）使用别名进行索引管理；
3）每天凌晨定时对索引做force_merge操作，以释放空间；
4）采取冷热分离机制，热数据存储到SSD，提高检索效率；冷数据定期进行shrink操作，以缩减存储；
5）采取curator进行索引的生命周期管理；
6）仅针对需要分词的字段，合理的设置分词器；
7）Mapping阶段充分结合各个字段的属性，是否需要检索、是否需要存储等。 …
6.写入调优
1）写入前副本数设置为0；
2）写入前关闭refresh_interval设置为-1，禁用刷新机制；
3）写入过程中：采取bulk批量写入；
4）写入后恢复副本数和刷新间隔；
5）尽量使用自动生成的id。
1.3、查询调优
1）禁用wildcard；
2）禁用批量terms（成百上千的场景）；
3）充分利用倒排索引机制，能keyword类型尽量keyword；
4）数据量大时候，可以先基于时间敲定索引再检索；
5）设置合理的路由机制。
也可以部署调优，业务调优等。*
7.elasticsearch 索引数据多了怎么办，如何调优，部署？
面试官 ：想了解大数据量的运维能力。 解答 ：索引数据的规划，应在前期做好规划，正所谓“设计先行，编码在
后”，这样才能有效的避免突如其来的数据激增导致集群处理能力不足引发的线上客户检索或者其他业务受到影
响。 如何调优，这里细化一下：
7.1 动态索引层面
基于 模板+时间+rollover api滚动 创建索引，举例：设计阶段定义：blog索引的模板格式为：blog_index_时间戳
的形式，每天递增数据。
这样做的好处：不至于数据量激增导致单个索引数据量非常大，接近于上线2的32次幂-1，索引存储达到了TB+甚
至更大。
一旦单个索引很大，存储等各种风险也随之而来，所以要提前考虑+及早避免。
7…2 存储层面
冷热数据分离存储 ，热数据（比如最近3天或者一周的数据），其余为冷数据。 对于冷数据不会再写入新数据，可
以考虑定期force_merge加shrink压缩操作，节省存储空间和检索效率。
7.3 部署层面
一旦之前没有规划，这里就属于应急策略。
结合ES自身的支持动态扩展的特点，动态新增机器的方式可以缓解集群压力，注意：如果之前主节点等 规划合
理 ，不需要重启集群也能完成动态新增的。
8.Elasticsearch在部署时，对Linux的设置有哪些优化方法？
1）关闭缓存swap;
2）堆内存设置为：Min（节点内存/2, 32GB）;
3)设置最大文件句柄数；
4）线程池+队列大小根据业务需要做调整；
5）磁盘存储raid方式——存储有条件使用RAID10，增加单节点性能以及避免单节点存储故障。
9.Elasticsearch是如何实现Master选举的？
Elasticsearch的选主是ZenDiscovery模块负责的，主要包含Ping（节点之间通过这个RPC来发现彼此）和Unicast（单播模块包含一个主机列表以控制哪些节点需要ping通）
分为两部分；
-
对所有可以成为master的节点（node.master:
true）根据nodeId字典排序，每次选举每个节点都把自己所知道节点排一次序，然后选出第一个（第0位）节点，暂且认为它是master节点。 -
如果对某个节点的投票数达到一定的值（可以成为master节点数n/2+1）并且该节点自己也选举自己，那这个节点就是master。否则重新选举一直到满足上述条件。