elasticsearch 查询优化

Posted 2021-01-15 ytys

首先对不必要的字段不做分词也就是不做索引，禁止内存交换

1.shard 

• 一个Shard就是一个Lucene实例，是一个完整的搜索引擎。
•  分片数过多会导致检索时打开比较多的文件，多台服务器之间通讯成本加大。
• 而分片数过少会导至单个分片索引过大，所以检索速度也会慢。

• 建议单个分片最多存储10G-20G左右的索引数据，并且尽量集群的所有节点都分片数一致，不要出现分片数不一样导致的一个实例负载过大，等待合并的时间变长；

2.shard副本

• 使用副本的优点：数据备份，提高对大索引的查询效率，建议副本在1-2个左右，过多的副本会延迟合并时间以及磁盘使用率提高，性价比不高
• 当要导入大量数据时，设置副本为0，之后动态添加副本   //（ 效率较大）当导入大量索引时，设置了副本数，es会同时打开副本同步，消耗系统资源，同时需要额外提供主副之间的通信
• 设置副本数curl -XPOST  ‘http://localhost:9200/{_index}/_settings‘ -d ‘{"index":{"number_of_replicas":1}}‘

3.segment

• 每个分片包含多个segment，每一个segment都是一个倒排索引；在查询的时，会把所有的segment查询结果汇总归并后最为最终的分片查询结果返回； segment越多,加载到内存中的segment越多，占用segment memory越多，查询性能可能就会下降，因此应该合并小的segment，减小segment数，提高检索的segment数来提高查询效率；创建索引的时候，elasticsearch会把文档信息写到内存buffer中，elasticsearch定期会执行flush操作，把segment持久化到磁盘上，索引越大，segment越多，查询效率就会下降

---- 合并索引段落语句

curl -XPOST ‘http://localhost:9200/{_index}/_forcemerge?max_num_segments=1‘

4： 路由优化 

• ES中所谓的路由和IP网络不同，是一个类似于Tag的东西。在创建文档的时候，可以通过字段为文档增加一个路由属性的Tag。ES内在机制决定了拥有相同路由属性的文档，一定会被分配到同一个分片上，无论是主分片还是副本。那么，在查询的过程中，一旦指定了感兴趣的路由属性，ES就可以直接到相应的分片所在的机器上进行搜索，而避免了复杂的分布式协同的一些工作，从而提升了ES的性能。于此同时，假设机器1上存有路由属性A的文档，机器2上存有路由属性为B的文档，那么我在查询的时候一旦指定目标路由属性为A，即使机器2故障瘫痪，对机器1构不成很大影响，所以这么做对灾况下的查询也提出了解决方案。所谓的路由，本质上是一个分桶（Bucketing）操作。当然，查询中也可以指定多个路由属性，机制大同小异

• 转Elasticsearch模块功能之-路由（routing）https://blog.csdn.net/changong28/article/details/38427311

5:GC调优 

• 　　elasticSearch本质上是个Java程序，所以配置JVM垃圾回收器本身也是一个很有意义的工作。我们使用JVM的Xms和Xmx参数来提供指定内存大小，本质上提供的是JVM的堆空间大小，当JVM的堆空间不足的时候就会触发致命的OutOfMemoryException。这意味着要么内存不足，要么出现了内存泄露。处理GC问题，首先要确定问题的源头，一般有两种方案
• 开启ElasticSearch上的GC日志：在ES的配置文件elasticsearch.yml中有相关的属性可以配置
•  使用jstat命令：jstat命令可以帮助我们查看JVM堆中各个区的使用情况和GC的耗时情况。
•  生成内存Dump：最后的办法就是将JVM的堆空间转储到文件中去，实质上是对JVM堆空间的一个快照

　　想了解更多关于JVM本身GC调优方法请参考：http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html

• 采用G1垃圾回收机制代替默认CMS(得观察是否真的有必要)
• JAVA_OPTS="$JAVA_OPTS -XX:+UseG1GC"  
• JAVA_OPTS="$JAVA_OPTS -XX:MaxGCPauseMillis=200"