ES數據庫重建索引——Reindex(數據遷移)

ES數據庫重建索引——Reindex(數據遷移)

原文鏈接: https://www.cnblogs.com/Ace-suiyuan008/p/9985249.html

應用背景:

1、當你的數據量過大,而你的索引最初創建的分片數量不足,導致數據入庫較慢的情況,此時需要擴大分片的數量,此時可以嘗試使用Reindex。 2、當數據的mapping需要修改,但是大量的數據已經導入到索引中了,重新導入數據到新的索引太耗時;但是在ES中,一個字段的mapping在定義並且導入數據之後是不能再修改的, 所以這種情況下也可以考慮嘗試使用Reindex。

Reindex:

ES提供了_reindex這個API。相對於我們重新導入數據肯定會快不少,實測速度大概是bulk導入數據的5-10倍。

數據遷移步驟:

1、創建新的索引(可以通過java程序也可以直接在head插件上創建) 注意:在創建索引的時候要把表結構也要創建好(也就是mapping) 2、複製數據 最簡單、基本的方式: 代碼請求:

POST _reindex
{
  "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"
  }
}

數據遷移效率

問題發現: 常規的如果我們只是進行少量的數據遷移利用普通的reindex就可以很好的達到要求,但是當我們發現我們需要遷移的數據量過大時,我們會發現reindex的速度會變得很慢 數據量幾十個G的場景下,elasticsearch reindex速度太慢,從舊索引導數據到新索引,當前最佳方案是什麼?

原因分析: reindex的核心做跨索引、跨集羣的數據遷移。 慢的原因及優化思路無非包括: 1)批量大小值可能太小。需要結合堆內存、線程池調整大小; 2)reindex的底層是scroll實現,藉助scroll並行優化方式,提升效率; 3)跨索引、跨集羣的核心是寫入數據,考慮寫入優化角度提升效率。

可行方案: 1)提升批量寫入大小值 2)藉助scroll的sliced提升寫入效率

提升批量寫入大小值

默認情況下,_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固態硬盤),要麼添加更多節點。

藉助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倍+。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章