一、生成环境部署建议
1、系统设置与官方保持一致
官方文档资料：https://www.elastic.co/guide/en/elasticsearch/reference/7.x/setup.html
2、ES设置尽量简洁
elasticsearch.yml中尽量只写必备的参数，其他可以通过api动态设置的参数都通过api来设定
文档 Setup Elasticsearch → Important Elasticsearch Configuration
ES版本升级较快，尽量跟随官方设置，不要copy他人的设置
3、elasticsearch.yml中建议设定的基本参数
cluster.name
node.name
node.master/node.data/node.ingest
network.host 建议显示指定为内网ip，不要偷懒设置为0.0.0.0
discovery.zen.ping.unicast.hosts 设定集群其他节点地址
discovery.zen.mininum_master_nodes 一般设定为2，master节点一般为3个
path.data/path.log
除上述参数外再根据需要增加其他的静态配置参数
动态设定的参数有transient persistent两种设置，前者再集群重启后会丢失，后者不会丢失；两种设定都会覆盖elasticsearch.yml中的配置
4、关于JVM内存设定
不要超过31GB
预留一半内存给操作系统，用来做文件缓存
具体大小根据该node要存储的数据量来估算，为了保证性能，在内存和数据量间有一个建议的比例
搜索类项目的比例建议在1:16以内
日志类的项目比例建议在1:46~1:96之间
假设总数量大小为1TB，3个node，1个副本，那么每个node要存储的数据量为2TB/3=666改变，即700GB左右，做20%的预留空间，每个node要存储大约850GB的数据
如果是搜索类项目，每个node内存大小为850/16=53GB，大于31GB；3116=496GB，即每个node最多存储496GB数据，所以至少需要5个node
如果是日志类型项目，每个node内存大小为850/48=18GB，因此3个节点足够
二、写性能优化
1、refresh
segment写入磁盘的过程很耗时，可以借助文件系统缓存的特性，先将segment在缓存中创建并开放查询来进一步提升实时性，该过程在es中被称为refresh。
在refresh之前文档会先存储在一个buffer中，refresh时将buffer中的所有文档清空并生成segment
es每默认1s执行一次refresh，因此文档的实时性被提高到1秒，这也是es被称为近实时(Near Real Time)的原因
2、translog
es引入translog机制解决断电可能导致的数据丢失问题。写入文档到buffer时，同时将该操作写入到translog。
translog文件会即时写入磁盘（fsync），默认每个请求都会落盘，可以修改为每5秒写一次，这样风险便是丢失5秒内的数据，相关配置为index.translog.
es启动时会检查translog文件，并从中恢复数据
3、flush
flush负责将内存中的segment写入磁盘，主要做如下的工作：
将translog写入磁盘
将index buffer清空，将其中的文档生成一个segment，相当于一个refresh操作
更新commit point 并写入磁盘
执行fsync操作，将内存中的segment写入磁盘
删除旧的translog文件
优化方案：
客户端：多线程写、批量写
ES：在高质量数据建模的前提下，主要是在refresh、translog、flush之间做文章
降低refresh频率
增加translog大小、降低translog写磁盘的频率
副本设置
合理设计shard数，并保证shard均匀地分配在所有node上，充分利用所有node的资源
三、读性能优化
1、数据模型是否符合业务模型？
高质量的数据建模是优化的基础
将需要通过script脚本动态计算的值提前算好作为字段存到文档中
尽量使数据模型贴近业务模型
2、索引配置是否优化？
根据数据规模设置合理的主分片数，可以通过测试得到最适合的分片数
设置合理的副本数据，不是越多越好
3、查询语句是否优化？
尽量使用filter上下文，减少计算得分的场景
尽量不使用Script进行字段计算或者算分排序
结合profile/explain API分析慢查询语句的症结所在，然后再优化数据模型
四、如何设定shard数
ES的性能基本上是线性扩展的，因此我们只要测出1个Shard的性能指标，然后根据实际性能需求就能测算出需要的Shard数。比如单Shard写入eps 是10000，而线上eps需求是50000，那么至少需要5个shard（实际还要考虑副本的情况）
测试1个shard的流程如下：
搭建与生产环境相同配置的单节点集群
设定一个单分片零副本的索引
写入实际生成数据进行测试，获取写性能指标
针对数据进行查询请求，获取读性能指标
压测工具 esrally
如果是搜索引擎场景，单shard大小不超过15GB，如果是日志场景，单shard大小不超过50GB(shard 越大，查询性能越低)
估算初索引的总数据大小，然后再除以单shard大小可以得到分片数
五、xpack监控功能介绍
Stack Monitoring 介绍