目录
1.基本介绍
2.使用场景
3.相关操作
3.1 覆盖更新
3.2 创建不存在的文档并更新旧版本的文档
3.3 仅创建不存在的文档
3.4 导入符合条件的数据/添加查询条件
3.5 从多个源索引中一起复制
3.6 限制处理的文档数
3.7 只同步源index里部分字段
3.8 屏蔽掉不想同步的字段
3.9 修改字段名称
3.10 为新索引中设置的新字段赋值
3.11 script中需要设置多个修改
3.12 将reindex任务设置为后台运行
4.性能优化
4.1 增加批量写入的每批次数量
4.2 提高scroll的并行度/分片设置
5.参考文档
1.基本介绍
Reindex会将一个索引的数据复制到另一个已存在的索引，但是并不会复制原索引的mapping（映射）、shard（分片）、replicas（副本）等配置信息。
ES官方提供了_reindex这一API，相比于使用bulk重新导入数据的速度更快，其核心是做跨索引、跨集群的数据迁移。
在运行_reindex操作前，应当先根据复制源索引及存储需求创建新的目标索引，报错设置mapping映射、分片、副本等。
2.使用场景
1.分片数变更：当你的数据量过大，而你的索引最初创建的分片数量不足，导致数据入库较慢的情况，此时需要扩大分片的数量，此时可以尝试使用Reindex。
2.mapping字段变更：当数据的mapping需要修改，但是大量的数据已经导入到索引中了，重新导入数据到新的索引太耗时；但是在ES中，一个字段的mapping在定义并且导入数据之后是不能再修改的，所以这种情况下也可以考虑尝试使用Reindex。
3.分词规则修改，比如使用了新的分词器或者对分词器自定义词库进行了扩展，而之前保存的数据都是按照旧的分词规则保存的，这时候必须进行索引重建。
3.相关操作
3.1 覆盖更新
"version_type": "internal"，internal表示内部的，省略version_type或version_type设置为 internal 将导致 Elasticsearch 盲目地将文档转储到目标中，覆盖任何具有相同类型和 ID 的文件。
这也是最常见的重建方式。
POST _reindex
{"source": {"index": "twitter"},"dest": {"index": "new_twitter","version_type": "internal"}
}3.2 创建不存在的文档并更新旧版本的文档
"version_type": "external"，external表示外部的，将 version_type 设置为 external 将导致 Elasticsearch 保留源中的版本，创建任何丢失的文档，并更新目标索引中版本比源索引中版本旧的任何文档。
id不存在的文档会直接更新；id存在的文档会先判断版本号，只会更新版本号旧的文档。
POST _reindex
{"source": {"index": "twitter"},"dest": {"index": "new_twitter","version_type": "external"}
}3.3 仅创建不存在的文档
要创建的 op_type 设置将导致 _reindex 仅在目标索引中创建丢失的文档，所有存在的文档都会引起版本冲突。
只要两个索引中存在id相同的记录，就会引起版本冲突。
POST _reindex
{"source": {"index": "twitter"},"dest": {"index": "new_twitter","op_type": "create"}
}ps：关于version_type的internal、external以及op_type间的区别阐述，可参考下方链接🔗中的第一个回复，比较容易理解（新引入的external_gte判断类似）
[reindex问题 - Elastic 中文社区 (elasticsearch.cn)] reindex问题 - 搜索客，搜索人自己的社区
3.4 导入符合条件的数据/添加查询条件
POST _reindex
{"source": {"index": "twitter","query": {"term": {"user": "kimchy"}}},"dest": {"index": "new_twitter"}
}3.5 从多个源索引中一起复制
适用于多个源索引间mapping一致的情况
POST _reindex
{"source": {"index": ["twitter", "blog"]},"dest": {"index": "all_together"}
}3.6 限制处理的文档数
例如希望按时间倒排后只复制前1w条到新索引中
POST _reindex
{"size": 10000,"source": {"index": "twitter","sort": { "date": "desc" }},"dest": {"index": "new_twitter"}
}3.7 只同步源index里部分字段
POST _reindex
{"source": {"index": "pigg_test","_source": ["name", "age"]},"dest": {"index": "pigg_test2"}
}3.8 屏蔽掉不想同步的字段
POST _reindex
{"source": {"index": "pigg_test","_source": {"excludes": ["name"]}},"dest": {"index": "pigg_test2"}
}3.9 修改字段名称
原索引
POST my-index-000001/_doc/1?refresh
{"text": "words words","flag": "foo"
}reindex重建索引，将原索引中的flag字段变更为tag字段导入新索引中（ps：原索引中字段名不会受到影响）
POST _reindex
{"source": {"index": "my-index-000001"},"dest": {"index": "my-new-index-000001"},"script": {"source": "ctx._source.tag = ctx._source.remove(\"flag\")"}
}结果为
GET my-new-index-000001/_doc/1
{"_index" : "my-new-index-000001","_type" : "_doc","_id" : "1","_version" : 1,"_seq_no" : 0,"_primary_term" : 1,"found" : true,"_source" : {"text" : "words words","tag" : "foo"}
}3.10 为新索引中设置的新字段赋值
新索引
PUT my-new-index-000001
{"mappings": {"properties": {"flag" : {"type" : "text","fields" : {"keyword" : {"type" : "keyword","ignore_above" : 256}}},"Type": {"type": "keyword"}}}
}只转移原索引中“flag”字段的数据并将新字段“Type”设置为“testaa”
POST _reindex
{"source": {"index": "my-index-000001","_source":["flag"]},"dest": {"index": "my-new-index-000001"},"script": {"source": "ctx._source.Type = 'testaa'"}
}3.11 script中需要设置多个修改
POST _reindex
{"source": {"index": "my-index-000001","_source":["flag"]},"dest": {"index": "my-new-index-000001"},"script": {"source": """ctx._source.Type = 'article';ctx._source.tag = ctx._source.remove('flag')"""}
}3.12 将reindex任务设置为后台运行
POST _reindex?wait_for_completion=false通过将wait_for_completion 设为 false，可以将 reindex 在后台运行，将请求转为异步任务，这时 reindex 会返回一个 task_id，根据这个 task_id 可以监控 reindex 的进度
GET _tasks/task_id获取reindex任务列表
GET _tasks?detailed=true&actions=*reindex4.性能优化
常规的如果我们只是进行少量的数据迁移利用普通的reindex就可以很好的达到要求，但是当我们发现我们需要迁移的数据量过大时，我们会发现reindex的速度会变得很慢。
原因分析：
reindex的核心做跨索引、跨集群的数据迁移。
慢的原因及优化思路无非包括：
1）批量大小值可能太小。需要结合堆内存、线程池调整大小；
2）reindex的底层是scroll实现，借助scroll并行优化方式，提升效率；
3）跨索引、跨集群的核心是写入数据，考虑写入优化角度提升效率。
可行方案：
1）提升批量写入的大小值size
2）通过设置sliced提高写入的并行度
不过！！大部分情况下操作生产数据的时候，应该首要考虑保证正常线上服务的查询性能与稳定性。reindex的性能在次要位置。
4.1 增加批量写入的每批次数量
默认情况下 _reindex 使用 1000 的滚动批次。可以使用源元素source中的 size 字段更改批次大小：
POST _reindex
{"source": {"index": "pigg_test","size": 5000},"dest": {"index": "pigg_test2"}
}4.2 提高scroll的并行度/分片设置
Reindex 支持 Sliced Scroll 来并行化重新索引过程。 这种并行化可以提高效率并提供一种将请求分解为更小的部分的便捷方式。
每个Scroll请求，可以分成多个Slice请求，可以理解为切片，各Slice独立并行，利用Scroll重建或者遍历要快很多倍。
slicing的设定分为两种方式：手动设置分片、自动设置分片。
自动设置分片如下：
POST _reindex?slices=5&refresh
{"source": {"index": "twitter"},"dest": {"index": "new_twitter"}
}slices大小设置注意事项：
1）slices大小的设置可以手动指定，或者设置slices设置为auto，auto的含义是：针对单索引，slices大小=分片数；针对多索引，slices=分片的最小值。
Setting
slicestoautowill let Elasticsearch choose the number of slices to use. This setting will use one slice per shard, up to a certain limit. If there are multiple sources, it will choose the number of slices based on the index or backing index with the smallest number of shards.
2）当slices的数量等于索引中的分片数量时，性能最高效。slices大小大于分片数，非但不会提升效率，反而会增加开销。
3）如果这个slices数字很大(例如500)，建议选择一个较低的数字，因为过大的slices 会影响性能。
PS：在实际操作中，在生产环境上进行远程reindex，需要考虑到slices大小对线上正常查询服务查询性能的影响以及要顾及线上生产服务的稳定性。
5.参考文档
[Reindex API | Elasticsearch Guide [8.7] | Elastic] Reindex API | Elasticsearch Guide [8.14] | Elastic
[Scripting | Elasticsearch Guide [8.7] | Elastic] Scripting | Elasticsearch Guide [8.14] | Elastic
[reindex问题 - Elastic 中文社区 (elasticsearch.cn)] reindex问题 - 搜索客，搜索人自己的社区
[Reindex from a remote cluster | Elasticsearch Guide [8.7] | Elastic] Reindex from a remote cluster | Elasticsearch Guide [8.14] | Elastic