一、使用場景
1.分片數(shù)變更
:當你的數(shù)據(jù)量過大,而你的索引最初創(chuàng)建的分片數(shù)量不足,導(dǎo)致數(shù)據(jù)入庫較慢的情況,此時需要擴大分片的數(shù)量,此時可以嘗試使用Reindex。
2. mapping字段變更
:當數(shù)據(jù)的mapping需要修改,但是大量的數(shù)據(jù)已經(jīng)導(dǎo)入到索引中了,重新導(dǎo)入數(shù)據(jù)到新的索引太耗時;但是在ES中,一個字段的mapping在定義并且導(dǎo)入數(shù)據(jù)之后是不能再修改的,所以這種情況下也可以考慮嘗試使用Reindex。
3. 分詞規(guī)則修改
,比如使用了新的分詞器或者對分詞器自定義詞庫進行了擴展,而之前保存的數(shù)據(jù)都是按照舊的分詞規(guī)則保存的,這時候必須進行索引重建。
二、_reindex
官方說明地址:reindex
ES提供了_reindex這個API。相比于我們重新導(dǎo)入數(shù)據(jù)肯定會快不少,實測速度大概是bulk導(dǎo)入數(shù)據(jù)的5-10倍。
reindex的核心做跨索引、跨集群的數(shù)據(jù)遷移。
Reindex 不會嘗試設(shè)置目標索引。 它不會復(fù)制源索引的設(shè)置。 您應(yīng)該在運行 _reindex 操作之前設(shè)置目標索引,包括設(shè)置映射、分片計數(shù)、副本等。
先根據(jù)復(fù)制源索引創(chuàng)建新的目標索引,然后執(zhí)行reindex命令。
基礎(chǔ)使用命令:
POST _reindex
{
"source": {
"index": "old_index"
},
"dest": {
"index": "new_index"
}
}
三、實戰(zhàn)
1、覆蓋更新
說明:"version_type": "internal"
,internal表示內(nèi)部的,省略version_type或version_type設(shè)置為 internal 將導(dǎo)致 Elasticsearch 盲目地將文檔轉(zhuǎn)儲到目標中,覆蓋任何具有相同類型和 ID 的文件。
這也是最常見的重建方式。
POST _reindex
{
"source": {
"index": "twitter"
},
"dest": {
"index": "new_twitter",
"version_type": "internal"
}
}
2、創(chuàng)建丟失的文檔并更新舊版本的文檔
說明:"version_type": "external"
,external表示外部的,將 version_type 設(shè)置為 external 將導(dǎo)致 Elasticsearch 保留源中的版本,創(chuàng)建任何丟失的文檔,并更新目標索引中版本比源索引中版本舊的任何文檔。
id不存在的文檔會直接更新;id存在的文檔會先判斷版本號,只會更新版本號舊的文檔。
POST _reindex
{
"source": {
"index": "twitter"
},
"dest": {
"index": "new_twitter",
"version_type": "external"
}
}
3、僅創(chuàng)建丟失的文檔
要創(chuàng)建的 op_type 設(shè)置將導(dǎo)致 _reindex 僅在目標索引中創(chuàng)建丟失的文檔,所有存在的文檔都會引起版本沖突。只要兩個索引中存在id相同的記錄,就會引起版本沖突
。
POST _reindex
{
"source": {
"index": "twitter"
},
"dest": {
"index": "new_twitter",
"op_type": "create"
}
}
4、沖突處理
默認情況下,版本沖突會中止 _reindex 進程。 “沖突”請求正文參數(shù)可用于指示 _reindex 繼續(xù)處理有關(guān)版本沖突的下一個文檔。 需要注意的是,其他錯誤類型的處理不受“沖突”參數(shù)的影響。
當"conflicts": "proceed"
在請求正文中設(shè)置時,_reindex 進程將繼續(xù)處理版本沖突并返回遇到的版本沖突計數(shù)。
POST _reindex
{
"conflicts": "proceed",
"source": {
"index": "twitter"
},
"dest": {
"index": "new_twitter",
"op_type": "create"
}
}
5、source中添加查詢條件
POST _reindex
{
"source": {
"index": "twitter",
"query": {
"term": {
"user": "kimchy"
}
}
},
"dest": {
"index": "new_twitter"
}
}
6、source中包含多個源索引
源中的索引可以是一個列表,允許您在一個請求中從多個源中復(fù)制。 這將從 twitter 和 blog 索引中復(fù)制文檔:
POST _reindex
{
"source": {
"index": ["twitter", "blog"]
},
"dest": {
"index": "all_together"
}
}
也支持*號來匹配多個索引。
POST _reindex
{
"source": {
"index": "twitter*"
},
"dest": {
"index": "all_together"
}
}
7、限制處理的記錄數(shù)
通過設(shè)置size大小來限制處理文檔的數(shù)量。
POST _reindex
{
"size": 10000,
"source": {
"index": "twitter",
"sort": { "date": "desc" }
},
"dest": {
"index": "new_twitter"
}
}
8、從遠程ES集群中重建索引
POST _reindex
{
"source": {
"remote": {
"host": "http://otherhost:9200",
"username": "user",
"password": "pass",
"socket_timeout": "1m",
"connect_timeout": "10s"
},
"index": "source",
"query": {
"match": {
"test": "data"
}
}
},
"dest": {
"index": "dest"
}
}
9、提取隨機子集
說明:從源索引中隨機取10條數(shù)據(jù)到新索引中。
POST _reindex
{
"size": 10,
"source": {
"index": "twitter",
"query": {
"function_score" : {
"query" : { "match_all": {} },
"random_score" : {}
}
},
"sort": "_score"
},
"dest": {
"index": "random_twitter"
}
}
10、修改字段名稱
原索引
POST test/_doc/1?refresh
{
"text": "words words",
"flag": "foo"
}
重建索引,將原索引中的flag字段重命名為tag字段。
POST _reindex
{
"source": {
"index": "test"
},
"dest": {
"index": "test2"
},
"script": {
"source": "ctx._source.tag = ctx._source.remove(\"flag\")"
}
}
結(jié)果:
GET test2/_doc/1
{
"found": true,
"_id": "1",
"_index": "test2",
"_type": "_doc",
"_version": 1,
"_seq_no": 44,
"_primary_term": 1,
"_source": {
"text": "words words",
"tag": "foo"
}
}
四、性能優(yōu)化
常規(guī)的如果我們只是進行少量的數(shù)據(jù)遷移利用普通的reindex就可以很好的達到要求,但是當我們發(fā)現(xiàn)我們需要遷移的數(shù)據(jù)量過大時,我們會發(fā)現(xiàn)reindex的速度會變得很慢。
數(shù)據(jù)量幾十個G的場景下,elasticsearch reindex速度太慢,從舊索引導(dǎo)數(shù)據(jù)到新索引,當前最佳方案是什么?
原因分析:
reindex的核心做跨索引、跨集群的數(shù)據(jù)遷移。
慢的原因及優(yōu)化思路無非包括:
1)批量大小值可能太小。需要結(jié)合堆內(nèi)存、線程池調(diào)整大??;
2)reindex的底層是scroll實現(xiàn),借助scroll并行優(yōu)化方式,提升效率;
3)跨索引、跨集群的核心是寫入數(shù)據(jù),考慮寫入優(yōu)化角度提升效率。
可行方案:
1)提升批量寫入的大小值size
2)通過設(shè)置sliced提高寫入的并行度
1、提升批量寫入大小值
默認情況下 _reindex 使用 1000 的滾動批次??梢允褂迷丛豷ource中的 size 字段更改批次大小:
POST _reindex
{
"source": {
"index": "source",
"size": 5000
},
"dest": {
"index": "dest"
}
}
2、提高scroll的并行度
Reindex 支持 Sliced Scroll 來并行化重新索引過程。 這種并行化可以提高效率并提供一種將請求分解為更小的部分的便捷方式。
每個Scroll請求,可以分成多個Slice請求,可以理解為切片,各Slice獨立并行,利用Scroll重建或者遍歷要快很多倍。
slicing的設(shè)定分為兩種方式:手動設(shè)置分片、自動設(shè)置分片。
自動設(shè)置分片如下:
POST _reindex?slices=5&refresh
{
"source": {
"index": "twitter"
},
"dest": {
"index": "new_twitter"
}
}
slices大小設(shè)置注意事項:
1)slices大小的設(shè)置可以手動指定,或者設(shè)置slices設(shè)置為auto,auto的含義是:針對單索引,slices大小=分片數(shù);針對多索引,slices=分片的最小值。
2)當slices的數(shù)量等于索引中的分片數(shù)量時,查詢性能最高效。slices大小大于分片數(shù),非但不會提升效率,反而會增加開銷。
3)如果這個slices數(shù)字很大(例如500),建議選擇一個較低的數(shù)字,因為過大的slices 會影響性能。
效果
實踐證明,比默認設(shè)置reindex速度能提升10倍+。
五、超時問題
es中的請求超時時間默認是1分鐘,當重建索引的數(shù)據(jù)量太大時,經(jīng)常會出現(xiàn)超時。這種情況可以增大超時時間,也可以添加wait_for_completion=false
參數(shù)將請求轉(zhuǎn)為異步任務(wù)。文章來源:http://www.zghlxwxcb.cn/news/detail-458263.html
POST _reindex?slices=9&refresh&wait_for_completion=false
{
"source": {
"index": "twitter"
},
"dest": {
"index": "new_twitter"
}
}
1、獲取reindex任務(wù)列表
GET _tasks?detailed=true&actions=*reindex
2、根據(jù)任務(wù)id查看任務(wù)
GET /_tasks/r1A2WoRbTwKZ516z6NEs5A:36619
3、取消任務(wù)
POST _tasks/r1A2WoRbTwKZ516z6NEs5A:36619/_cancel
總結(jié)
本文主要介紹了ES索引重建的常見使用場景以及典型的使用方法,并說明了相關(guān)性能優(yōu)化的技巧和請求超時問題的處理方法。文章來源地址http://www.zghlxwxcb.cn/news/detail-458263.html
到了這里,關(guān)于ES索引重建reindex詳解的文章就介紹完了。如果您還想了解更多內(nèi)容,請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章,希望大家以后多多支持TOY模板網(wǎng)!