Elasticsearch优化

1.搜索优化

1.为操作系统预留足够的内存。搜索命中缓存可以显著减少对磁盘访问，提高性能。

2.尽量使用SSD,SSD性能好于旋转类磁盘，避免使用NFS类远程文件系统，NFS在搜索情况下，会慢10倍左右。

3.一些字段可以预索引。比如根据价格范围来搜索，如果新增一个字段，落库时候预计算范围，落入price_range。会有显著提升。

4.有些字段的内容是数值，但并不意味着其总是应该被映射为数值类型，例如，一些标识符，将它们映射为keyword可能会比integer或long更好

5.避免使用脚本

6.为不再更新的只读索引执行force merge，将Lucene索引合并为单个分段，可以提升查询速度。当一个Lucene索引存在多个分段时，每个分段会单独执行搜索再将结果合并，将只读索引强制合并为一个Lucene分段不仅可以优化搜索过程，对索引恢复速度也有好处。

2.写入优化

1.推荐使用es自己生成的id,减少计算。

2.加大translog flush间隔，目的是降低iops、writeblock。

3. 加大index refresh间隔，除了降低I/O，更重要的是降低了段合并segment merge频率。

4.批量写使用bulk请求 。批量写比一个索引请求只写单个文档的效率高得多，但是要注意bulk请求的整体字节数不要太大，太大的请求可能会给集群带来内存压力，因此每个请求最好避免超过几十兆字节，即使较大的请求看上去执行得更好。建立索引的过程属于计算密集型任务，应该使用固定大小的线程池配置，来不及处理的任务放入队列。线程池最大线程数量应配置为CPU核心数+1

3.分片大小

1. 对于数据量较小（100GB以下）的index，往往写入压力查询压力相对较低，一般设置3~5个shard，副本设置为1即可（也就是一主一从，共两副本）
2. 对于数据量较大（100GB以上）的index：一般把单个shard的数据量控制在（20GB~50GB）
   综合考虑整个index的shard数量，如果shard数量（不包括副本）超过50个，就很可能引发拒绝率上升的问题，此时可考虑把该index拆分为多个独立的index，分摊数据量，同时配合routing使用，降低每个查询需要访问的shard数量。