數據遷移:Reindex：
ES提供了_reindex這個API。相對於程序重新導入數據快，實測速度大概是bulk導入數據的5-10倍。
數據遷移步驟：
1、創建新的索引
2、遷移數據
1）代碼請求：
POST _reindex
{
"source": {
"index": "old_index"
},
"dest": {
"index": "new_index",
"version_type": "internal"
}
}
2）利用命令：
curl _XPOST 'esIp:9200/_reindex' -d{"source":{"index":"old_index"},"dest":{"index":"new_index","version_type": "internal"}}
version_type："version_type": "internal"，如果新的index中有數據，並且可能發生衝突則Elasticsearch強制性的將文檔轉儲到目標中，覆蓋具有相同類型和ID的任何內容。
優化
問題發現：
當遷移的數據量過大時，發現reindex的速度會變得很慢，比如數據量幾十個G的場景下，elasticsearch reindex速度太慢
原因分析：
reindex的核心做跨索引、跨集羣的數據遷移。/ 慢的原因及優化思路無非包括：/ - 1）批量大小值可能太小。需要結合堆內存、線程池調整大小；
- 2）reindex的底層是scroll實現，藉助scroll並行優化方式，提升效率；
- 3）跨索引、跨集羣的核心是寫入數據，考慮寫入優化角度提升效率。
優化方案：
1）提升批量寫入大小值
默認_reindex使用1000進行批量操作
POST _reindex
{
"source": {
"index": "source",
"size": 5000
},
"dest": {
"index": "dest",
"routing": "=cat"
}
}
批量大小設置的依據：
1、使用批量索引請求以獲得最佳性能。
批量大小取決於數據、分析和集羣配置，但一個好的起點是每批處理5-15 MB。
注意，這是物理大小。文檔數量不是度量批量大小的好指標。
2、逐步遞增文檔容量大小的方式調優。
1）從大約5-15 MB的大容量開始，慢慢增加，直到你看不到性能的提升。然後開始增加批量寫入的併發性(多線程等等)。
2）使用kibana、cerebro或iostat、top和ps等工具監視節點，以查看資源何時開始出現瓶頸。如果您開始接收EsRejectedExecutionException，您的集羣就不能再跟上了:至少有一個資源達到了容量。
要麼減少併發性，或者提供更多有限的資源(例如從機械硬盤切換到ssd固態硬盤)，要麼添加更多節點。
2）藉助scroll的sliced提升寫入效率
Reindex支持Sliced Scroll以並行化重建索引過程。 這種並行化可以提高效率，並提供一種方便的方法將請求分解爲更小的部分。
sliced原理（from medcl）
1）用過Scroll接口吧，很慢？如果你數據量很大，用Scroll遍歷數據那確實是接受不了，現在Scroll接口可以併發來進行數據遍歷了。
2）每個Scroll請求，可以分成多個Slice請求，可以理解爲切片，各Slice獨立並行，利用Scroll重建或者遍歷要快很多倍。
slicing使用舉例
slicing的設定分爲兩種方式：手動設置分片、自動設置分片。
手動設置分片如下：
POST _reindex?slices=5&refresh
{
"source": {
"index": "old_index"
},
"dest": {
"index": "new_index"
}
}
slices大小設置注意事項：
1）slices大小的設置可以手動指定，或者設置slices設置爲auto，auto的含義是：針對單索引，slices大小=分片數；針對多索引，slices=分片的最小值。 2）當slices的數量等於索引中的分片數量時，查詢性能最高效。slices大小大於分片數，非但不會提升效率，反而會增加開銷。 3）如果這個slices數字很大(例如500)，建議選擇一個較低的數字，因爲過大的slices 會影響性能。