ElasticSearch7
倒排索引
数据写入时，建立关键字和主键的映射，查询时–>关键字–>主键–>对应文章
分片
因为ES是以检索为主的产物，为了便于查询，会将数据进行分片，例如:根据性别分片，当查询女的时候就只需要去女性这个分片中查询，速度更快。
在创建index的时候可以指定分片数进行设置，一旦设定，无法修改
副本
为防止数据节点宕机或者挂掉，影响服务的使用，可以在创建inde的时候指定副本数目，如果设置为1时，则相当于在集群中，会有两份相同数据存在，当原始数据丢失时，可以通过副本进行数据恢复或者响应
可以通过setting方法修改副本数量
多分片数据路由
当有写数据进来时，会根据数据主键hash(id)来计算，当前数据存储在哪个节点
当用户读取数据时，因为在每个分片中都会存在一份数据，所以集群会轮询到指定节点，但是并不是一定在当前节点做数据返回，如果当前节点的负载比较高时，会协调一个负载较低的节点处理当前请求。
多分片多副本数据写入流程
- 客户端写入数据，随意访问集群中的节点（协调节点）
- 协调节点创建该数据的id信息，进行hash(id)，查询到对应主数据节点
- 主数据节点进行数据保存，然后将数据发送至副本节点
- 副本节点保存数据，反馈结果给主数据节点
- 主数据节点反馈到客户端
- 客户端收到写入数据反馈，写入成功
在写入时，可以通过设置consistency属性设置，是否需要副本节点反馈,其参数选项有:
- one，只需要主节点写入成功即视为写入成功
- all，需要所有副本节点写入成功才视为写入成功
- quorum，大多数节点写入成功即视为写入成功，计算公式：
多分片多副本查询数据流程
- 客户端请求数据，随意访问集群中的节点（协调节点）
- 协调节点进行计算所在分片，并获取到所有的副本节点
- 为了负载均衡，回轮询所有节点
- 将请求转发到指定节点
- 该节点进行数据返回
关键字
- 词条：索引中最小存储和查询单元
- 词典：字典，词条的集合，使用B+、hashMap存储
- 倒排表：关键词出现在什么位置，和出现的频率，每条数据叫做倒排项
全文检索的大致流程
倒排查询的搜索过程：
- 词典中查询关键字是否存在，不存在直接返回
- 查询倒排表，关键词在倒排表中的指针，找到文档id的列表
- 找到对应的数据
- 进行返回
倒排索引早期的问题及好处
- 早期阶段，ES会为整个文档建立一个很大的倒排索引，并将其写入到磁盘，该倒排索引不会被修改，然后将其加载到内存中，因为不可边，所以不存在线程安全问题；一个大的倒排索引是允许被压缩的，这样在读到内存中，可以大量减少磁盘IO
- 问题：倒排索引是不允许被修改的，当更新频率较高时，就需要创建新的索引文件，重新建立倒排表，效率会降低，性能也会急剧下降
动态更新索引
如何在不变性的前提下，实现倒排索引的更新？
- 引入段的概念，通过新增段，来减少修改情况下建立整个索引表的问题
删除
在我们删除的时候，由于索引段不会被修改，所以我们在查询的时候还是会查询到被删除的文档。删除的过程是将要删除的文档使用.del标识，查询到结果后发现该文档被.del所标识，则将该文档从查询结果中剔除（逻辑删除）
合并倒排索引
当索引段数量过多时，会将索引段进行合并，在合并的过程中，会将删除的文档从磁盘中彻底删除（物理删除），可以通过refresh_interval来设置段合并的频率，单位是秒
真正的写入流程
- 客户端执行写入请求
- 协调节点找到主分片节点，和其他副本节点
- 将文件写入主分片节点，并在主分片的内存中建立索引生成index数据
- 将index数据封装成一个segment数据对象，并将操作写入translog中
- 根据设置的refresh_interval(默认1s)属性所指定的频率，将segment数据对象、translog刷新至OSCache中
- 根据flush(默认30m)属性所设定的值，将OSCache中的segment数据对象和translog文件flush到磁盘中
- 当磁盘中的segment文件越来越多时，会将segment文件进行合并
文本分析器
- 分词器
- 字符过滤器，在建立索引文件时，将文本进行转换
- token过滤器，按照特定的要求、特定的格式进行转化，比如转换大小写、删除指定字符
ES性能优化
由于elasticSearch是重度使用磁盘的
- 硬件方面
- 使用SSD(固态硬盘)
- 使用RID0，其本质就是，将数据存储到多快磁盘中，当有请求进来时，就可以多快磁盘并行处理
- 使用多快硬盘，可以通过配置path.data进行配置
- 尽可能的避免使用远程挂载
- 合理的设置分片策略
- 每一个分片可以视为一个搜索引擎，意味着内存、文件句柄消耗严重
- 如果每一个分片都分配到不同节点还好，如果一个节点中包含多个分片，则面临资源竞争
- 计算词条相关度是根据每个分片来的，如果分片多的话，会导致相关度计算存在误差
- 总的分片数一般不要超过节点数的3倍，例如3个分片+2个副本为3+(3*2)=9
- 节点数<=主分片数*(副本数-1)
- 推迟分片分配
- 默认情况下当节点宕机后，集群会重新分配分片，就需要大量的资源消耗，可以设置节点重新上线的时间，比如节点宕机后五分钟未上线才会重新分配分片
- 使用路由参数
- 不带路由（routing）参数，协调节点无法计算数据所属分片，只能将请求分发至所有节点，返回经过后进行聚合
- 带路由参数(routing)，协调节点计算出所属分片，将查询结果返回
- 写入优化
- 加大translog flush，目的是为了降低Iops、write block
- 增加index Refresh,目的是减少segment merge 频率
- 调整bulk线程池和队列
- 优化节点间的任务分配
- 尽量批量数据提交
- 数据尽量不要超过100m
- 段合并
- 在后台定期进行段合并
- 减少副本的数量
- 可以在写入阶段，将副本数量设置为0，在数据写入完成后，再修改副本数量写入副本
- 调整ES的JVM
elasticsearch集群的master是如何选举的？
- ES中选举主要模块是ZenDiscovery模块负责的，主要包括Ping和Unicast
- ping 节点直接通过这个RPC来进行彼此通信
- unicast单播模块维护一个主机列表，来判断哪些主机需要ping通
- 对所有可成为master(配置文件中node.master=true)的节点进行排序（通过nodeId），每次选举的时候都把当前节点所知道的master进行排序，选出排为第一个的节点,当该节点收到的票数为一半以上，并且该节点的投票是自己，则当前节点为master，若未达到一半以上，则重复以上步骤
- master的指责是集群、节点、索引的管理，不负责文档级别的管理，数据是有data节点进行管理的
有哪些情况可能出现脑裂问题
- 由于网络问题，集群之间的网络延迟，从节点无法访问到master,导致从节点重新选举出新的master
- 节点负载，当节点既是数据节点又是主节点时，访问量较大时，可能出现响应延迟，从节点无法及时访问到master,并认为master节点挂点了，选举出新的master
- 内存回收，当主节点也是数据几点时，进程占用较大，发生GC时，会出现响应延迟，从节点无法及时访问，从新选举出新的主几点
如何避免脑裂问题
- 减少误判，discovery.zen.ping_timeout的默认超时时间是3s，可以将该时间设置的大一点，减少误判的概率
- 增加触发选举节点的数量，官方推荐（n/2）+1，当有一半以上的节点都认为主节点挂了，才会进行选举
- 角色分离，将主节点和数据节点分离，避免出现负载或者GC所导致的响应延迟
ElasticSearch 是如何保证读写一致的
- 可以使用版本号，使用乐观锁，确保新版本的数据不会被旧版本的数据覆盖掉
- 在写操作的过程中，一致性级别包括quorume/one/all，可以使用高级别的写入策略来保证数据的一致性
- quorume 为默认配置，表示当大多数的节点写入成功即认为成功
- one 当有一个节点写入成功则认为写入成功
- all 表示需要所有的节点都需要写入成功
- 对于读操作时，可以使用replication为sync，表示主副分片都返回，来保证数据为最新的
ElasticSearch8
- 新版本采用JDK17 ,并默认包含，也提供了兼容jdk8的版本
- ES8中废除了type的概念
- ES8中默认开启安全认证的
- 提供了同步和异步API
- 提供了EQL(事件查询语句 )
- 在ES6.3以后就支持了SQL操作，Kibana中我们使用的是DSL
- ES提供了实用lambda的相关API
cursor（游标）
当我们使用sql进行查询时，假如总共有3天数据，但是我们的查询语句只需要返回2条数据，则剩下的这条数据就会进入cursor中，在后续查询中，可以直接使用cursor进行查询，只可以取用一次，多次使用时，结果是返回空，游标是消耗性能的，可以使用close进行关闭
权重
- ES中查询到的结果是按照score进行排序的，可进行设置权重查询自己想要的那条数据
- 可以使用explan查询权重计算详情
NLP自然语言处理
- 下载openNLP
- 下载NLP预处理模型包，输入对应的语句，可进行预处理的分析
性能优化
- 页缓存
- 操作系统级别的缓存
- ES是实用java语言编写的，java无法直接操作OS的文件，所以OS将文件缓存到内存中
- 一般情况下我们在设置ES程序时，ES的内存要小于操作系统的一半，这样就有更大的内存进行缓存文件
- 分片集请求缓存（节点请求缓存）
- 在查询的时候指定request_cache=true ,会将我们的查询结果缓存至该节点的 内存中
- 默认是不开启缓存
- 查询缓存
- 将某一些功能进行缓存，缓存的管理更为精细，相比较于分片集请求缓存，该缓存可以在不同的查询中重复使用
- 减少内存堆
- 如果将ES的内存堆设置的特别大时，我们的内存中会存储大量的索引数据
- 由于ES会将一些查询缓存存入系统内存中，则当ES的内存越大，系统可用内存就会变小
- 官方推荐堆内存不要超过系统内存的一半，并且不要超过30G
- 数据分层
- 热数据，将热点数据存储至性能较好的节点中
- 温数据，有些数据访问频率没有那么高时，将其放至容量较大的节点，速度一般的节点
- 冷数据快照，部分历史数据如果访问频率特别低时，可以将数据迁移至外部存储系统，并做快照处理
- 在7.1.2后续版本，ES可以直接查询对快照数据进行查询，不用拉取过来再查询了
