應用背景：
1、當你的數據量過大，而你的索引最初創建的分片數量不足，導致數據入庫較慢的情況，此時需要擴大分片的數量，此時可以嘗試使用Reindex。
2、當數據的mapping需要修改，但是大量的數據已經導入到索引中了，重新導入數據到新的索引太耗時；但是在ES中，一個字段的mapping在定義並且導入數據之后是不能再修改的，
所以這種情況下也可以考慮嘗試使用Reindex。
Reindex：
ES提供了_reindex這個API。相對於我們重新導入數據肯定會快不少，實測速度大概是bulk導入數據的5-10倍。
數據遷移步驟：
1、創建新的索引(可以通過java程序也可以直接在head插件上創建)
注意：在創建索引的時候要把表結構也要創建好(也就是mapping)
2、復制數據
最簡單、基本的方式：
1）代碼請求：
POST _reindex
{
"source": {
"index": "old_index"
},
"dest": {
"index": "new_index"
}
}
2）利用命令：
curl _XPOST 'ES數據庫請求地址:9200/_reindex' -d{"source":{"index":"old_index"},"dest":{"index":"new_index"}}
但如果新的index中有數據，並且可能發生沖突，那么可以設置version_type"version_type": "internal"或者不設置，則Elasticsearch強制性的將文檔轉儲到目標中，覆蓋具有相同類型和ID的任何內容：
POST _reindex
{
"source": {
"index": "old_index"
},
"dest": {
"index": "new_index",
"version_type": "internal"
}
}
設置op_type為create將導致_reindex僅在目標索引中創建缺少的文檔。所有存在的文檔將導致版本POST _reindex
{
“source”: {
“index”: “twitter”
},
“dest”: {
“index”: “new_twitter”,
“op_type”: “create”
}
}
版本沖突將中止_reindex進程，但您可以通過請求體設置”conflict”:”proceed”來在沖突時進行計數：
POST _reindex
{
"conflicts": "proceed",
"source": {
"index": "twitter"
},
"dest": {
"index": "new_twitter",
"op_type": "create"
}
}
還可以通過向source添加type或添加query來限制文檔
POST _reindex
{
"conflicts": "proceed",
"source": {
"index": "old_ijndex"
},
"dest": {
"index": "new_index",
"version_type": "internal",
"op_type": "create"
}
}
增加查詢
curl -u ${newClusterUser}:${newClusterPass} -XPOST "http://${newClusterHost}/_reindex?pretty" -H "Content-Type: application/json" -d'{
"source": {
"remote": {
"host": "'${oldClusterHost}'",
"username": "'${oldClusterUser}'",
"password": "'${oldClusterPass}'"
},
"index": "'${indexName}'",
"query": {
"match_all": {}
}
},
"dest": {
"index": "'${indexName}'"
}
}'
數據量大、無刪除操作、有更新時間。時間范圍內
curl -u ${newClusterUser}:${newClusterPass} -XPOST "${newClusterHost}/_reindex?pretty" -H "Content-Type: application/json" -d '{
"source": {
"remote": {
"host": "'${oldClusterHost}'",
"username": "'${oldClusterUser}'",
"password": "'${oldClusterPass}'"
},
"index": "'${indexName}'",
"query": {
"range" : {
"'${timeField}'" : {
"gte" : '${lastTimestamp}',
"lt" : '${curTimestamp}'
}
}
}
},
"dest": {
"index": "'${indexName}'"
}
}'
es reindex script改字段內容
reindex的時候，改變字段的內容
{
"source": {
"index": "twitter"
},
"dest": {
"index": "new_twitter",
"version_type": "external"
},
"script": {
"source": "if (ctx._source.foo == 'bar') {ctx._version++; ctx._source.remove('foo')}",
"lang": "painless"
}
}
數據遷移效率
問題發現：
常規的如果我們只是進行少量的數據遷移利用普通的reindex就可以很好的達到要求，但是當我們發現我們需要遷移的數據量過大時，我們會發現reindex的速度會變得很慢
數據量幾十個G的場景下，elasticsearch reindex速度太慢，從舊索引導數據到新索引，當前最佳方案是什么？
原因分析：
reindex的核心做跨索引、跨集群的數據遷移。
慢的原因及優化思路無非包括：
1）批量大小值可能太小。需要結合堆內存、線程池調整大小；
2）reindex的底層是scroll實現，借助scroll並行優化方式，提升效率；
3）跨索引、跨集群的核心是寫入數據，考慮寫入優化角度提升效率。
可行方案：
1）提升批量寫入大小值
默認情況下，_reindex使用1000進行批量操作，您可以在source中調整batch_size。
POST _reindex
{
"source": {
"index": "source",
"size": 5000
},
"dest": {
"index": "dest",
"routing": "=cat"
}
}
批量大小設置的依據：
1、使用批量索引請求以獲得最佳性能。
批量大小取決於數據、分析和集群配置，但一個好的起點是每批處理5-15 MB。
注意，這是物理大小。文檔數量不是度量批量大小的好指標。例如，如果每批索引1000個文檔:
1）每個1kb的1000個文檔是1mb。
2）每個100kb的1000個文檔是100 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": "twitter"
},
"dest": {
"index": "new_twitter"
}
}
slices大小設置注意事項：
1）slices大小的設置可以手動指定，或者設置slices設置為auto，auto的含義是：針對單索引，slices大小=分片數；針對多索引，slices=分片的最小值。
2）當slices的數量等於索引中的分片數量時，查詢性能最高效。slices大小大於分片數，非但不會提升效率，反而會增加開銷。
3）如果這個slices數字很大(例如500)，建議選擇一個較低的數字，因為過大的slices 會影響性能。
實踐證明，比默認設置reindex速度能提升10倍+。
Index Alias
當針對某個指定的index進行操作時候，ElasticSearch中的API接受一個index的名字。當然在多個index的情況下也可以指定多個index。
index aliases的API允許我們為一個index指定別名。一個別名能夠被映射到多個index中，當指定了index對應已經有其它index對應的別名之后，別名可以自動擴展到多個index。一個別名能夠關聯上一個過濾器，當搜索和路由的時候能夠自動使用這個過濾器。
add別名
這個一個關聯別名alias1到index test1的例子
curl -XPOST 'http://localhost:9200/_aliases' -d '
{
"actions" : [
{ "add" : { "index" : "test1", "alias" : "alias1" } }
]
}'
成功則返回
{"acknowledged":true}
remove別名
也可以刪除別名
curl -XPOST 'http://localhost:9200/_aliases' -d '
{
"actions" : [
{ "remove" : { "index" : "test1", "alias" : "alias1" } }
]
}'
成功則返回
{"acknowledged":true}
重命名
重命名一個別名很簡單，通過相同API的簡單remove和add操作就可以了。這個操作是原子的，不用擔心在很短的一段時間內別名並不指向任何一個index
curl -XPOST 'http://localhost:9200/_aliases' -d '
{
"actions" : [
{ "remove" : { "index" : "test1", "alias" : "alias1" } },
{ "add" : { "index" : "test1", "alias" : "alias2" } }
]
}'
成功則返回
{"acknowledged":true}
別名切換
當然，也可以通過同一個API實現alias到不同index的切換。在實際使用中，如果我們通過別名來訪問ElasticSearch，那么可以通過別名指向index的切換來實現不同版本數據的快速切換。
curl -XPOST 'http://localhost:9200/_aliases' -d '
{
"actions" : [
{ "remove" : { "index" : "test1", "alias" : "alias2" } },
{ "add" : { "index" : "test", "alias" : "alias2" } }
]
}'
成功則返回
{"acknowledged":true}
指向多個index的別名
可以將一個別名指向多余一個index，通過簡單的多個add操作
curl -XPOST 'http://localhost:9200/_aliases' -d '
{
"actions" : [
{ "add" : { "index" : "test1", "alias" : "alias1" } },
{ "add" : { "index" : "test2", "alias" : "alias1" } }
]
}'
成功則返回
{"acknowledged":true}
---------------------