索引层面优化

分片大小

分片大小对于搜索查询非常重要

1. 如果分配给索引的分配太多分片,会导致lucene分段很小.从而导致开销增加.
2. 查询也会降低查询的吞吐量

• 优化：官方建议一个分片大小20~40GB左右,根据集群大小合理规划分片数

针对场景优化

1. 基于时间滚动索引(周、月、日为周期建立索引)
2. 别名：实现在查询时可以查询分散的时间索引,就如同在单个索引上查询一样

Index Sorting

集群层

规划集群规模

根据业务情况规划集群大小

• 数据总量、每天增量
• 查询类型和并发
• 节点数不建议太多 最大集群规模控制在100以内,节点太多会增加master节点压力
• 单个分片不超过50G,集群最大分片控制在几十万级别,超过集群恢复时间长

节点层

堆空间:最主要的考虑因素之一是确保至少有一半的可用内存进入文件系统缓存，以便Elasticsearch可以将索引的hot regions保留在物理内存中

jvm

ES官方推荐JVM内存为31G，超过32G,内存指针压缩失效,浪费一些内存,降低cpu性能,GC压力较大
堆内存 最大最小保持一致,防止运行时动态改变内存大小

部署

当主机内存超过64G,并拥有多个数据盘时.部署节点方案

1. 部署单个节点,jvm内存不超过32G,配置全部数据盘
   缺点:多余内存只能被cache使用,并且有一个坏盘,节点无法重启
2. 部署单个节点,JVM超过32G
   缺点:gc压力及内存指针压缩失效
3. 有多少个数据盘就部署多少个节点,每个节点配置单个数据路径.
   优点：统一配置,
   缺点：节点数太多,集群压力比较大,适合集群规模比较小
4. 使用内存大小除以64GB来确定部署节点数.每个节点部署一部分数据盘.
   优点:资源利用率最高,
   缺点:部署复杂
   总结:官方推荐方案4 也可以使用1和3
   集群规模小考虑多节点部署方式
   集群规模大的时候,考虑单节点部署 例如100台以上

节点下线

下线或维护节点时,通过
cluster.routing.allocation.exclude._ip
cluster.routing.allocation.exclude._name
排除节点,当分哦迁移完毕,在下线该节点

主从分离

master和data node分离(集群规模大的情况)
好处:master切换可以迅速完成
跳过 gateway和分片重新分配的 过程，主节点没有存储数据,master下线不会产生未分配的分片.master选举后集群立即变为green

节点层

控制线程池队列大小

为系统cache保留一半的物理内存

• 搜索依赖系统cache的命中,建议是把50%的可用内存作为es的堆内存,
  剩下的作为系统cache

系统层

关闭swap

配置linux OOM killer

vm相关参数

写文件的数据 先到page cache 系统缓存,再由系统缓存定期异步的刷入磁盘.存在在page cache的数据尚未刷盘的数据称为 脏页或dirty page.
写缓存可以提升IO的速度 缺点 数据丢失的风险

• page cache刷盘的三种时机

1. 物理内存低于特定阈值,为系统腾出空间内存
2. 脏页驻留时间超过特定阈值,避免脏页无限驻留
3. 被用户 sync()或fsync()触发

• 系统执行刷盘的两种策略
  1.异步执行刷盘
  2.同步执行刷盘,用户io被阻塞

重要参数

• vm.dirty_background_ratio 默认10 当内存脏数据超过百分比,系统异步刷盘.不超过不刷屏驻留
• vm.dirty_ratio 默认30 超过百分比 系统同步刷盘,写请求被阻塞
• vm.dirty_expire_centisecs 默认30秒 定义脏数据的过期时间
  超过这个时间被异步刷盘
  vm.dirty_writeback_centisecs 默认5秒 定时时间间隔 周期性的启动线程来检查是否刷盘
  cat /proc/vmstat | egrep "dirty|writeback"

如果数据安全性要求没那么高,想多“cache”一些数据,让读取更容易命中
vm.dirty_background_ratio = 30
vm.dirty_ratio = 60
vm.dirty_expire_centisecs = 6000
如果希望写入过程不要被系统的同步刷盘策略影响,则可以让系统更多的容纳脏数据,但早一些触发异步刷盘,这样可以让io更加平滑
vm.dirty_background_ratio=5
vm.dirty_ratio=60

索引层

使用模板

全局模板 template 为“*”的模板
用于设置索引级别的全局设置信息 translog的刷盘方式等

时间滚动的索引

如果一个索引每天都有新增内容,那么不要让这个索引持续增大,建议使用日期等规则按一定频率生成索引,同时将索引设置写入模板,让模板匹配这一系列的索引 例如别名
优点:数据清除立竿见影,不像删除doc 依赖于Lucene 分段的合并

避免热索引分片不均

index.routing.allocation.total_shards_per_node 控制es节点上每个索引最大能分配的分片个数,考虑到节点故障、分片迁移等情况 建议为2

副本数的选择

大部分情况将副本数设置为1,如果对搜索请求的吞吐量要求较高,可以适当增加副本
在大量写入的时候 考虑到写的性能 可以设置为0

Force Merge

对冷索引force merge

• 单一分段占用存储更小
• 减少文件打开书
• 加快搜索
• 减少内存使用
• 加快索引恢复

将分段合并为单个分段,执行成功后自行flush

Shrink Index

在按时间周期构建索引的场景下 ，有可能分片相对数据量会多,这个时候考虑重建索引,减少分片数

close 索引

暂不使用的索引建议close ,减少资源使用

延迟分配分片

• index.unassigned.node_left.delayed_timeout：1m
  该配置表示一个节点故障1m后，系统会开始对该节点上的分片进行恢复操作。如果故障节点上的分片是主分片，那么即使是延时分配，其他节点对应的分片副本也会被置为主分片，否则，该索引无法正常使用，仅仅是延时了副本的故障恢复

减少因为短暂的网络问题、进程退出等情况造成该节点分配的重新分配

较少fielddata的使用

fielddata 使用场景是针对text类型做聚合操作
期读取每个分段中的倒排索引,反转term和doc的关系,将结果存储到jvm堆中

客户端

使用rest API 而非JAVA api

兼容性问题

注意429状态

产生429的问题是es来不及处理,一般是写入段并发过高导致 建议降低并发

读写

避免搜索返回巨大的结果集

如果结果集就是很大,建议使用scroll API

避免索引巨大的DOC

避免使用多个_type

不能通过_type无意义,不过通过_type删除索引

禁用_all

_all用于不知道字段查询 大于6的版本已经废弃

避免将请求发送到同一个协调节点

建议使用 反向代理 LVS 负载均衡,较少对协调节点的压力

查询预热

不需要特殊的操作,ES会替我们完成
https://elasticsearch.cn/question/471
https://www.jianshu.com/p/fa510352ce1a
https://www.elastic.co/guide/en/elasticsearch/reference/master/tune-for-search-speed.html#_warm_up_the_filesystem_cache