ElasticSearch相关内容

用途：数据搜索、存储和分析引擎

地理位置搜索、前缀搜索

一个索引就相当于一个 table
索引三结构：aliases、mappings、settings

node 角色

只有 data.master = true（候选节点） 属性的节点才能参与 master 的选举
1）、master：集群中只有一个master节点，一般只负责分片负载均衡以及创建和删除索引，属性是 data.master = true，节点不要设置 node.data ＝ true ，避免存储数据，加大节点压力
2）、coordinating：协调节点，属性：data.master = false 和 data.data = false，只负责分片的负载均衡
3）、数据节点：做数据的存储和查询等，属性：data.master = false 和 data.data = true
4）、voting：投票节点，属性：Node.voting_only = true，仅投票节点，即使配置了data.master = true，也不会参选, 但是仍然可以作为数据节点

倒排索引：基于 term（分词）查找 doc（文档）

正排索引：基于 doc（文档）查找 term（分词），doc_values

TF: term 在每个 doc 中出现的次数（频率），频率越高相关度越高

IDF: term 在整个索引中出现的次数（频率），频率越高相关度越低

可以使用 painless 脚本处理逻辑，类似于 redis 使用 lua 脚本，使用脚本时尽量使用变量方式，这样可以加快脚本执行速度（脚本会在第一次执行后编译好，后序不需要编译了，只需要将变量的值通过参数替换即可）

分词器：ik 中文分词器，分析器：ik_max_word（默认，细粒度）、ik_smart（粗粒度）

text：应用于全文检索，字段内容会被分析，在生成倒排索引以前，字符串会被分析器分成一个个词项，不能用于排序聚合（排序聚合时text内容会加载到堆内存中，占用内存较高）

keyword：text 类型默认都会同时生成 keyword 类型，专门用于聚合和排序，只能通过精确值（exact value）搜索到，Id应该用keyword

在同一字段中同时具有全文本（text）和关键字（keyword）版本会很有用：一个用于全文本搜索（text），另一个用于聚合和排序（keyword）

es 通过版本号乐观锁来实现并发修改数据的

deep_page_search：深度分页查询使用 scroll 来解决 或者避免这种分页查询

filter ：查询到一定次数时会进行缓存，filter 时不会计算 score

Highlight高亮查询

1）、unified highlighter：默认的高亮方式，使用Lucene的实现方式
2）、plain highlighter：性能较高，消耗少量内存，性价比高
3）、fast vactor highlighter 适合字段较大，较复杂的查询情况
自定义标签
1）pre_tag：起始标签，如<b>
2）    post_tag：结束标签，如</b>
注意：每个高亮字段都需要对应一个查询

Suggest搜索推荐（目前使用 completion suggester（支持中文））

suggest：term suggester、phrase suggester、completion suggester、context suggester
completion suggester：基于内存（内存占用高），性能很高，自动补全，自动完成，支持三种查询【前缀查询（prefix）/模糊查询（fuzzy）/正则表达式查询（regex）】

地理位置搜索 （疫情地图）

geo_point：地理位置类型，经纬度坐标
1）latitude：维度  缩写：lat
2）longitude：经度  缩写：lon
Geo-bounding box query：两个点确定一个矩形，搜索中间的点
1）top_left：矩形左上点坐标
2）bottom_right：矩形右上角表

尽量不要使用 fielddata 来做字段的聚合，因为 fielddata 会导致索引数据在堆内存中创建，占用大量的堆内存

rollover index：防止索引过大影响性能，当索引（索引必须指定别名）达到一定条件时自动创建新的索引，原有索引的别名会绑定到新的索引上去

master 选举过程

1）、master 选举，可能会产生脑裂，通过 discovery.zen.minimum_master_nodes = N/2 + 1（最小投票节点数）数量来决定当选 master，解决脑裂问题
2）、Replica 容错，新的master或者原有的master会将丢失的Primary对应的某个副本提升为Primary
3）、Master节点会尝试重启故障机
4）、数据同步，Master会将宕机期间丢失的数据同步到重启机器对应的分片上去

索引压缩

实际上是压缩的分片，并非在原有索引上压缩，而是生成了一个新的索引，由于使用了hash路由算法以及索引不可变的特性，target index 分片数量必须为source index的约数。比如source index p shard：12,那么target index p shard只能是6 4 3 2 1，如果比如source index p shard是质数，那target index p shard只能是1
工作原理和过程：
1）、创建一个新的目标索引，其定义与源索引相同，但主碎片数量较少。
2）、将段从源索引硬链接到目标索引。如果文件系统不支持硬链接，则将所有segment file都复制到新索引中，复制过程很耗时。
3）、shard recovery操作，恢复目标索引

索引写入原理

1）、索引先写入 buffer 中，同时将索引写入 translog 文件中（防止数据丢失）此时索引无法访问
2）、buffer 中的索引默认每隔 1s refresh 写入 index segment file（段文件） 文件系统缓存中（os buffer cache（pageCache），清空buffer数据，此时打开搜索限制，索引才可以访问
3）、每隔一定时间(默认30分钟), 或者当translog文件达到一定大小时, 发生flush操作, 并执行一次全量提交
 3.1）将此时内存buffer(缓冲区)中的所有数据写入一个新的segment, 并commit到文件系统的cache中;
 3.2）打开这个新的segment, 供搜索使用;
 3.3）清空当前的内存buffer(缓冲区);
 3.4）将translog文件中的所有segment通过fsync强制刷到磁盘上;
 3.5）将此次写入磁盘的所有segment记录到commit point中, 并写入磁盘;
 3.6）删除当前translog, 创建新的translog接收下一波创建请求

translog：防止数据丢失，存储了上一次flush(即上一个commit point)到当前时间的所有数据的变更记录. —— 即translog中存储的是还没有被刷到磁盘的所有最新变更记录

commit point：做恢复数据，记录成功写入磁盘的所有 segment。ES发生故障, 或重启ES时, 将根据磁盘中的commit point去加载已经写入磁盘的segment, 并重做translog文件中的所有操作, 从而保证数据的一致性

index segment file merge过程

1）、选择一些相似大小的 segment merge 成一个新的 segment
2）、执行 flush 操作，将新的 segment 刷新到磁盘持久化
3）、更新commit文件: 写一个新的commit point, 包括了新的segment, 并删除旧的segment
4）、打开新的segment, 完成搜索请求的转移
5）、删除旧的小segment

日志收集分析

fileBeat  -> kafka -> logstash  -> elasticSearch -> kibana

fileBeat ：日志收集

logstash：日志进行filter（内容格式处理） 、output 到 elasticSearch

elasticSearch：日志的存储

kibana：日志的 dasboard 展示