巧用ingest pipeline实现Elasticsearch索引的重定向

时间:2022-07-27
本文章向大家介绍巧用ingest pipeline实现Elasticsearch索引的重定向,主要内容包括其使用实例、应用技巧、基本知识点总结和需要注意事项,具有一定的参考价值,需要的朋友可以参考一下。

背景

在Elasticsearch的日常使用过程中,常常会碰到如下问题:

  1. 索引的分片数量设置的较少,集群中只有部分节点承担写入压力,导致出现热点,写入性能一直无法提升。
  2. 当前正在执行写入的索引因为某些配置不满足需求但又无法动态更新该配置,需要根据新的索引模板创建新索引承担写入。

对于第1个问题,在7.x版本的集群中比较常见,因为所以默认只有1分片1副本,该问题的一种解决方式就是切换一个新的索引进行写入,提高新的索引的分片数量(最好保持为节点数量的倍数),使得写入并行度提高,从而提高写入吞吐率。

第2个问题往往出现在以下场景中:

  • 想要开启对索引的最优压缩以节省存储成本,比如指定codec为best_compression
  • 在6.8版本的集群中,索引默认是不开启soft_deletes的(index.soft_deletes.enabled默认为false), 导致对于已经创建好的索引,不能使用CCR跨集群复制功能。
  • 跨集群数据迁移过程中,需要切换一个新的索引承担写入,老的索引通过snapshot方式迁移至新的集群,新的索引因为文档数量较少可以使用logstash、reindex、CCR进行跨集群数据同步。

但是如果业务端不能修改写入的索引名称,或者是无法更新诸如logstash、filebeat的配置文件并进行重启,这时候该怎么办呢?

既然业务端不能有任何变更,那就不能够直接使用索引别名了,因为对于已经存在的索引,是无法创建同名称的别名的。当然,如果业务端一开始使用的就是别名,那就另当别论了,直接修改is_write_index配置项就可以切换索引了。

所以,对于业务端不能有任何变更,但是需要切换索引写入的场景,我们可以使用ES的default pipeline 来实现索引的重定向: 写入时指定了一个索引,实际上写入到了另外一个索引。

实战过程

default pipeline 与final pipeline

default pipeline与final pipeline实际上都是普通的ingest pipeline,只是和一般的pipeline执行时机不同;default pipeline的执行时机是当前写入请求没有指定pipeline时,final pipeline的执行时机是在所有pipeline执行完毕后,具体如图所示:

如果当前bulk或者index请求指定了pipeline参数,则会先执行自定义的普通pipeline,所有的pipelie执行完毕后在执行final pipeline(如果索引的显式的设置了index.final_pipeline);如果当前bulk或者index请求没有指定pipeline,当索引显式的设置了index.default_pipeline参数时,则会先执行default pipeline,然后再执行final pipeline。

索引重定向

使用set ingest processor可以对当前写入的索引名称_index字段进行重新赋值, 如下图所示:

因此我们可以创建一个pipeline, 将其配置为当前正在写入的索引的default pipeline,从而实现把所以重定向写入到另外一个索引中:

定义pipeline

PUT _ingest/pipeline/redirect
{
  "description": "_description",
  "processors": [
    {
      "set": {
        "field": "_index",
        "value": "new_index"
      }
    }
  ]
}

设置default_pipeline

PUT test/_settings
{
  "index.default_pipeline": "redirect"
}

经过上述设置后,可以发现,向test索引写入的数据已经全部写入到了new_index索引。

为什么不用final pipeline呢?因为final pipeline强制要求不能进行索引的重新命名(可能因为需要避免出现循环)。

存在的问题

使用default pipeline,使得在业务端不用做任何变更的情况下,将数据写入到一个新的索引中去,但是该方式还存在以下问题:

  • 性能问题:使用ingest pipeline是会带来一定的性能损耗的,pipeline的处理过程中需要遍历每个document,节点的cpu使用率势必会上升,在集群资源充足的情况下或者索引本身写入速率不高的情况下可以使用该方式解决索引切换的问题。
  • 查询方式的问题:虽然解决了写入索引切换的问题,但是数据存储到新的索引中去了,查询时就必须去查询新的索引;如果业务使用的是通配符的方式去查询,则非常好解决,只需要把新索引命名为老的索引名称再增加一个后缀即可,不能使用通配符的方式查询索引的话,就不能使用该方式切换写入的索引了。