5.面试题——Elasticsearch

1.用Elasticsearch的好处是什么？

使用ElasticSearch的主要好处在于其强大的全文搜索和实时分析能力。ElasticSearch基于Apache Lucene构建，提供了高性能、可扩展的搜索解决方案，支持复杂的搜索查询，如模糊搜索、全文搜索、多字段搜索、地理空间搜索等。它能够自动处理文本分析，如分词、索引和查询优化，从而极大地提升了搜索速度和准确性。此外，ElasticSearch支持分布式部署，能够轻松处理PB级数据，保证了系统的高可用性和可扩展性。无论是用于构建搜索引擎、日志分析、实时监控还是其他需要高效搜索和分析的场景，ElasticSearch都能提供强大的技术支持和灵活的配置选项，帮助用户快速响应业务需求。

系统中的数据， 随着业务的发展， 时间的推移， 将会非常多，而业务中往往采用模糊查询进行数据的 搜索，而模糊查询会导致查询引擎放弃索引，导致系统查询数据时都是全表扫描，在百万级别的数据库中， 查询效率是非常低下的，而我们使用 ES 做一个全文索引，将经常查询的系统功能的某些字段，比如说电 商系统的商品表中商品名，描述、价格还有 id 这些字段我们放入 ES 索引库里，可以提高查询速度。

2.数据同步（数据库数据同步到ES中）

一般情况下，如果做查询搜索功能，使用ES来模糊搜索，但是数据是存放在数据库MySQL里的，所以说我们需要把 MySQL
中的数据和ES进行同步，保证数据一致(以 MySQL为主)。

4种方式，全量同步（首次)＋增量同步（新数据)︰

• 定时任务，比如1分钟1次，找到 MySQL 中过去几分钟内(至少是定时周期的2倍)发生改变的数据，然后更新到ES。
  • 优点:简单易懂、占用资源少、不用引入第三方中间件
  • 缺点:有时间差
  • 应用场景:数据短时间内不同步影响不大、或者数据几乎不发生修改
• 双写:写数据的时候，必须也去写ES;更新删除数据库同理。(事务:建议先保证 MySQL写成功，如果ES写失败了，可以通过定时任务＋日志＋告警进行检测和修复(补偿))
• 用Logstash 数据同步管道（一般要配合kafka消息队列+ beats采集器)
• 订阅数据库流水的同步方式Canal
  • 优点：实时同步，实时性非常强
  • 原理：数据库每次修改时，会修改binlog文件，只要监听该文件的修改，就能第一时间得到消息并处理
  • canal:帮你监听 binlog，并解析 binlog为你可以理解的内容：它伪装成了mysql的从节点
    

3.Elasticsearch 是如何实现 master 选举的？（底层）

前置前提：

1. 只有候选主节点（master：true）的节点才能成为主节点。
2. 最小主节点数（min_master_nodes）的目的是防止脑裂。

核对了一下代码，核心入口为 findMaster，选择主节点成功返回对应 Master，否则返回 null。选举流程大致描述如下：

• 第一步：确认候选主节点数达标，elasticsearch.yml 设置的值
  • discovery.zen.minimum_master_nodes；
• 第二步：比较：先判定是否具备 master
  • 资格，具备候选主节点资格的优先返回； 若两节点都为候选主节点，则 id 小的值会主节点。注意这里的 id 为 string 类型。
  • 题外话：获取节点 id 的方法。

4.elasticsearch 的倒排索引是什么？

传统的我们的检索是通过文章，逐个遍历找到对应关键词的位置。
而倒排索引，是通过分词策略，形成了词和文章的映射关系表，这种词典+映射表即为倒排索引。有了倒排索引，就能实现
o（1）时间复杂度的效率检索文章了，极大的提高了检索效率。

倒排索引，相反于一篇文章包含了哪些词，它从词出发，记载了这个词在哪些文档中出现过，由两部分 组成——词典和倒排表。
加分项：倒排索引的底层实现是基于：FST（Finite State Transducer）数据结构。 lucene 从4+版本后开始大量使用的数据结构是 FST。FST 有两个优点：
（1）空间占用小。通过对词典中单词前缀和后缀的重复利用，压缩了存储空间；
（2）查询速度快。O(len(str))的查询时间复杂度。

5.elasticsearch 索引数据多了怎么办，如何调优，部署？

• 动态索引层面
  • 基于模板+时间+rollover api 滚动创建索引，举例：设计阶段定义：blog 索引的模板格式为：blog_index_时间戳的形式，每天递增数据。这样做的好处：不至于数据量激增导致单个索引数据量非 常大，接近于上线 2 的32次幂-1，索引存储达到了 TB+甚至更大。一旦单个索引很大，存储等各种风险也随之而来，所以要提前考虑+及早避免。
• 存储层面
  • 冷热数据分离存储，热数据（比如最近 3 天或者一周的数据），其余为冷数据。
  • 对于冷数据不会再写入新数据，可以考虑定期 force_merge 加 shrink 压缩操作，节省存储空间和检索效率。
• 部署层面
  • 一旦之前没有规划，这里就属于应急策略。
  • 结合 ES 自身的支持动态扩展的特点，动态新增机器的方式可以缓解集群压力，注意：如果之前主节点
  • 等规划合理，不需要重启集群也能完成动态新增的。

6.query 和 filter 有什么区别？

• query： 查询操作不仅仅会进行查询，还会计算分值，用于确定相关度；
• filter： 查询操作仅判断是否满足查询条件，不会计算任何分值，也不会关心返回的排序问题，同时，filter查询的结果可以被缓存，提高性能。

7.elasticsearch 了解多少，说说你们公司 es 的集群架构，索引数据大小，分片有多少，以及一些调优手段 。（高级）

ES 集群架构 13 个节点，索引根据通道不同共 20+索引，根据日期，每日递增 20+，索引：10分片，每日递增 1亿+数据，每个通道每天索引大小控制：150GB 之内。

• 设计阶段调优
  • 根据业务增量需求，采取基于日期模板创建索引，通过 roll over API 滚动索引；
  • 使用别名进行索引管理；
  • 每天凌晨定时对索引做 force_merge 操作，以释放空间；
  • 采取冷热分离机制，热数据存储到 SSD，提高检索效率；冷数据定期进行 shrink操作，以缩减存储；
  • 采取 curator 进行索引的生命周期管理；
  • 仅针对需要分词的字段，合理的设置分词器；
  • Mapping 阶段充分结合各个字段的属性，是否需要检索、是否需要存储等。………
• 写入调优
  • 写入前副本数设置为 0；
  • 写入前关闭 refresh_interval 设置为-1，禁用刷新机制；
  • 写入过程中：采取 bulk 批量写入；
  • 写入后恢复副本数和刷新间隔；
  • 尽量使用自动生成的 id。
• 查询调优
  • 禁用 wildcard；
  • 禁用批量 terms（成百上千的场景）；
  • 充分利用倒排索引机制，能 keyword 类型尽量 keyword；
  • 数据量大时候，可以先基于时间敲定索引再检索；
  • 设置合理的路由机制。
• 其他调优
  • 部署调优，业务调优等。
  • 上面的提及一部分，面试者就基本对你之前的实践或者运维经验有所评估了。