reindex是5.X版本后新增的，主要用于对index级的数据进行重建。如果你的mapping里某个类型有修改或者你需要迁移数据那就可以借助reindex来完成，它很方便的进线异步重建，并且还支持跨集群。它的语法也特别简单：

curl -X POST "localhost:9200/_reindex" -H 'Content-Type: application/json' -d'
{"source": {"remote": {"host": "http://otherhost:9200;,"username": "user","password": "pass"},"index": "source","query": {"match": {"test": "data"}}},"dest": {"index": "dest"}
}
'

虽然它很棒，但在数据量特别大（30g以上）的情况下速度非常慢，即使是同集群内上大约不到5M/s的写入速度，但CPU还是IO使用率都很低。

纠其原理

• reindex的底层是是通过scroll实现，能否借助并行优化

• 批量值（size）值可能太小导致5M/s

• 写入数据索引流程还可以优化，提升tps

1.借助scroll的sliced参数提升并发

reindex的底层是是通过scroll实现,每个Scroll请求，可以分成多个Slice请求，可以理解为切片，各Slice独立并行，利用Scroll重建或者遍历要快很多倍。

POST localhost:9200/_reindex?slices=5

slices大小设置注意事项（手动设置分片、自动设置分片）：

1. slices大小的设置可以为auto（针对单索引，slices大小=分片数；针对多索引，slices=分片的最小值）

2. 当slices的数量等于索引中的分片数量时，查询性能最高效。slices大小大于分片数，非但不会提升效率，反而会增加开销

2.根据文档体积大小逐步递增提升批量索引请求

如果每批索引1000个文档（1000个文档是1mb），调整size值从大约5-15 MB的大容量开始，直到你看不到性能的提升

POST  localhost:9200/_reindex
{"source": {"index": "twitter","size": 5000},"dest": {"index": "new_twitter"}
}

3写入数据索引参数优化

3.1副本数设置为0

主要原因在于：复制文档时，将整个文档发送到副本节点，并逐字重复索引过程。 这意味着每个副本都将执行分析，索引和潜在合并过程。如果您使用零副本进行索引，则恢复副本的过程本质上是逐字节的网络传输。

PUT /demo_logs/_settings
{"number_of_replicas": 1
}

3.2 增加refresh间隔

如果正在进行大量数据导入，考虑先不要急于索引刷新refresh。可以将每个索引的refresh_interval到30s。

PUT /demo_logs/_settings
{ "refresh_interval": -1 }

此类问题从官网、原理甚至源码的角度思考，然后通过实践就能得到比默认设置reindex速度能提升N倍.