Solr Advent Calendar 2016 の3日目です。
前回の記事でCommitの頻度を減らすとインデキシングが速く終わることに触れました。
SolrのCommitにはHardCommitとSoftCommitの2種類があるため、今回はそれについてです。
SoftCommit
Soft CommitとはNear Real Time Searchの為に実装されたCommit方式で、
公式ドキュメントによるとSoftCommitはメモリ上のインデックスをディスクに書き出さないため、その分高速だそうです。
そのSoftCommitとHardCommitのパフォーマンスの違いを計測したいと思います。
調査に使ったインデックス
後ほど(ry
201601204追記
前回と同じものを使用
Solrのバージョン
5.5.2
調査したパターン
前回と同じく、インデックスが0件の状態から、
1度の更新リクエストで1万件のデータを100回に分けて更新します。
調査パターンは2通りです。
- 毎回 softCommit=trueを指定
http:/localhost:8983/solr/collection/update?softCommit=true- 便宜上パターン3と呼びます
- 毎回 commitWithin=5000を指定
http:/localhost:8983/solr/collection/update?commitWithin=5000- 同じくパターン4とします
commitWithinとは指定されたミリ秒以内にSoftCommitを発生させる機能です。
このパラメーターを受けた時点でCommit Scheduleと呼ばれるCommitを発生させるポイントがセットされ、
そこまでに入ってきたcommitWithin付きの更新リクエストは全て、Commitが1回にまとめられます。
つまり、ユーザーが意識することなくcommitの回数の制御が可能で、(solrconfig.xmlで設定できるautoCommitと違い)Solrの本体の変更無しでcommitの間隔の調整ができます。
結果と考察
前回の結果と比較するため、合わせて結果を張りました。
| 処理時間(秒) | |
|---|---|
| パターン1 | 196 |
| パターン2 | 157 |
| パターン3 | 192 |
| パターン4 | 146 |
パターン3はパターン1とほぼ変わらずでした。
ディスクへの書き込みが無い分、高速なはずですがそれほど変わりませんでした・・・。
おかしいと思っていたのですが、Solr Adminから確認できるSoft Commitの回数が増えていなかったので、
上手くSoft Commitが発生していないようでした。
やり方を間違えたのでしょうか・・・。
パターン4に関してはパターン2よりも高速でした。
1度にまとめてcommitするよりも、定期的にcommitした方が良いのでしょうか？
(もしくは誤差範囲？)
仮にほとんどHard Commitをしないパターン2とほぼ同等と考えるとSoft Commitによるオーバーヘッドはかなり少ないものと考えれるかもしれません。
まとめ
パターン3に関してはきちんとした調査が出来ていなかったので、単純なHard CommitとSoft Commitの比較ができ無かったのが残念でした。
ですが、パターン4の結果からcommitWithin(5000ms)であればCommitのオーバーヘッドを減らせることは分かりました。
実際の運用では定期的にメモリ上のインデックスをディスクに書き出した方が良いため、solrconfigでのauto hard commitはopenSearch=falseで少し長目の値を取ったほうが良いと考えれます(検証で設定していたのはそのためでした)。
なので、更新リクエストに関しては特に理由が無ければcommitWitinを使うとバランスが良いという結果が出たと言えます。
明日はアトミックアップデートについて書きます。