1
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 5 years have passed since last update.

SolrAdvent Calendar 2016

Day 2

SolrのCommitのタイミングと更新速度の違い

Last updated at Posted at 2016-12-02

Solr Advent Calendar 2016 の2日目です。

Commitとは

Solrのcommitとは、

  • 更新したインデックスを検索可能な状態にする(新しいSearcherを開く)
  • インデックスをディスクに書き出す

という処理です。
公式ドキュメントにも記載がある通り、頻繁にcommitするとパフォーマンスが悪くなります。
そこで、commitの発生回数と更新速度の違いを調査したいと思います。

調査に使ったインデックス

後ほどgitに上げます・・・!

20161204追記
gitにインデックスのサンプルデータと一緒に置きました。

Solrのバージョン

5.2.1を使用しています。

調査したパターン

インデックスが0件の状態から、
1度の更新リクエストで1万件のデータを更新しました。
これを100回、計100万件を更新します。
この時に、

  1. 毎回 commit=true
  2. 毎回 commit=falseして、最後に1度だけcommit=true

というようにcommitの発生タイミングを制御しました。
今回は諸事情から、solrconfig.xmlの設定でAuto Commitを15秒に1度に設定しディスクへ書き出しをさせます。
そのさいにopenSearhcerはfalseで設定しています。

結果と考察

以下のようになりました。

処理時間(秒)
パターン1 196
パターン2 157

やはり毎回commitする方法に対して、最後に1度だけcommitするパターン2の方が高速でした。
実際の運用環境では並列で更新リクエストをしたり、定期で走るバッチ更新や即時反映させたいリアルタイムのある更新リクエストなどもある場合、パフォーマンスの観点からは毎回commit=trueにするのはあまり良い方法では無いかも知れません。
一方で最後に一度だけcommitさせる方法は検索結果への反映が遅れてしまうという欠点もあるため、auto commitを上手く使いたいところです。

まとめ

commitの頻度を減らすことでインデキシングが高速になることが計測から分かりました。
次回はSoftCommitについて触れたいと思います。

1
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
1
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?