ElasticSearch性能调优

作者: 日期: 2021 年 10 月 16 日 发表评论 (0) 查看评论

目录

硬件环境选择

ES本身是磁盘使用密集型的服务，所以在磁盘能力提升后，集群整体性能会大幅度提高。如果有条件，尽可能使用SSD硬盘， 不错的CPU。ES的厉害之处在于ES本身的分布式架构以及lucene的特性。IO的提升，会极大改进ES的速度和性能。

  • 条件允许，强烈建议SSD，SSD相对机械磁盘具有超高的读写速度和稳定性。
  • 采用RAID0，可以提升写入速度。
  • 配置ES在多块磁盘同时进行读写。

系统拓朴设计

ES集群在架构拓朴时，一般都会采用Hot-Warm的架构模式，即设置3种不同类型的节点：Master节点、Hot 节点和 Warm节点。

内存

由于ES构建基于lucene, 而lucene设计强大之处在于lucene能够很好的利用操作系统内存来缓存索引数据，以提供快速的查询性能。lucene的索引文件segements是存储在单文件中的，并且不可变，对于OS来说，能够很友好地将索引文件保持在cache中，以便快速访问；因此，我们很有必要将一半的物理内存留给lucene ; 另一半的物理内存留给ES（JVM heap )。ES的查询严重依赖OS的File Cache，所以说内存分配的内存肯定是越多越好。最理想的情况就是FileCache的内存大小和存储的数据的大小差不多。即使达不到这个标准，最少也需要达到存储的数据的一半。所以， 在ES内存设置方面，可以遵循以下原则：

  1. 当机器内存小于64G时，遵循通用的原则，50%给ES，50%留给lucene。

  2. 当机器内存大于64G时，遵循以下原则：

    1. 如果主要的使用场景是全文检索, 那么建议给ES Heap分配 4~32G的内存即可；其它内存留给操作系统, 供lucene使用（segments cache), 以提供更快的查询性能。
    2. 如果主要的使用场景是聚合或排序， 并且大多数是numerics, dates, geo_points 以及not_analyzed的字符类型， 建议分配给ES Heap分配 4~32G的内存即可，其它内存留给操作系统，供lucene使用(doc values cache)，提供快速的基于文档的聚类、排序性能。
    3. 如果使用场景是聚合或排序，并且都是基于analyzed 字符数据，这时需要更多的 heap size, 建议机器上运行多ES实例，每个实例保持不超过50%的ES heap设置(但不超过32G，堆内存设置32G以下时，JVM使用对象指标压缩技巧节省空间)，50%以上留给lucene。

  3. 禁止swap，一旦允许内存与磁盘的交换，会引起致命的性能问题。 通过： 在elasticsearch.yml 中 bootstrap.memory_lock: true， 以保持JVM锁定内存，保证ES的性能。

  4. GC设置原则

    1. 保持GC的现有设置，默认设置为：Concurrent-Mark and Sweep (CMS)，别换成G1GC，因为目前G1还有很多BUG。
    2. 保持线程池的现有设置，目前ES的线程池较1.X有了较多优化设置，保持现状即可；默认线程池大小等于CPU核心数。如果一定要改，按公式（（CPU核心数* 3）/ 2）+ 1 设置；不能超过CPU核心数的2倍；但是不建议修改默认配置，否则会对CPU造成硬伤。

集群分片设置：

ES一旦创建好索引后，就无法调整分片的设置，而在ES中，一个分片实际上对应一个lucene 索引，而lucene索引的读写会占用很多的系统资源，因此，分片数不能设置过大；所以，在创建索引时，合理配置分片数是非常重要的。一般来说，我们遵循一些原则：

  1. 控制每个分片占用的硬盘容量不超过ES的最大JVM的堆空间设置（一般设置不超过32G，参加上文的JVM设置原则），因此，如果索引的总容量在500G左右，那分片大小在16个左右即可；当然，最好同时考虑原则2。

  2. 考虑一下node数量，一般一个节点有时候就是一台物理机，如果分片数过多，大大超过了节点数，很可能会导致一个节点上存在多个分片，一旦该节点故障，即使保持了1个以上的副本，同样有可能会导致数据丢失，集群无法恢复。所以， 一般都设置分片数不超过节点数的3倍。

减少副本数量

es的副本可以保证集群可用性，提高搜索并发能力，但是降低写入性能。 因为文档写入内容需要同步副本。

如果大批量导入可以关闭index.number_of_replicas:0，写入成功后在开启副本。

Mapping建模:

  1. 尽量避免使用nested或 parent/child，能不用就不用；nested query慢， parent/child query 更慢，比nested query慢上百倍；因此能在mapping设计阶段搞定的（大宽表设计或采用比较smart的数据结构），就不要用父子关系的mapping。

  2. 如果一定要使用nested fields，保证nested fields字段不能过多，目前ES默认限制是50。参考：

index.mapping.nested_fields.limit ：50

因为针对1个document, 每一个nested field, 都会生成一个独立的document, 这将使Doc数量剧增，影响查询效率，尤其是JOIN的效率。

  1. 避免使用动态值作字段(key),  动态递增的mapping，会导致集群崩溃；同样，也需要控制字段的数量，业务中不使用的字段，就不要索引。控制索引的字段数量、mapping深度、索引字段的类型，对于ES的性能优化是重中之重。以下是ES关于字段数、mapping深度的一些默认设置：

index.mapping.nested_objects.limit :10000

index.mapping.total_fields.limit:1000

index.mapping.depth.limit: 20

document 模型设计：对于 MySQL，我们经常有一些复杂的关联查询。在 es 里该怎么玩儿，es 里面的复杂的关联查询尽量别用，一旦用了性能一般都不太好。

最好是先在 Java 系统里就完成关联，将关联好的数据直接写入 es 中。搜索的时候，就不需要利用 es 的搜索语法来完成 join 之类的关联搜索了。

document 模型设计是非常重要的，很多操作，不要在搜索的时候才想去执行各种复杂的乱七八糟的操作。es 能支持的操作就是那么多，不要考虑用 es 做一些它不好操作的事情。如果真的有那种操作，尽量在 document 模型设计的时候，写入的时候就完成。另外对于一些太复杂的操作，比如 join/nested/parent-child 搜索都要尽量避免，性能都很差的。

索引优化设置：

1.减少refresh次数
Lucene为提高写性能会采用延迟写入方式，只是将数据写入内存中，当延迟大于1s时，会触发一次refresh，refresh会把内存中数据以段形式刷新到操作系统文件缓存系统中。

数据以段形式刷新到操作系统的文件系统后才可以进行搜索，所以如果搜索实时性要求不高，可以增加延迟，可以减少段数量，降低合并压力。

  • 设置refresh_interval 为-1，同时设置number_of_replicas 为0，通过关闭refresh间隔周期，同时不设置副本来提高写性能。
  1. 修改index_buffer_size 的设置，可以设置成百分数，也可设置成具体的大小，大小可根据集群的规模做不同的设置测试。

indices.memory.index_buffer_size：10%（默认）

indices.memory.min_index_buffer_size： 48mb（默认）

indices.memory.max_index_buffer_size

  1. 减少flush次数
    Translog数量达到512m会触发一次flush。主要为了把文件缓存系统中段数据持久化到磁盘，这个过程比较耗时，可以设置index.translog.flush_threshold_size参数修改缓存数据量，减少刷新次数，比如可以增加一倍。

修改translog相关的设置：

a. 控制数据从内存到硬盘的操作频率，以减少硬盘IO。可将sync_interval的时间设置大一些。

index.translog.sync_interval：5s(默认)。

b. 控制tranlog数据块的大小，达到threshold大小时，才会flush到lucene索引文件。

index.translog.flush_threshold_size：512mb(默认)

  1. _id字段的使用，应尽可能避免自定义_id, 以避免针对ID的版本管理；建议使用ES的默认ID生成策略或使用数字类型ID做为主键。

  2. _all字段及_source字段的使用，应该注意场景和需要，_all字段包含了所有的索引字段，方便做全文检索，如果无此需求，可以禁用；_source存储了原始的document内容，如果没有获取原始文档数据的需求，可通过设置includes、excludes 属性来定义放入_source的字段。

  3. 合理的配置使用index属性，analyzed 和not_analyzed，根据业务需求来控制字段是否分词或不分词。只有 groupby需求的字段，配置时就设置成not_analyzed, 以提高查询或聚类的效率。

查询优化：

  1. query_string 或 multi_match的查询字段越多， 查询越慢。可以在mapping阶段，利用copy_to属性将多字段的值索引到一个新字段，multi_match时，用新的字段查询。

  2. 日期字段的查询， 尤其是用now 的查询实际上是不存在缓存的，因此， 可以从业务的角度来考虑是否一定要用now, 毕竟利用query cache 是能够大大提高查询效率的。

  3. 查询结果集的大小不能随意设置成大得离谱的值， 如query.setSize不能设置成 Integer.MAX_VALUE， 因为ES内部需要建立一个数据结构来放指定大小的结果集数据。

  4. 尽量避免使用script，万不得已需要使用的话，选择painless & experssions 引擎。一旦使用script查询，一定要注意控制返回，千万不要有死循环（如下错误的例子），因为ES没有脚本运行的超时控制，只要当前的脚本没执行完，该查询会一直阻塞。

如： {

    “script_fields”：{

        “test1”：{

            “lang”：“groovy”，

            “script”：“while（true）{print 'don’t use script'}”

        }

    }

}

  1. 避免层级过深的聚合查询， 层级过深的group by , 会导致内存、CPU消耗，建议在服务层通过程序来组装业务，也可以通过pipeline的方式来优化。

  2. 复用预索引数据方式来提高AGG性能：

如通过 terms aggregations 替代 range aggregations， 如要根据年龄来分组，分组目标是: 少年（14岁以下） 青年（14-28） 中年（29-50） 老年（51以上）， 可以在索引的时候设置一个age_group字段，预先将数据进行分类。从而不用按age来做range aggregations, 通过age_group字段就可以了。

  1. Cache的设置及使用：

a) QueryCache: ES查询的时候，使用filter查询会使用query cache, 如果业务场景中的过滤查询比较多，建议将querycache设置大一些，以提高查询速度。

indices.queries.cache.size： 10%（默认），可设置成百分比，也可设置成具体值，如256mb。

当然也可以禁用查询缓存（默认是开启）， 通过index.queries.cache.enabled：false设置。

b) FieldDataCache: 在聚类或排序时，field data cache会使用频繁，因此，设置字段数据缓存的大小，在聚类或排序场景较多的情形下很有必要，可通过indices.fielddata.cache.size：30% 或具体值10GB来设置。但是如果场景或数据变更比较频繁，设置cache并不是好的做法，因为缓存加载的开销也是特别大的。

c) ShardRequestCache: 查询请求发起后，每个分片会将结果返回给协调节点(Coordinating Node), 由协调节点将结果整合。

如果有需求，可以设置开启;  通过设置index.requests.cache.enable: true来开启。

不过，shard request cache只缓存hits.total, aggregations, suggestions类型的数据，并不会缓存hits的内容。也可以通过设置indices.requests.cache.size: 1%（默认）来控制缓存空间大小。

  1. 不建议使用正则

批量写入

当大量的写任务时，可以采用批量提交的方案，但是需要考虑每次提交数据量的最优性能，这样可以根据网络情况，集群情况，数据大小控制批量写入的数量。

  • 可以一次批量写入5M～15M开始，直到性能没有提升时结束。
  • 逐渐增加并发数，使用监控工具观察CPU，IO，网络，内存等情况。
  • 如果抛出EsRejectedExecutionException错误，说明集群已经到达处理瓶颈了，可以适当增加集群节点。

自动生成_id

当写入端使用特定的id将数据写入ES时，ES会去检查对应的index下是否存在相同的id，这个操作会随着文档数量的增加而消耗越来越大，所以如果业务上没有强需求，建议使用ES自动生成的id，加快写入速率。

使用alias

生产提供服务的索引，切记使用别名提供服务，而不是直接暴露索引名称，避免后续因为业务变更或者索引数据需要reindex等情况造成业务中断。

避免宽表

在索引中定义太多字段是一种可能导致映射爆炸的情况，这可能导致内存不足错误和难以恢复的情况，这个问题可能比预期更常见，

只存储必要的索引字段

  1. 比如说你现在有一行数据。id,name,age .... 30 个字段。但是你现在搜索，只需要根据 id,name,age 三个字段来搜索。如果你傻乎乎往 es 里写入一行数据所有的字段，就会导致说 90% 的数据是不用来搜索的，结果硬是占据了 es 机器上的 filesystem cache 的空间，单条数据的数据量越大，就会导致 filesystem cahce 能缓存的数据就越少。其实，仅仅写入 es 中要用来检索的少数几个字段就可以了，比如说就写入es id,name,age 三个字段，然后你可以把其他的字段数据存在 mysql/hbase/MongoDB 里，我们一般是建议用 es + hbase 这么一个架构。也就是说把索引数据存储在ES中，先从ES中查到数据，构建记录的主键，然后根据主键去HBase(MongoDB)中根据主键去查其余的字段。

  2. hbase 的特点是适用于海量数据的在线存储，就是对 hbase 可以写入海量数据，但是不要做复杂的搜索，做很简单的一些根据 id 或者范围进行查询的这么一个操作就可以了。从 es 中根据 name 和 age 去搜索，拿到的结果可能就 20 个 doc id，然后根据 doc id 到 hbase 里去查询每个 doc id 对应的完整的数据，给查出来，再返回给前端。

  3. 写入 es 的数据最好小于等于，或者是略微大于 es 的 filesystem cache 的内存容量。然后你从 es 检索可能就花费 20ms，然后再根据 es 返回的 id 去 hbase 里查询，查 20 条数据，可能也就耗费个 30ms，可能你原来那么玩儿，1T 数据都放es，会每次查询都是 5~10s，现在可能性能就会很高，每次查询就是 50ms。

数据预热

提前或者定时的把热数据进行预热。

冷热数据分离

将冷数据写入一个索引中，然后热数据写入另外一个索引中。并且部署到不同的物理机上。保证热点数据访问的性能。

分页性能优化

不允许深度分页（默认深度分页性能很差）

跟产品经理说，你系统不允许翻那么深的页，默认翻的越深，性能就越差。

类似于 app 里的推荐商品不断下拉出来一页一页的

类似于微博中，下拉刷微博，刷出来一页一页的，你可以用 scroll api，关于如何使用，自行上网搜索。

使用合理的段合并

Lucene以段形式存储数据，当新数据创建索引时，会自动创建一个新段，所以在一个索引文件中包含多个段。数据越多后，索引段越多，需要消耗的文件句柄及cpu就越多。

Lucene后台服务会定期计算庞大的段合并工作量，所以：

  • 当段合并速度落后索引写入速度时，为避免堆积，es会把写索引线程数量降低到一个，并打印告警信息。
  • 为防止因为段合并影响搜索性能，es默认对段合并进行限制，默认20m/s。

参考资料

重点阅读

扩展阅读

ElasticSearch
发表评论？

0 条评论。

发表评论

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据。