こんにちは。
最近暖かくなってきて春を感じている新人エンジニアの片岡です。
elasticsearch運用時には、indexのライフサイクルマネジメントとして、
書き込みせずに参照だけになるindexに対してshard数の変更やforcemergerを実行してメンテナンスする必要ありますよね。
elasticsearchでは一般的な手順として次のような手順を実行します。
- shard数の削減
- 圧縮形式の変更
- merge処理を行いセグメントをまとめる
elasticsearchではデータを保持する際に裏で圧縮を行っています。
そこで、圧縮方法の違いやmerge処理によるサイズ変化への影響を検証してみました。
検証概要
次の検証を行いました。
1. 2.2GBのApacheログをelasticsearchに投入し、Primary Shardの数を5に設定した。
2. Shrink APIを使ってshard数を削減し、Primary Shard : 1にする。
その際圧縮方法をLZ4→Best Compressionに変更する。
3. force mergeを実行する。
shard数を減らせるShrink APIを用いて、shard数を減らしたり、圧縮方法を変更したりしています。
データが圧縮されたかどうかはディスクサイズを確認して検証しました。
今回はelasticsearchを自分のPC一台で立ち上げています。
そのためReplicaは生成されないのでReplica数は0にして検証を行っています。
検証環境
OS X 10.1.3
elasticsearch 6.2.1
検証内容
初期状態
まずはデータを投入した段階のshardの状態をcat APIを使って見てみました。
元のデータサイズである2.2GBと比べると2倍以上の大きさになっていますが、
これはelasticsearchがデータを持つときのオーバーヘッドや、Logstashの加工による影響があるためです。
圧縮形式:LZ4
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size green open apache_log vMBqxqeQS46IoALeCsW_UQ 5 0 10310474 0 4.7gb 4.7gb
Shrink API
初期状態からShrink APIをたたいてみました。
POST apache_log/_shrink/best_compression { "settings": { "index.number_of_replicas": 0, "index.number_of_shards": 1, "index.codec": "best_compression" } }
実行したときのレスポンス遅延はほとんどありませんでした。
shrinkのマニュアルにありますが、即応答を返して、非同期でshrink処理が実行されるからですね。
The above request returns immediately once the target index has been added to the cluster state — it doesn’t wait for the shrink operation to start.
結果は以下。
best compressionにしたらstore.sizeが大きくなってしまいました。
公式HPを見ると、
Best compression will only take affect when new writes are made to the index,
such as when force-merging the shard to a single segment.
とあります。圧縮方法の変更は新しく書き込まれたデータにしか適用されないなので
force merge等を利用する必要がありますね。
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size green open apache_log vMBqxqeQS46IoALeCsW_UQ 5 0 10310474 0 4.7gb 4.7gb green open best_compression UgRAepvGR1Or1Pl3MZLqOQ 1 0 10310474 0 6.8gb 6.8gb
Force merge
複数のセグメントを1つにまとめるmerge処理を強制的に行うAPIです。
POST best_compression/_forcemerge { "max_num_segments":1 }
結果はこちら。
health status index uuid pri rep docs.count docs.deleted store.size pri.store.size green open apache_log vMBqxqeQS46IoALeCsW_UQ 5 0 10310474 0 4.7gb 4.7gb green open best_compression UgRAepvGR1Or1Pl3MZLqOQ 1 0 10310474 0 4.3gb 4.3gb
best compressionされました。
LZ4と比べて8%削減されましたね。
検証結果
以下のように検証を行いディスクサイズが変化しました。
まとめ
ShrinkAPIを実行しただけでは圧縮が適用されないということ、
また、Shrink APIを実行すると、一度データサイズが大きくなることには注意が必要ですね。
Acroquest Technologyでは、キャリア採用を行っています。
- ビッグデータ（Hadoop/Spark、NoSQL）、データ分析（Elasticsearch、Python関連）、Web開発（SpringCloud/SpringBoot、AngularJS）といった最新のOSSを利用する開発プロジェクトに関わりたい。
- マイクロサービス、DevOpsなどの技術を使ったり、データ分析、機械学習などのスキルを活かしたい。
- 社会貢献性の高いプロジェクトや、顧客の価値を創造するようなプロジェクトで、提案からリリースまで携わりたい。
- 書籍・雑誌等の執筆や、対外的な勉強会の開催・参加を通した技術の発信、社内勉強会での技術情報共有により、エンジニアとして成長したい。
少しでも上記に興味を持たれた方は、是非以下のページをご覧ください。データ分析基盤Elasticsearchを使い倒したいエンジニア募集！ - Acroquest Technology株式会社のエンジニア中途・インターンシップ・契約・委託の求人 - Wantedlywww.wantedly.com
