数据模型
基于文档的搜索引擎，它使用 JSON 文档来存储数据。ES中，相关的数据通常存储在同一个文档中，而不是分散在多个表中
节点
- 主节点
- 候选主节点（Master-eligible Node)：可以被选举为主节点的节点。主节点主要负责集群本身
的管理，⽐如说创建索引。类似的还有仅投票节点（Voting-only Node），这类节点只参与主从
选举，但是⾃身并不会被选举为主节点。 - 协调节点（Coordinating Node）：协调节点负责协调请求的处理过程。⼀个查询请求会被发送
到协调节点上，协调节点确定数据节点，然后让数据节点执⾏查询，最后协调节点合并数据节
点返回的结果集。⼤多数节点都会兼任这个⻆⾊。 - 数据节点（Data Node）：存储数据的节点。当协调节点发来查询请求的时候，也会执⾏查询并
且把结果返回给协调节点。类似的还有热数据节点（Hot Data Node）、暖数据节点（Warm Data Node）、冷数据节点（Cold Data Node），你从名字就可以看出来，它们只是⽤于存储不
同热度的数据。
查询语言
使用 Query DSL（Domain Specific Language），基于 JSON，支持全文搜索、复合查询、过滤以及聚合等
核心功能
核心功能是全文搜索。它对数据进行索引时会自动建立全文搜索索引，使其在搜索大量文本数据时表现优异
ACID事务
不支持ACID事务
场景
主要用于快速检索文档，也可用于日志、数据分析、监控等，我的实际使用场景是快速检索文档
倒排索引
两个步骤：分词、建立倒排索引
例如：王来勇是大帅比
分词：王来勇、是、大帅比
简历倒排索引：王来勇、是、大帅比三个词都与王来勇是大帅比这个文档id相关联
分词默认是Standard 模式分词,中文正常是使用 IK 分词器：ik_smart: 会做最粗粒度的拆分，ik_max_word: 会将文本做最细粒度的拆分
ES和数据库的数据一致性
双写（没解耦，互相有影响，还有单词处理时间长）
对数据库和ES进行双写，并且先操作本地数据库，后操作ES，而且还需要把两个操作放到一个事务中
MQ异步消费
抛消息，数据库和ES各有监听然后消费
观察者模式（例如binlog监听（Maxwell）），数据库有变动抛消息，ES监听然后消费
定时同步
ES性能优化
集群和硬件
花钱即可使用缓存
不经常变化的数据，查询后缓存，设置好过期策略慢查询日志
查询优化（别的地方copy的，注意即可，慢了看慢查询日志找ai优化）
避免高开销查询: 如 wildcard、regexp 等类型的查询往往开销较大，尽量避免使用或优化其使用方式。
使用过滤器: 对于不需要评分的查询条件，使用 filter 而不是 query，因为 filter 可以被缓存以加快后续相同查询的速度。
查询尽可能少的字段: 只返回查询中需要的字段，减少数据传输和处理时间。
避免深度分页: 避免深度分页，对于需要处理大量数据的情况，考虑使用 search_after。
避免使用脚本：尽量避免使用脚本（Script）查询，因为它们通常比简单查询要慢。（脚本执行通常比静态查询更消耗资源。每次执行脚本时，都需要进行编译（除非缓存）和运行，这会增加CPU和内存的使用。脚本执行不能利用索引，因此可能需要全面扫描文档。）
使用 term 而非 match 查询文本字段： 一般来说，term 查询比 match 查询快，因为 term 查询不需要对查询内容进行分词。term 查询直接查找精确的值，索引定位效率高。
避免使用通配符、正则表达式：这类查询往往非常消耗资源，特别是以通配符开头的（如 *text）。
合理使用聚合：聚合可以用于高效地进行数据分析，但复杂的聚合也可能非常消耗资源。优化聚合查询，如通过限制桶的数量，避免过度复杂的嵌套聚合。