Elasticsearch系列---实战零停机重建索引

前言

我们使用Elasticsearch索引文档时，最理想的情况是文档JSON结构是确定的，数据源源不断地灌进来即可，但实际情况中，没人能够阻拦需求的变更，在项目的某个版本，可能会对原有的文档结构造成冲击，增加新的字段还好，如果要修改原有的字段，只能重建索引了。

概要

本篇以实战方式讲解如何零停机完成索引重建的三种方案。

外部数据导入方案

整体介绍

系统架构设计中，有关系型数据库用来存储数据，Elasticsearch在系统架构里起到查询加速的作用，如果遇到索引重建的操作，待系统模块发布新版本后（若重建索引不是因为客户端修改导致的，可以不停机发版，直接操作），可以从数据库将数据查询出来，重新灌到Elasticsearch即可。

执行步骤

建议的功能方案：数据库 + MQ + 应用模块 + Elasticsearch，可以在MQ控制台发送MQ消息来触发重导数据，按批次对数据进行导入，整个过程异步化处理，请求操作示意如下所示：

详细操作步骤：

  1. 通过MQ的web控制台或cli命令行，发送指定的MQ消息
  2. MQ消息被微服务模块的消费者消费，触发ES数据重新导入功能
  3. 微服务模块从数据库里查询数据的总数及批次信息，并将每个数据批次的分页信息重新发送给MQ消息，分页信息包含查询条件和偏移量，此MQ消息还是会被微服务的MQ消息者接收处理。
  4. 微服务根据接收的查询条件和分页信息，从数据库获取到数据后，根据索引结构的定义，将数据组装成ES支持的JSON格式，并执行bulk命令，将数据发送给Elasticsearch集群。

这样就可以完成索引的重建工作。

方案特点

MQ中间件的选型不做具体要求，常见的rabitmq、activemq、rocketmq等均可。

在微服务模块方面，提供MQ消息处理接口、数据处理模块需要事先开发的，一般是创建新的索引时，配套把重建的功能也一起做好。整体功能共用一个topic，针对每个索引，有单独的结构定义和MQ消息处理tag，代码尽可能复用。处理的批次大小需要根据实际的情况设置。

微服务模块实例会部署多个，数据是分批处理的，批次信息会一次性全部先发送给MQ，各个实例处理的数据相互不重叠，利用MQ消息的异步处理机制，可以充分利用并发的优势，加快数据重建的速度。

方案缺点

  1. 对数据库造成读取压力，短时间内大量的读操作，会占用数据库的硬件资源，严重时可能引起数据库性能下降。
  2. 网络带宽占用多，数据毕竟是从一个库传到另一个库，虽说是内网，但大量的数据传输带宽占用也需要注意。
  3. 数据重建时间稍长，跟迁移的数据量大小有关。

基于scroll+bulk+索引别名方案

整体介绍

利用Elasticsearch自带的一些工具完成索引的重建工具，当然在方案实际落地时，可能也会依赖客户端的一些功能，比如用Java客户端持续的做scroll查询、bulk命令的封装等，但与上一方案相比，最明显的区别就是：数据完全自给自足，不依赖其他数据源。

执行步骤

假设原索引名称是music，新的索引名称为music_new，Java客户端使用别名music_alias连接Elasticsearch，该别名指向原索引music。

  1. 若Java客户端没有使用别名，需要给客户端分配一个:
    PUT /music/_alias/music_alias
  2. 新建索引music_new，将mapping信息，settings信息等按新的要求全部定义好。
  3. 使用scroll api将数据批量查询出来
GET /music/_search?scroll=1m
{
    "query": {
        "match_all": {}
    },
    "sort": ["_doc"],
    "size":  1000
}
  1. 采用bulk api将scoll查出来的一批数据，批量写入新索引
POST /_bulk
{ "index":  { "_index": "music_new", "_type": "children", "_id": "1" }}
{ "name":    "wake me, shake me" }
  1. 反复执行步骤3和步骤4，查询一批导入一批，可以借助Java Client或其他语言的API支持。
  2. 切换别名music_alias到新的索引music_new上面，此时Java客户端仍然使用别名访问，也不需要修改任何代码，不需要停机。
POST /_aliases
{
    "actions": [
        { "remove": { "index": "music", "alias": "music_alias" }},
        { "add":    { "index": "music_new", "alias": "music_alias" }}
    ]
}
  1. 验证别名查询的是否为新索引的数据

方案特点

在数据传输上基本自给自足，不依赖于其他数据源，Java客户端不需要停机等待数据迁移，网络传输占用带宽较小。

只是scroll查询和bulk提交这部分，数据量大时需要依赖一些客户端工具。

补充一点

在Java客户端或其他客户端访问Elasticsearch集群时，使用别名是一个好习惯。

Reindex API方案

Elasticsearch v6.3.1已经支持Reindex API，它对scroll、bulk做了一层封装，能够 对文档重建索引而不需要任何插件或外部工具。

最基础的命令：

POST _reindex
{
  "source": {
    "index": "music"
  },
  "dest": {
    "index": "music_new"
  }
}

响应结果：

{
  "took": 180,
  "timed_out": false,
  "total": 4,
  "updated": 0,
  "created": 4,
  "deleted": 0,
  "batches": 1,
  "version_conflicts": 0,
  "noops": 0,
  "retries": {
    "bulk": 0,
    "search": 0
  },
  "throttled_millis": 0,
  "requests_per_second": -1,
  "throttled_until_millis": 0,
  "failures": []
}

注意：
如果不手动创建新索引music_new的mapping信息，那么Elasticsearch将启动自动映射模板对数据进行类型映射，可能不是期望的类型，这点要注意一下。

version_type 属性

使用reindex api也是创建快照后再执行迁移的，这样目标索引的数据可能会与原索引有差异，version_type属性可以决定乐观锁并发处理的规则。

reindex api可以设置version_type属性，如下：

POST _reindex
{
  "source": {
    "index": "music"
  },
  "dest": {
    "index": "music_new"
    "version_type": "internal"
  }
}

version_type属性含义如下：

  • internal：直接拷贝文档到目标索引，对相同的type、文档ID直接进行覆盖，默认值
  • external：迁移文档到目标索引时，保留version信息，对目标索引中不存在的文档进行创建，已存在的文档按version进行更新，遵循乐观锁机制。

op_type 属性和conflicts 属性

如果op_type设置为create，那么迁移时只在目标索引中创建ID不存在的文档，已存在的文档，会提示错误，如下请求：

POST _reindex
{
  "source": {
    "index": "music"
  },
  "dest": {
    "index": "music_new",
    "op_type": "create"
  }
}

有错误提示的响应，节选部分：

{
  "took": 11,
  "timed_out": false,
  "total": 5,
  "updated": 0,
  "created": 1,
  "deleted": 0,
  "batches": 1,
  "version_conflicts": 4,
  "noops": 0,
  "retries": {
    "bulk": 0,
    "search": 0
  },
  "throttled_millis": 0,
  "requests_per_second": -1,
  "throttled_until_millis": 0,
  "failures": [
    {
      "index": "music_new",
      "type": "children",
      "id": "2",
      "cause": {
        "type": "version_conflict_engine_exception",
        "reason": "[children][2]: version conflict, document already exists (current version [17])",
        "index_uuid": "dODetUbATTaRL-p8DAEzdA",
        "shard": "2",
        "index": "music_new"
      },
      "status": 409
    }
   ]
}

如果加上"conflicts": "proceed"配置项，那么冲突信息将不展示，只展示冲突的文档数量，请求和响应结果将变成这样：

请求：

POST _reindex
{
  "conflicts": "proceed",
  "source": {
    "index": "twitter"
  },
  "dest": {
    "index": "new_twitter",
    "op_type": "create"
  }
}

响应:

{
  "took": 12,
  "timed_out": false,
  "total": 5,
  "updated": 0,
  "created": 1,
  "deleted": 0,
  "batches": 1,
  "version_conflicts": 4,
  "noops": 0,
  "retries": {
    "bulk": 0,
    "search": 0
  },
  "throttled_millis": 0,
  "requests_per_second": -1,
  "throttled_until_millis": 0,
  "failures": []
}

query支持

reindex api支持数据过滤、数据排序、size设置、_source选择等，也支持脚本执行，这里提供一个简单示例：

POST _reindex
{
  "size": 100,
  "source": {
    "index": "music",
    "query": {
      "term": {
        "language": "english"
      }
    },
    "sort": {
      "likes": "desc"
    }
  },
  "dest": {
    "index": "music_new"
  }
}

小结

本篇介绍了零停机索引重建操作的三个方案，从自研功能、scroll+bulk到reindex，我们作为Elasticsearch的使用者，三个方案的参与度是逐渐弱化的，但稳定性却是逐渐上升的，我们需要清楚地去了解各个方案的优劣，适宜的场景，然后根据实际的情况去权衡，哪个方案更适合我们的业务模型，仅供参考，谢谢。

专注Java高并发、分布式架构，更多技术干货分享与心得，请关注公众号：Java架构社区
可以扫左边二维码添加好友，邀请你加入Java架构社区微信群共同探讨技术

原文地址：https://www.cnblogs.com/huangying2124/p/12208348.html

时间： 2024-07-30 12:23:01

Elasticsearch系列---实战零停机重建索引的相关文章

ELK学习总结（4-1）elasticsearch更改mapping(不停服务重建索引)

elasticsearch更改mapping(不停服务重建索引)原文 http://donlianli.iteye.com/blog/1924721Elasticsearch的mapping一旦创建,只能增加字段,而不能修改已经mapping的字段.但现实往往并非如此啊,有时增加一个字段,就好像打了一个补丁,一个可以,但是越补越多,最后自己都觉得惨不忍睹了.怎么办??这里有一个方法修改mapping,那就是重新建立一个index,然后创建一个新的mapping.你可能会问,这要是在生产环境,可行

Elasticsearch如何修改Mapping结构并实现业务零停机

Elasticsearch 版本:6.4.0 一.疑问 在项目中后期,如果想调整索引的 Mapping 结构,比如将 ik_smart 修改为 ik_max_word 或者 增加分片数量 等,但 Elasticsearch 不允许这样修改呀,怎么办? 常规 解决方法: 根据最新的 Mapping 结构再创建一个索引 将旧索引的数据全量导入到新索引中 告知用户,业务要暂停使用一段时间 修改程序,将索引名替换成新的索引名称,打包,重新上线 告知用户,服务可以继续使用了,并说一声抱歉 我认为最大的弊端

Linux下零基础学C语言、C++系列实战视频教程

Linux下零基础跟我学C语言.C++系列实战教程(入门篇.项目实战与提高篇.软件设计与工程实践篇)适合人群:初级课时数量:194课时用到技术:C++涉及项目:windows版服务器端开发咨询qq:1840215592Linux下零基础学C语言.C++系列实战视频教程详细介绍:http://www.dwz.cn/Fk3mk1.1跟我一起学C(linux)课程详细介绍01.从helloworld程序认识计算机(一)Helloword程序什么是程序程序语言C程序执行环境02.从helloworld程

（57）ElasticSearch重建索引且保证应用程序不用重启

ElasticSearch中字段的类型一旦确定就不能修改,如果我们要修改其类型就要重新建mapping.然后把旧索引中的数据批量导入到新索引中.同时采用给索引起别名的方式使客户端应用程序不需要重启. 1.演示字段类型一旦确定不能修改 添加文档,同时默认创建了索引 PUT index1/type1/1 { "content":"2000-11-11" } 查询字段类型,content类型为date GET index1/type1/_mapping { "i

sql优化实战：从1353秒到135秒（删除索引+修改数据+重建索引）

最近在优化日结存储过程,日结存储过程中大概包含了20多个存储过程. 发现其有一个存储过程代码有问题,进一步发现结存的数据中有一个 日期字段business_date 是有问题的,这个字段对应的类型是varchar,但是存储过程传入参数的类型是char,导致最后结存进去的数据末尾多了几个空格. 比如,应该是'2016-12'的,但现在是'2016-12  '. 为了解决这个问题,要修改这个字段的值,去掉尾部的空格,于是运行如下语句: [sql] view plain copy print? upd

66.零停机下reindex

主要知识点: 理解reindex的使用场景和必要性 学会reindex 一.理解reindex的使用场景和必要性 假设:在某一个index中依靠dynamic mapping插入数据,但是不小心有些数据是2017-01-01这种日期格式的,所以title这个field被插入2017-01-01这条数据之后就被es自动映射为了date类型,实际上它应该是string类型的.如果后面有"hello word"这个格式的数据插入时就会报错,在这种情况下,是不能修改原index下的mappin

elasticsearch技术实战——第一篇（使用篇）

为了提高搜索命中率和准确率,改善现有羸弱的搜索功能,公司决定搭建全文搜索服务.由于之前缺乏全文搜索使用经验,经过一番折腾,终于不负期望按期上线.总结了一些使用心得体会,希望对大家有所帮助.计划分三篇: 第一篇(使用篇),主要讲解基本概念.分词.数据同步.搜索API. 第二篇(配置及参数调优篇),主要围绕JVM参数调优.异常排查.安全性等方面讲解. 第三篇(倒排索引原理篇),知其然知其所以然. 一.技术选型 说到全文搜索大家肯定会想到solr和elasticsearch(以下简称es),两者都是基

ES重建索引(reindex)性能优化建议

Reindex官方文档 https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-reindex.html Reindex简介 5.X版本后新增Reindex.Reindex可以直接在Elasticsearch集群里面对数据进行重建,如果你的mapping因为修改而需要重建,又或者索引设置修改需要重建的时候,借助Reindex可以很方便的异步进行重建,并且支持跨集群间的数据迁移.比如按天创建的索引可以定期重建合并到以

java实战系列-实战中MAVEN私服的搭建

 实战中MAVEN私服的搭建 利用maven来管理项目的构建,报告和文档已经成为了我们现在的共识,任何开源软件基本都在使用,当然我们现在的大部分公司也基本都在使用,我把以前使用maven的一些经验在进行加工呈现给大家,希望可以帮助一些当前正在学习maven的初学者们还有刚毕业的学子们! 我会结合Eclipse+nexus+maven的实践来个大家做介绍! Nexus是Maven仓库管理器,虽然我们可以从Maven中央仓库下载所需要的构件(artifact),但这样会让我们的编译过程变得相当的慢