はじめに
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データの出力完了までに先輩たちと同じやり方では、２４時間かかった。
出力されたファイルのサイズ： 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 とした。
この設定では、処理時間は １時間半弱 であった。 概算でも16倍ほど高速だ。
振り返り2
limitの値を８０倍に設定して、処理時間は16分の1になった。この程度の時間であれば、まだ個人利用のPCであっても我慢できる範囲だろう。まだどこかほかにボトルネックがあるのだろうが、このスクリプトで処理時間を変動させる要因のひとつはlimit値であることはまちがいない。次の機会があれば、さらにlimit値をあげてみたい。また、適切な値の決定方法がわからない。技術者の勘と経験で決めていいのだろうか。
まとめ
Elasticsearchのデータ移行にあたり、elasticdumpスクリプトを使った。inputとoutputのデータダンプの方向の違いはあるが、limitオプションの設定値をデフォルトの数十倍にして処理速度を比較した。その結果、limitオプションの設定値を大きくすることで、処理時間を大幅に短縮できることがわかった。