代码拉取完成，页面将自动刷新
面试官：想了解ES搜索的底层原理，不再只关注业务层面了。
搜索拆解为“query then fetch” 两个阶段。
query阶段的目的：定位到位置，但不取。
步骤拆解如下：
1、 假设一个索引数据有5主+1副本 共10分片，一次请求会命中（主或者副本分片中）的一个。
2、 每个分片在本地进行查询，结果返回到本地有序的优先队列中。
3、 第2）步骤的结果发送到协调节点，协调节点产生一个全局的排序列表。
fetch阶段的目的：取数据。
路由节点获取所有文档，返回给客户端。
Beats是一种开源工具，可以将数据直接传输到 Elasticsearch 或通过 logstash，在使用Kibana进行查看之前，可以对数据进行处理或过滤。
传输的数据类型包含：审核数据，日志文件，云数据，网络流量和窗口事件日志等。
当文档数量增加，硬盘容量和处理能力不足时，对客户端请求的响应将延迟。
在这种情况下，将索引数据分成小块的过程称为分片，可改善数据搜索结果的获取。
两者的本质区别：
精确匹配用于：是否完全一致？
举例：邮编、身份证号的匹配往往是精准匹配。
全文检索用于：是否相关？
举例：类似B站搜索特定关键词如“马保国 视频”往往是模糊匹配，相关的都返回就可以。
Elasticsearch 当前最新版本是7.10（2020年11月21日）。
为什么问这个问题？ES 更新太快了，应聘者如果了解并使用最新版本，基本能说明他关注 ES 更新。甚至从更广维度讲，他关注技术的迭代和更新。
但，不信你可以问问，很多求职者只知道用了 ES，什么版本一概不知。
没有用过，这是 Graph （收费功能）相关的API。
点到为止即可，类似问题实际开发现用现查，类似问题没有什么意义。
https://www.elastic.co/guide/en/elasticsearch/reference/current/graph-explore-api.html
面试官：想了解应聘者之前公司接触的ES使用场景、规模，有没有做过比较大规模的索引设计、规划、调优。
如实结合自己的实践场景回答即可。
比如：ES集群架构13个节点，索引根据通道不同共20+索引，根据日期，每日递增20+，索引：10分片，每日递增1亿+数据，
每个通道每天索引大小控制：150GB之内。
仅索引层面调优手段：
设计阶段调优
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、 设置合理的路由机制。
1.4、其他调优
部署调优，业务调优等。
上面的提及一部分，面试者就基本对你之前的实践或者运维经验有所评估了。
7.1 安全功能免费后，使用了：setup-passwords 为账号设置密码，确保集群安全。
(1) 客户端使用RestFul API向对应的node发送查询请求
(2)协调节点将请求转发到所有节点（primary或者replica）所有节点将对应的数据查询之后返回对应的doc id 返回给协调节点
(3)协调节点将doc进行排序聚合
(4) 协调节点再根据doc id 把查询请求发送到对应shard的node，返回document
我们遵循官方建议，一个Node最好不要多于三个shards.
此处可能存在不合适展示的内容，页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容，可点击提交进行申诉，我们将尽快为您处理。
