本文主要介绍一些能够提升ES性能的优化手段，以及一些防坑措施，请大家参考。
内存设置
由于ES构建基于lucene, 而lucene设计强大之处在于lucene能够很好的利用操作系统内存来缓存索引数据，以提供快速的查询性能。lucene的索引文件segements是存储在单文件中的，并且不可变，对于OS来说，能够很友好地将索引文件保持在cache中，以便快速访问；因此，我们很有必要将一半的物理内存留给lucene ; 另一半的物理内存留给ES（JVM heap)。所以，在ES内存设置方面，可以遵循以下原则：
- 1.当机器内存小于64G时，遵循通用的原则，50%给ES，50%留给lucene。
- 2.当机器内存大于64G时，遵循以下原则：
- a.如果主要的使用场景是全文检索，那么建议给ES Heap分配 4~32G的内存即可；其它内存留给操作系统, 供lucene使用（segments cache), 以提供更快的查询性能。
- b.如果主要的使用场景是聚合或排序，并且大多数是numerics, dates, geo_points 以及not_analyzed的字符类型，建议分配给ES Heap分配 4~32G的内存即可，其它内存留给操作系统，供lucene使用(doc values cache)，提供快速的基于文档的聚类、排序性能。
- c.如果使用场景是聚合或排序，并且都是基于 analyzed 字符数据，这时需要更多的 heap size, 建议机器上运行多ES实例，每个实例保持不超过50%的ES heap设置(但不超过32G，堆内存设置32G以下时，JVM使用对象指标压缩技巧节省空间)，50%以上留给lucene。
- 3.对于数据量比较大，无法把全部数据都缓存到os cache，尽量保证整个集群，所有机器os cache内存总和，超过整个存储容量的一般以上，这样才能提高性能，实在不行，只能采取其他措施，比如：
- a.数据预热，在后台做一个系统，定时查询热点数据，缓存到os cache中，下次用户访问热点数据时，就会直接从os cache中获取，不需要再查询磁盘了
- b.冷热分离，对于一条索引中，有些字段检索比较频繁，即为热字段，有些字段检索比较少，即为冷字段，对于这种情况，把一个索引拆分为两条索引，热字段一条，冷字段一条
- 这样经常检索的索引就会被缓存os cache，大部分时间冷索引就会在磁盘，提高内存利用率
- 4.禁止swap，一旦允许内存与磁盘的交换，会引起致命的性能问题。通过在
elasticsearch.yml中bootstrap.memory_lock: true，以保持JVM锁定内存，保证ES的性能。
分片设置
ES一旦创建好索引后，就无法调整分片的设置，而在ES中，一个分片实际上对应一个lucene索引，而lucene索引的读写会占用很多的系统资源，因此，分片数不能设置过大；所以，在创建索引时，合理配置分片数是非常重要的。一般来说，我们遵循一些原则：
- 1.控制每个分片占用的硬盘容量不超过ES的最大JVM的堆空间设置（一般设置不超过32G），因此，如果索引的总容量在500G左右，那分片大小在16个左右即可；当然，最好同时考虑原则2。
- 2.考虑一下node数量，一般一个节点有时候就是一台物理机，如果分片数过多，大大超过了节点数，很可能会导致一个节点上存在多个分片，一旦该节点故障，即使保持了1个以上的副本，同样有可能会导致数据丢失，集群无法恢复。所以，一般都设置分片数不超过节点数的3倍。
索引设置
- 我们知道，es内存比较宝贵，所以在我们设计索引的时候就需要进行处理，只把需要检索的字段存入，其他不需要检索的字段，存储到mysql或hbase中，提高es内存利用率
- 设计索引模型的时候，对于需要join等操作的场景，尽量在入es的时候处理好，即多个表合为一张宽索引，避免查询时使用join等操作