ElasticSearch
查询优化手段有哪些？
设计阶段调优
（
1
）根据业务增量需求，采取基于日期模板创建索引，通过
roll over API
滚动索引；
（
2
）使用别名进行索引管理；
（
3
）每天凌晨定时对索引做
force_merge
操作，以释放空间；
（
4
）采取冷热分离机制，热数据存储到
SSD
，提高检索效率；冷数据定期进行
shrink
操作，以缩
减存储；
（
5
）采取
curator
进行索引的生命周期管理；
（
6
）仅针对需要分词的字段，合理的设置分词器；
（
7
）
Mapping
阶段充分结合各个字段的属性，是否需要检索、是否需要存储等。
……..
写入调优
（
1
）写入前副本数设置为
0
；
（
2
）写入前关闭
refresh_interval
设置为
-1
，禁用刷新机制；
（
3
）写入过程中：采取
bulk
批量写入；
（
4
）写入后恢复副本数和刷新间隔；
（
5
）尽量使用自动生成的
id
。
1.
批量提交
背景是大量的写操作，每次提交都是一次网络开销。网络永久是优化要考虑的重点。
2.
优化硬盘
索引文件需要落地硬盘，段的思想又带来了更多的小文件，磁盘
IO
是
ES
的性能瓶颈。一个固态硬
盘比普通硬盘好太多。
3.
减少副本数量
副本可以保证集群的可用性，但是严重影响了 写索引的效率。写索引时不只完成写入索引，还要完
成索引到副本的同步。
ES
不是存储引擎，不要考虑数据丢失，性能更重要。 如果是批量导入，建
议就关闭副本。
9
、
ElasticSearch
查询优化手段有哪些？
设计阶段调优
（
1
）根据业务增量需求，采取基于日期模板创建索引，通过
roll over API
滚动索引；
（
2
）使用别名进行索引管理；
（
3
）每天凌晨定时对索引做
force_merge
操作，以释放空间；
（
4
）采取冷热分离机制，热数据存储到
SSD
，提高检索效率；冷数据定期进行
shrink
操作，以缩
减存储；
（
5
）采取
curator
进行索引的生命周期管理；
（
6
）仅针对需要分词的字段，合理的设置分词器；
（
7
）
Mapping
阶段充分结合各个字段的属性，是否需要检索、是否需要存储等。
……..
写入调优
（
1
）写入前副本数设置为
0
；
（
2
）写入前关闭
refresh_interval
设置为
-1
，禁用刷新机制；
（
3
）写入过程中：采取
bulk
批量写入；
（
4
）写入后恢复副本数和刷新间隔；
（
5
）尽量使用自动生成的
id
。
查询调优
（
1
）禁用
wildcard
；
（
2
）禁用批量
terms
（成百上千的场景）；
（
3
）充分利用倒排索引机制，能
keyword
类型尽量
keyword
；
（
4
）数据量大时候，可以先基于时间敲定索引再检索；
（
5
）设置合理的路由机制。
10
、
elasticsearch
是如何实现
master
选举的？
面试官：想了解
ES
集群的底层原理，不再只关注业务层面了。
前置前提：
（
1
）只有候选主节点（
master
：
true
）的节点才能成为主节点。
（
2
）最小主节点数（
min_master_nodes
）的目的是防止脑裂。
核对了一下代码，核心入口为
fifindMaster
，选择主节点成功返回对应
Master
，否则返回
null
。选
举流程大致描述如下：
第一步：确认候选主节点数达标，
elasticsearch.yml
设置的值
discovery.zen.minimum_master_nodes
；
第二步：比较：先判定是否具备
master
资格，具备候选主节点资格的优先返回；
若两节点都为候选主节点，则
id
小的值会主节点。注意这里的
id
为
string
类型。
题外话：获取节点
id
的方法。
GET /_cat/nodes?v&h=ip,port,heapPercent,heapMax,id,name
ip port heapPercent heapMax id name
11
、
elasticsearch
索引数据多了怎么办，如何调优，部署？
面试官：想了解大数据量的运维能力。
解答：索引数据的规划，应在前期做好规划，正所谓
“
设计先行，编码在后
”
，这样才能有效的避免
突如其来的数据激增导致集群处理能力不足引发的线上客户检索或者其他业务受到影响。
如何调优：
动态索引层面
基于模板
+
时间
+rollover api
滚动创建索引，举例：设计阶段定义：
blog
索引的模板格式为：
blog_index_
时间戳的形式，每天递增数据。这样做的好处：不至于数据量激增导致单个索引数据量
非常大，接近于上线
2
的
32
次幂
-1
，索引存储达到了
TB+
甚至更大。
一旦单个索引很大，存储等各种风险也随之而来，所以要提前考虑
+
及早避免。
存储层面
冷热数据分离存储，热数据（比如最近
3
天或者一周的数据），其余为冷数据。
对于冷数据不会再写入新数据，可以考虑定期
force_merge
加
shrink
压缩操作，节省存储空间和
检索效率。
部署层面
一旦之前没有规划，这里就属于应急策略。
结合
ES
自身的支持动态扩展的特点，动态新增机器的方式可以缓解集群压力，注意：如果之前主
节点等规划合理，不需要重启集群也能完成动态新增的