首页 > 其他 > 详细

ElasticSearch经验小结 (Based on 5.x)

时间:2019-06-20 01:25:32      阅读:57      评论:0      收藏:0      [点我收藏+]

标签:port   rem   业务需求   amp   哈希   守护进程   war   分词   nali   

  1. ElasticSearch (ES)
    1.1 存储
  • 分片 shard
    官方:搜索场景下一个分片大小建议不要超过30G
    索引不能动态调整shard,ES非常鼓励reindex,因此索引不建议太大,一般手动按时间划分。对于更新型数据可能不太友好。

  • 内存
    官方:堆内建议不要超过32G,否则无法利用内存指针压缩优化,64-bit的地址表示会长一倍,被认为会比较影响性能
    官方&七牛:1G内存约可服务20~30G左右的索引数据。

  • 磁盘
    对性能比较重视的索引请尽量存在SSD,Lucene非常耗磁盘

  • 分词器
    字分词器会性能较低(尤其是match类查询),但是支持查询灵活
    词分词器会有可能难以适应业务查询需求变化和新词查询,但是性能和空间占用都较有优势
    一般来说分词器还是会妥协于业务需求,除非reindex代价不高。

1.2 写入

  • transport优于http
  • 控制bulk大小和频率
    官方:建议bulk的大小为单节点4m/s左右一批,但其实要考虑实际负载和对读的影响
    注意观察bulk thread_pool指标,如果bulk请求过多(比如异步写过快),则会引起EsRejectedException拒绝写入。在java client中需要自己去遍历response去确认是否成功,而不是依靠onFailure回调。

  • 控制refresh_interval去避免过于频繁的merge触发和提高写性能
    如实时索引要求不是太高可以适当把refresh_interval从默认的1s调整成10s或30s。

  • reindex或迁移等在5.x后尽量用官方的内部命令工具会比较快
  • 刷数时replica=0,刷完再恢复
  • mapping侧的写入优化主要侧重于减少索引分析(analyz优化等)、减少索引写入(_source exclude等)
  • Other: 还有一些比较极端的方法去提高写性能,比如禁止index warmup、提高index并行度等。需要根据实际业务场景去确定这些优化的风险。
    1.3 读取
  • 善用filter做缓存且防止数据打分排序 bool-filter
  • 能用term代替match/match_phrase的尽量用term
  • 时间戳不需要毫秒级的尽量使用秒级

  • 尽量不要从ES scroll太多数据,如有需求尽量只scroll id。
  • range查询不要用字符串,尽量用数值
  • script真的很慢
  • cardinality太多的维度慎做agg,hyperloglog算法不精确

  • 一致性
    ES支持读写时主从一致性配置,一般情况下都是异步写replica的弱一致性(最终一致性)以提高吞吐率和写性能。此时需注意不同副本间的一致性问题,可以利用 _preference 参数做哈希来解决。

1.4 GC优化

  • JDK 1.7+ && CMS优化:
    -Xmx30g –Xms30g -Xmn512m -Xss256k
    -XX:MaxPermSize=256m -XX:SurvivorRatio=2
    -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
    -XX:+CMSParallelRemarkEnabled -XX:MaxTenuringThreshold=15
    -XX:+UseCMSCompactAtFullCollection -XX:+UseCMSInitiatingOccupancyOnly
    -XX:CMSInitiatingOccupancyFraction=75 -XX:-DisableExplicitGC

GC情况最后依然还需根据实际自己的情况进行调整。
JDK 1.8.100+ 的版本G1GC才能用,之前版本的G1GC都会导致Lucene数据丢失。

1.5 监控
方案:ELK、Grafana + 时序数据库(Opentsdb)/监控系统(OpenFalcon)等
指标:JVM (GC、Heap、OffHeap等)、query数目与耗时、fetch数目与耗时、flush、refresh、merge、slow query、集群基础监控。

另:记得对ElasticSearch做自动拉起的守护进程,默认5min内拉起的话不会触发分片reroute。

1.6 Linux

  • 关闭大页 Tuning transparent huge pages (THP) off
  • 禁止swap Set vm.swappiness = 0
  • 关闭NUMA vm.zone_reclaim_mode = 0

以上操作系统配置基本适用于持续服务的高读性能数据存储集群,包括但不仅限于HBase、ES等。
1.7 部署

  • master节点:尽量与data node 分开,至少三台
  • client 节点:对于大集群建议划分,将一些需要聚合的请求利用client node去做导流,即使挂了也方便恢复。
  • tribe节点:跨集群连接性节点,不与data node合部。

1.8 备份与容灾

  • Quorum的Master选举机制
  • 索引备份机制基于replica,线上索引至少设为1,也有利于做读负载均衡
  • 集群备份可以利用 ES snapshot/restore机制去做,用户视角可做到增量备份,可以选择备份到HDFS(默认3副本,注意磁盘空间)
  • ES非常鼓励reindex,因此有些操作(比如分片强制assign)的后果会比较不care数据(有可能会清空)。因此请注意做ES运维操作时对其可能的后果有充分了解。

ElasticSearch经验小结 (Based on 5.x)

标签:port   rem   业务需求   amp   哈希   守护进程   war   分词   nali   

原文:https://www.cnblogs.com/lhfcws/p/11055833.html

(0)
(0)
   
举报
评论 一句话评论(0
0条  
登录后才能评论!
© 2014 bubuko.com 版权所有 鲁ICP备09046678号-4
打开技术之扣,分享程序人生!
             

鲁公网安备 37021202000002号