Solr Advent Calendar 2016 の5日目です。
2016年12月17日 追記
設定に間違いがあり、アトミックアップデートが正常に動いていなかったので、再検証しています
アトミックアップデートとSOLR-9592
前回の記事でアトミックアップデートのパフォーマンスについて良くないことに触れましたが、どうやらSOLR-9592でパフォーマンスの改善があり、既にSolr-6.3.0に取り込まれているようです。
チケットとソースを読むとフィールドの補完をするためにフィールド値を取得するところが、遅かった?ようです。
せっかくなので、前回からの続きでどれだけ高速になったか調査したいと思います。
調査に使ったインデックス
概ね前回と同じですが、unique_key以外をstored=falseかつdocValues=trueにしたものを使います。
理由は補足の項を参照。
Solrのバージョン
6.3.0
調査したパターン
これも前回のアトミックアップデートの検証と同じく、optmize済みのインデックス100万件が有る状態から、1万件づつ更新リクエストを発行します。
- 全てのフィールドを揃えて更新
- sort_int1だけアップデート(set)で更新
結果と考察
処理時間(秒) | |
---|---|
パターン1 |
|
パターン2 |
|
アトミックアップデートが通常の更新とほぼ同等のパフォーマンスになりました。
6.3系以降ではアトミックアップデートの更新速度でのデメリットは解消とされた言っても良いのでは無いでしょうか。
依然として処理コストがかかるものの、Solr-5.5.2では3倍以上かかっていたものが2倍ほどまで短縮されました。
補足
今回のパフォーマンス改善はstored=falseかつ、useDocValuesAsStored=trueのフィールドに対して有効なようです。
当初はstored=trueで検証していたのですが、パフォーマンスが変わらなかったので、ソースをデバッグしたところ、stored=falseかつ、useDocValuesAsStored=trueの場合にパッチのパスに入っていました。
調査したのが結構前なのと、この辺りは詳しく終えていないので、ちょっと自信が無いですが・・・。
上記、正しくはstored=falseかつdocValues=trueの場合です。
Solr 5.5.2へのバックポート
下記はSOLR-9592のdiffです。
https://github.com/apache/lucene-solr/commit/cae6b49a065bfbc5789d8bdcf3706c158c0fc10d
実際にパフォーマンスへ影響しているコードはSolrIndexSearcherへのものです。
下記がbranch_5_5のSolrIndexSearcherのコードです。
https://github.com/apache/lucene-solr/blob/branch_5_5/solr/core/src/java/org/apache/solr/search/SolrIndexSearcher.java#L792-L864
SOLR-9592の改善が入るまで、いくつかのパッチが当たっているため、そのまま適用はできませんが、バックポートするのも難しくなさそうです。
本当は5.5.2にバックポートしてパフォーマンスを調査した結果で記事を書くつもりでしたが、記事を書く段階で
ソースを見直すとパッチを雑に当てすぎていたので、今回は断念しました・・・。
まとめ
SOLR-9592によるアトミックアップデートの改修は大きなものがありました。
実際にSolrを使った開発をすると、大量のドキュメントに対して特定のフィールドのみを更新したい要件があったりします。
今までは大量のドキュメントをアトミックアップデートで更新するには負荷が大きかったため、使用を断念せざるを得ない時もありましたが、6.3以降は気にせず使っていけそうです。
依然として更新速度はかかっているものの、大きくパフォーマンスの改善がされたので利用検討が視野に入るケースも増えているのは無いでしょうか。