Elasticsearch是一个实时的分布式搜索引擎,为用户提供搜索服务,当我们决定存储某种数据时,在创建索引的时候需要数据结构完整确定下来,与此同时索引的设定和很多固定配置将不能改变。当需要改变索引结构时就需要重建索引。
下面介绍索引重建的3个方案:
方案一:外部数据导入方案
整体介绍
系统架构设计中,一般有关系型数据库用来存储数据,Elasticsearch在系统架构里起到查询加速的作用。如果是遇到索引重建的操作,待系统模块发布新版本后,可以从数据库中将数据查询出来,重新写入ES即可。
详细操作步骤
- 微服务模块从数据库里查询数据的总数和批次信息,将每个批次的分页信息发给MQ,分页信息包含查询条件和偏移量
- 微服务根据接收到的分页信息,从数据库获得数据,根据新索引结构的定义,将数据组装成JSON,并执行bulk命令,将数据写入es
方案特点
微服务模块实例可能会部署多个,数据是分批处理的,批次信息会一次性发给MQ,利用MQ的异步处理机制,可以充分的利用多实例的并发优势,加速数据重建的速度。
方案缺点
- 对数据库造成读取压力,短时间内大量的读操作,会占用数据库的硬件资源。
- 网络带宽占用多,从数据库写入ES会有大量的数据传输带宽占用
方案二:基于scroll+bulk+索引别名方案
整体介绍
利用java客户端做持续的scroll查询和bulk命令写入,数据自给自足,不依赖其他数据源。
执行步骤
假设原索引名称是item,新的索引名称为item_new,java客户端使用别名item_alias链接ES,该别名指向原索引item。
- 先建立一个别名
PUT /item/_alias/item_alias
- 新建索引item_new,将mapping信息等按新的格式定义好
- 使用scroll api将数据批量查询出来,这个1m就是保存搜索的上下文环境的时间。
GET /item/_search?scroll=1m
{
"query": {
"match_all": {}
},
"sort": ["_doc"],
"size": 2
}
- 采用bulk api将scroll查出来的数据,批量写入新索引
POST /_bulk
{"index":{"_index":"item_new","_id":"tr6YgYEB9TD2fYkcFzjY"}}
{"title":"小米手机","price":"2688","images":"http://image.lagou.com/12479122.jpg","createTime":"2022-02-01 12:02:02","lifecycle":1}
- 反复执行步骤3和4(注意步骤3中,需要指定上一次查询的scroll_id)
GET /_search/scroll
{
"scroll":"1m",
"scroll_id":"步骤3查出来的值"
}
- 切换别名item_alias到新的索引item_new上面,此时java客户端让使用别名访问,不需要修改代码,也不需要停机。
POST /_aliases
{
"actions": [
{
"remove": {
"index": "item",
"alias": "item_alias"
}
}
,{
"add": {
"index": "item_new",
"alias": "item_alias"
}
}
]
}
方案特点
在数据传输上自给自足,不依赖其他数据源。网络传输占用带宽较小。
另外在java客户端访问es集群时,使用别名是一个好习惯。
方案三:Reindex API方案
ES v6.3.1已经支持Reindex API,它对scroll、bulk做了一层封装,能够对文档重建索引不需要任何插件或外部工具。
- 基础使用:
POST _reindex
{
"source": {
"index": "item"
},
"dest": {
"index": "item_new"
}
}
注意: 如果不手动创建新索引book_new的mapping信息,那么Elasticsearch将启动自动映射模板对数据进行类型映射,可能不是期望的类型,这点要注意一下
- version_type属性
使用reindex api也是创建快照后再执行迁移的,这样目标索引的数据可能会与原索引有差异,version_type属性可以决定乐观锁并发处理的规则
POST _reindex
{
"source": {
"index": "item"
},
"dest": {
"index": "item_new",
"version_type": "internal"
}
}
version_type属性含义如下:
- internal:直接拷贝文档到目标索引,对相同的type、文档ID直接进行覆盖,默认值
- external:迁移文档到目标索引时,保留version信息,对目标索引中不存在的文档进行创建,已
存在的文档按version进行更新,遵循乐观锁机制
- op_type属性和conflicts属性
如果op_type设置为create,那么迁移时只在目标索引中创建ID不存在的文档,已存在的文档,会提示错误,如下请求:
POST _reindex
{
"source": {
"index": "item"
},
"dest": {
"index": "item_new",
"op_type": "create"
}
}
错误信息会比较多,如果加上"conflicts":"proceed"配置项,那么冲突信息将不展示,只展示冲突的文档数量,请求和响应结果将变成这样:
POST _reindex
{
"conflicts": "proceed",
"source": {
"index": "item"
},
"dest": {
"index": "item_new",
"op_type": "create"
}
}
- query支持
reindex api支持数据过滤、数据排序、size设置、_source选择等,也支持脚本执行。
POST _reindex
{
"size": 10,
"source": {
"index": "item",
"query": {
"term": {
"title": {
"value": "手机"
}
}
}
},
"dest": {
"index": "item_new",
"op_type": "create"
}
}