0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

Elasticsearchのindexの引越し。Elasticdumpはlimitオプション再定義で高速処理。

Last updated at Posted at 2020-11-21

はじめに

Elasticsearch を docker を使って、ローカルマシンで使用している。
Elasticsearchのバージョンをあげてみたくなったので、データをDumpして引越ししてみることにした。

事前調査

2020/11/20現在、Googleを使って、「elasticsearch インデックス 移行」と調べてみると、Elasticdumpというスクリプトを使っているひとが多いようだ。

(以下、Googleの検索結果 表示される順に抜粋)

ElasticSearchのindexデータを移行する - Qiitaqiita.com › Node.js
https://qiita.com/taai/items/9244e7dc4dacf29ab95a

よく使うElasticSearchのクエリ(elasticdump) - Qiitaqiita.com › Elasticsearch
https://qiita.com/nakazii-co-jp/items/3199433d685d0600c6d6

Elasticsearchのデータをdumpしてコピーしたい - DRYな備忘録otiai10.hatenablog.com › entry › 2015/03/04
https://otiai10.hatenablog.com/entry/2015/03/04/152842

Elasticsearch 上のデータを割と簡単にダンプして他の ...inokara.hateblo.jp › entry › 2020/05/02
https://inokara.hateblo.jp/entry/2020/05/02/074402

...
..
.

elasticsearch-dump/elasticsearch-dump: Import and ... - GitHubgithub.com › elasticsearch-dump › el...
https://github.com/elasticsearch-dump/elasticsearch-dump

Qiita先輩方の記事の作成日が5年前であっったりしたが、githubは2020年に入っても頻繁にメンテナンスされているようだ。elasticsearchのバージョンは気にせず使えるのではないだろうか。
Google検索結果で表示される情報は、やや作成日が古いものもあることが気になったが、2020年もメンテされているなら使っても問題は少ないのではないか、と期待して、私もこの node.js スクリプトを使ってみることとした。

準備

elasticdump は、nodeスクリプトなので、マシンにnode実行環境が必要であった。私の環境ではすでにnode実行環境があるので npm install elasticdump した(あとで気づいたのだがdockerもあるようだ。)。

実行1 ( dump output=json, input=elasticsearch/index )

事前調査のいずれの先輩たちも、「elasricdump --output ^^^ --input ~~~」と、インプットとアウトプットの指定だけでdumpをし、dumpをelasticsearchに読み込ませているので、そのまま真似してやってみたのだが・・・

ドキュメント数が1200万を超え、ストレージサイズが6GBを超えていた私のindexではjsonのdumpデータの出力完了までに先輩たちと同じやり方では、24時間かかった

出力されたファイルのサイズ: 5302184689 byte

<参考:マシン環境> intel i7-3770k, 16GB Memory, SSD 960GB
<参考:docker Engine> v19.03.13
<参考:docker resources> CPUs:4, Memory:5.50GB, Swap:2GB, Disk image size:59.6GB

振り返り1

そんなに時間かかるものなのか?
動作ログを見てみる・・・なるほど、objectを100ずつ扱っていたのか。
これ、もっと増やせないのか?

elasticsearch-dump のGitHubを読むと、設定オプションがあった。

--limit
                How many objects to move in batch per operation
                limit is approximate for file streams
                (default: 100)

よし、では、dumpしたJsonを新環境に書き込むにあたっては、「--limit」オプションを追加しよう。

実行2 ( dump output=elasticsearch/index, input=json )

実行1の output と input のオプションの対象を入れ替え、 さらに limitオプションを付け足して実行する。いちどにあつかうオブジェクトの量を増やした効果を見てみた。limitの値をどの程度にするのが適切なのかわからなかったが、今回は なんとなく8000 とした。

この設定では、処理時間は 1時間半弱 であった。 概算でも16倍ほど高速だ。

振り返り2

limitの値を80倍に設定して、処理時間は24時間から1時間半へと16分の1になった。この程度の時間であれば、まだ個人利用のPCであっても我慢できる範囲だろう。まだどこかほかにボトルネックがあるのだろうが、このスクリプトで処理時間を変動させる要因のひとつはlimit値であることはまちがいない。次の機会があれば、さらにlimit値をあげてみたい。ただし、適切な値の決定方法がわからない。技術者の勘と経験で決めていいのだろうか。

まとめ

Elasticsearchのデータ移行にあたり、elasticdumpスクリプトを使った。inputとoutputのデータダンプの方向の違いはあるが、limitオプションの設定値をデフォルトの数十倍にして処理速度を比較した。その結果、limitオプションの設定値を大きくすることで、処理時間を大幅に短縮できることがわかった

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?