说明

Elasticsearch是一个实时的分布式搜索引擎，为用户提供搜索服务，当我们决定存储某种数据时，在创建索引的时候需要数据结构完整确定下来，与此同时索引的设定和很多固定配置将不能改变。当需要改变数据结构时就需要重建索引，为此，Elasticsearch团队提供了辅助工具帮助开发人员进行索引重建。

方案一:外部数据导入方案

整体介绍

系统架构设计中，有关系型数据库用来存储数据，Elasticsearch在系统架构里起到查询加速的作用，如果遇到索引重建的操作，待系统模块发布新版本后，可以从数据库将数据查询出来，重新灌到Elasticsearch即可

执行步骤

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

详细操作步骤

  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消息的异步处理机制，可以充分利用并发的优势，加快数据重建的速度。

    方案缺点

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

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

    整体介绍

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

    执行步骤

    假设原索引名称是book，新的索引名称为book_new，Java客户端使用别名book_alias连接Elasticsearch，该别名指向原索引book。
    1. 若Java客户端没有使用别名，需要给客户端分配一个: PUT /book/_alias/book_alias
    2. 新建索引book_new，将mapping信息，settings信息等按新的要求全部定义好。
    3. 使用scroll api将数据批量查询出来, 为了使用 scroll，初始搜索请求应该在查询中指定 scroll 参数，这可以告诉 Elasticsearch 需要保持搜索的上下文环境多久,1m 就是一分钟。
    1. GET /book/_search?scroll=1m
    2. {
    3. "query": {
    4. "match_all": {}
    5. },
    6. "sort": ["_doc"],
    7. "size": 2
    8. }

  3. 采用bulk api将scoll查出来的一批数据，批量写入新索引

    POST /_bulk { “index”: { “_index”: “book_new”, “_id”: “对应的id值” }} { 查询出来的数据值 }

  4. 反复执行修改后的步骤3和步骤4，查询一批导入一批，以后可以借助Java Client或其他语言的API支持。

注意做3时需要指定上一次查询的 scroll_id

  1. GET /_search/scroll 
  2. { 
  3.   "scroll": "1m", 
  4.   "scroll_id" : "步骤三中查询出来的值" 
  5. }
  1. 切换别名book_alias到新的索引book_new上面，此时Java客户端仍然使用别名访问，也不需要修

改任何代码，不需要停机。

  1. POST /_aliases 
  2. { 
  3.   "actions": [ 
  4.     { 
  5.       "remove": { 
  6.         "index": "book", 
  7.         "alias": "book_alias" 
  9.       }
  10.     }, 
  11.     { 
  12.       "add": { 
  13.         "index": "book_new", 
  14.         "alias": "book_alias" 
  16.       }
  17.     } 
  18.     ] 
  19. }
  1. 验证别名查询的是否为新索引的数据

    方案特点

    在数据传输上基本自给自足，不依赖于其他数据源，Java客户端不需要停机等待数据迁移，网络传输占用带宽较小。只是scroll查询和bulk提交这部分，数据量大时需要依赖一些客户端工具。

    补充一点

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

    Reindex API方案

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

    最基础的命令

    1. POST _reindex 
    2. { 
    3. "source": { 
    4.  "index": "book" 
    5. },
    6. "dest": { 
    7.  "index": "book_new" 
    8. } 
    9. }
    注意： 如果不手动创建新索引book_new的mapping信息，那么Elasticsearch将启动自动映射模板对数据进行类型映射，可能不是期望的类型，这点要注意一下。

    version_type 属性

    使用reindex api也是创建快照后再执行迁移的，这样目标索引的数据可能会与原索引有差异，
    version_type属性可以决定乐观锁并发处理的规则。
    reindex api可以设置version_type属性
    1. POST _reindex 
    2. { 
    3. "source": { 
    4.  "index": "book" 
    5. },
    6. "dest": { 
    7.  "index": "book_new",
    8.  "version_type": "internal"
    9. } 
    10. }
    version_type属性含义如下：
  • internal：直接拷贝文档到目标索引，对相同的type、文档ID直接进行覆盖，默认值
  • external：迁移文档到目标索引时，保留version信息，对目标索引中不存在的文档进行创建，已存在的文档按version进行更新，遵循乐观锁机制。

    op_type 属性和conflflicts 属性

    如果op_type设置为create，那么迁移时只在目标索引中创建ID不存在的文档，已存在的文档，会提示错误，如下请求：
    1. POST _reindex 
    2. { 
    3. "source": { 
    4.   "index": "book" 
    5. },
    6. "dest": { 
    7.   "index": "book_new", 
    8.   "op_type": "create" 
    9. }
    10. }

    query支持

    reindex api支持数据过滤、数据排序、size设置、_source选择等，也支持脚本执行
    1. POST _reindex 
    2. { 
    3. "size": 100, 
    4. "source": { 
    5.   "index": "book", 
    6.   "query": { 
    7.     "term": { 
    8.       "language": "english" 
    9.     } 
    10.   },
    11.   "sort": { 
    12.     "likes": "desc" 
    13.   } 
    14. },
    15. "dest": { 
    16.   "index": "book_new" 
    17. } 
    18. }

    小结

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