web-dev-qa-db-ja.com

SOLR autoCommitとautoSoftCommit

とについて非常に混乱しています。これが私が理解していることです

  • autoSoftCommit-autoSoftCommitの後でSOLRサーバーがダウンすると、autoSoftCommitドキュメントが失われます。

  • autoCommit-ディスクにハードコミットを行い、すべてのautoSoftCommitコミットがディスクに書き込まれ、他のドキュメントをコミットすることを確認します。

私の次の設定はautoSoftCommitでのみあるようです。 autoCommit自体はコミットを実行していないようです。何か足りないものはありますか？

<updateHandler class="solr.DirectUpdateHandler2">
    <updateLog>
        <str name="dir">${solr.ulog.dir:}</str>
    </updateLog>
   <autoSoftCommit>
        <maxDocs>1000</maxDocs>
        <maxTime>1200000</maxTime>
    </autoSoftCommit>
    <autoCommit>
        <maxDocs>10000</maxDocs>
        <maxTime>120000</maxTime> 
        <openSearcher>false</openSearcher>
    </autoCommit>
</updateHandler>

autoCommitがそれ自体で機能するのはなぜですか？

solrsolr4
25
hajime

ハードコミットのopenSearcher = falseがあります。つまり、コミットが発生しても、サーチャーは再起動されておらず、変更を確認できません。その設定を変更してみてください。ソフトコミットは必要ありません。

SoftCommitはサーチャーを再度開きます。したがって、両方のセクションがある場合、ソフトコミットは新しい変更を（ハードコミットされていない場合でも）表示し、設定どおりハードコミットはそれらをディスクに保存しますが、可視性は変更しません。

これにより、ソフトコミットを1秒にして、ドキュメントをすばやく表示し、ハードコミットの頻度を減らすことができます。

30
Alexandre Rafalovitch

これは 記事 が役立つと思います。ハードコミットとソフトコミットがどのように機能するか、およびシステムのチューニング時に考慮すべきトレードオフについて詳しく説明します。

推奨が間違っている場合があるので、私はいつもこれに身震いします。私の最初の推奨事項は、問題を考えすぎないことです。一部の非常に賢い人々は、プロセス全体を堅牢にすることを試みました。最初に簡単なことを試し、必要に応じて調整だけを行ってください。特に、トランザクションログのサイズを確認し、ハードコミットの間隔を調整して、これらを「妥当なサイズ」に保つようにします。 JVMのクラッシュ後に再起動した場合のペナルティは、ほとんどの場合、関係する再生時間であることに注意してください。 15秒は許容範囲ですか？なぜ小さくなりますか？

ハードコミット間隔がソフトコミット間隔よりもはるかに短い状況を見てきました。以下の一括インデックス作成ビットを参照してください。

これらは開始する場所です。

ヘビー（バルク）インデクシング

ここでの想定は、将来の検索のために、できるだけ多くのデータをできるだけ早くインデックスに登録することに関心があるということです。データソースなどの元々の負荷を考えています.

ソフトコミット間隔を非常に長く設定します。 10分くらい。ソフトコミットは可視性に関するものであり、ここでの仮定は、バルクインデックスはほぼリアルタイムの検索ではないため、あらゆる種類のサーチャーを開く余分な作業を行わないことです。ハードコミット間隔を15秒に設定します（openSearcher = false）。ここでも、Solrでデータをブラストすることを前提としています。ここで最悪のケースは、システムを再起動し、tlogから15秒程度のデータを再生する必要がある場合です。システムがそれより頻繁に上下にバウンスする場合は、最初にその理由を修正してください。簡単なことを試した後にのみ、改良を検討する必要がありますが、通常、それらは異常な状況でのみ必要です。ただし、次のことが含まれます。一括読み込み操作のためにtlogを完全にオフにし、何らかのマップ縮小プロセスを使用してオフラインでインデックスを作成する。追いつくために複製。これは自動であることに注意してください。ノードがリーダーとの同期が「遠すぎる」ことを検出した場合、ノードは古いスタイルのレプリケーションを開始します。追いつくと、リーダーに索引付けされ、独自のログを保持するため、ドキュメントが取得されます。等.

INDEX-HEAVY、QUERY-LIGHT

つまり、ログファイルの検索などです。これは、ほとんどの場合、システムに大量のデータが送信される場合です。ただし、クエリの負荷は非常に軽く、多くの場合、使用状況のトラブルシューティングや分析が行われます。

ソフトコミット間隔を非常に長く設定し、ドキュメントが表示されるまでの最大待機時間を設定します。これは、ほんの数分またはそれ以上になる場合があります。ハードコミット（openSearcher = true）またはソフトコミットをオンデマンドで発行する機能があれば、何時間もかかるかもしれません。ハードコミットを15秒に設定します。openSearcher= false

INDEX-LIGHT、QUERY-LIGHT OR HEAVY

これは比較的静的なインデックスであり、インデックスのバーストが少し発生することがあります。 5〜10分（またはそれ以上）ごとに更新を行うと言います

NRT機能が必要でない限り、この状況ではソフトコミットを省略し、openSearcher = trueを指定して5〜10分ごとにハードコミットを実行します。これは、単一の外部インデックス作成プロセスを使用してインデックスを作成している場合に、クライアントにハードコミットを発行させることが理にかなっている状況です。

INDEX-HEAVY、QUERY-HEAVY

これはニアリアルタイム（NRT）のケースであり、実際には最も扱いにくいものです。これは実験が必要ですが、ここから始めます

ソフトコミットの間隔を、できるだけ長く設定してください。 「1秒以上のレイテンシは必要ない」と言うプロダクトマネージャーの話を聞かないでください。本当に。ハードプッシュバックし、ユーザーが最善のサービスを提供されているか、気づくかどうかを確認します。ソフトコミットとNRTはすばらしいですが、無料ではありません。ハードコミット間隔を15秒に設定します。

私の場合（インデックスが重い、クエリが多い）、マスター/スレーブのレプリケーションに時間がかかりすぎて、スレーブへのクエリの実行が遅くなっていました。 softCommitを15分に増やし、hardCommitを1分に増やすことで、パフォーマンスが大幅に向上しました。これでレプリケーションは問題なく動作し、サーバーは1秒あたりの要求をはるかに多く処理できます。

これは私のユースケースですが、マスターはアイテムのインデックス作成にのみ使用され、新しいアイテムはレプリケーションサイクルごとにスレーブで利用できるため（5分）、これは私の場合はまったく問題ありません。ケースに応じてこのパラメータを調整する必要があります。

36
vruizext

ソフトコミットは可視性に関するものです。ハードコミットは耐久性に関するものです。最適化はパフォーマンスに関するものです。

ソフトコミットは非常に高速で、変更は表示されますが、この変更は永続的ではありません（メモリにのみ存在します）。したがって、クラッシュ中、この変更は最後になる可能性があります。
ハードコミットの変更はディスクに永続化されます。
最適化はハードコミットに似ていますが、solrインデックスセグメントを単一のセグメントにマージしてパフォーマンスを向上させます。ただし、非常にコストがかかります。

Commit（hard commit）操作は、インデックスの変更を新しい検索リクエストで認識できるようにします。ハードコミットは、トランザクションログを使用して最新のドキュメント変更のIDを取得し、インデックスファイルに対してfsyncを呼び出して、それらが安定したストレージにフラッシュされ、電源障害によるデータ損失が発生しないことを確認します。

ソフトコミットはインデックスの変更を表示するだけで、インデックスファイルのfsyncや新しいインデックス記述子の書き込みを行わないため、はるかに高速です。 JVMがクラッシュしたり、電源が失われたりすると、最後のハードコミット後に発生した変更は失われます。 NRT要件を持つ検索コレクション（インデックスの変更を検索ですばやく表示したい）は、ソフトコミットを頻繁に行いますが、ハードコミットはそれほど頻繁ではありません。 softCommitはスループットが遅くなる可能性があるため、時間の面では「安価」ですが、無料ではありません。

最適化は、すべてのインデックスセグメントを最初に単一のセグメントにマージすることを強制することを除いて、ハードコミットに似ています。使用に応じて、この操作はインデックス全体の読み取りと再書き込みを伴うため、たとえあったとしても、まれに（たとえば、毎晩）実行する必要があります。セグメントは通常、とにかく（マージポリシーによって決定されるように）時間の経過とともにマージされ、optimizeはこれらのマージをただちに強制的に発生させます。

auto commit properties we can manage from sorlconfig.xml files.
<autoCommit>
       <maxTime>1000</maxTime>
  </autoCommit>


    <!-- SoftAutoCommit

         Perform a 'soft' commit automatically under certain conditions.
         This commit avoids ensuring that data is synched to disk.

         maxDocs - Maximum number of documents to add since the last
                   soft commit before automaticly triggering a new soft commit.

         maxTime - Maximum amount of time in ms that is allowed to pass
                   since a document was added before automaticly
                   triggering a new soft commit.
      -->

     <autoSoftCommit>
       <maxTime>1000</maxTime>
     </autoSoftCommit>

参照：

https://wiki.Apache.org/solr/SolrConfigXml

https://lucene.Apache.org/solr/guide/6_6/index.html

1
nagendra patod