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

  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运维操作时对其可能的后果有充分了解。
posted @ 2019-06-19 23:52  Lhfcws  阅读(429)  评论(1)  编辑  收藏  举报