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

應用背景：

一、當你的數據量過大，而你的索引最初建立的分片數量不足，致使數據入庫較慢的狀況，此時須要擴大分片的數量，此時能夠嘗試使用Reindex。

二、當數據的mapping須要修改，可是大量的數據已經導入到索引中了，從新導入數據到新的索引太耗時；可是在ES中，一個字段的mapping在定義而且導入數據以後是不能再修改的，

因此這種狀況下也能夠考慮嘗試使用Reindex。

Reindex：

ES提供了_reindex這個API。相對於咱們從新導入數據確定會快很多，實測速度大概是bulk導入數據的5-10倍。

數據遷移步驟：

一、建立新的索引(能夠經過java程序也能夠直接在head插件上建立)

注意：在建立索引的時候要把表結構也要建立好(也就是mapping)

二、複製數據

最簡單、基本的方式：

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"
  }
}

 

數據遷移效率

問題發現：

常規的若是咱們只是進行少許的數據遷移利用普通的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"
  }
}

 

批量大小設置的依據：

一、使用批量索引請求以得到最佳性能。

批量大小取決於數據、分析和集羣配置，但一個好的起點是每批處理5-15 MB。

注意，這是物理大小。文檔數量不是度量批量大小的好指標。例如，若是每批索引1000個文檔:

1）每一個1kb的1000個文檔是1mb。

2）每一個100kb的1000個文檔是100 MB。

這些是徹底不一樣的體積大小。

二、逐步遞增文檔容量大小的方式調優。

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