コミットとトランザクションログ

Solr では、ドキュメントは「コミット」によって Lucene インデックスファイルが更新されるまで検索できません。コミット戦略によって、ドキュメントの追加、削除、または変更が検索可能になるタイミングが決まります。トランザクションログは、最後の「ハード」コミットポイント以降に受信したドキュメントの更新を記録します。

solrconfig.xml 内の <updateHandler>

このセクションの設定は、solrconfig.xml の <updateHandler> 要素で構成され、インデックス更新のパフォーマンスに影響を与える可能性があります。これらの設定は、内部的に更新がどのように行われるかに影響します。

<updateHandler> 要素は、solr.DirectUpdateHandler2 である必要がある class パラメータを取ります。Solr に含まれる _default configset にはこのセクションがすでに定義されていますが、以下で説明する多くのパラメータの値は、アプリケーションに合わせてカスタマイズする必要がある可能性があります。

<config>
  <updateHandler class="solr.DirectUpdateHandler2">
    ...
  </updateHandler>
</config>

<updateHandler> の構成は、クライアント更新リクエストを処理するリクエストハンドラの高レベルな構成には影響しないことに注意してください。

コミット

Solr に送信されたデータは、インデックスにコミットされるまで検索できません。これには、コミットが遅くなる場合があり、データの上書きを避けるために、他の可能なコミットリクエストから分離して実行する必要があるという理由があります。

ハードコミットとソフトコミット

Solr は、ハードコミットとソフトコミットの 2 種類のコミットをサポートしています。

ハードコミットは、インデックスファイルが安定したストレージにフラッシュされたことを保証するために、インデックスファイルに対してfsyncを呼び出します。現在のトランザクションログは閉じられ、新しいトランザクションログが開かれます。ハードコミットがない場合にデータがどのように復旧されるかについては、以下のトランザクションログのセクションを参照してください。オプションで、ハードコミットはドキュメントを検索可能にすることもできますが、ソフトコミットよりもコストがかかるため、一部のユースケースでは理想的ではない場合があります。デフォルトでは、コミットアクションは、すべてのLuceneインデックスファイルを安定したストレージ（ディスク）にハードコミットします。

ソフトコミットは、インデックスの変更を可視化するだけで、インデックスファイルのfsync、新しいセグメントの開始、新しいトランザクションログの開始を行わないため、高速です。NRT要件のある検索コレクションは、アプリケーションの可視性要件を満たすために、十分に頻繁にソフトコミットする必要があります。ソフトコミットはハードコミット（openSearcher=true）よりも「安価」である可能性がありますが、無料ではありません。アプリケーションの要件を考慮して、可能な限り長く設定することをお勧めします。

ハードコミットは、サーバーがクラッシュした場合、Solrがデータの保存場所を正確に把握していることを意味します。ソフトコミットは、データが保存されているが、場所の情報がまだ保存されていないことを意味します。トレードオフは、バックグラウンドのマージが完了するのを待たないため、ソフトコミットの方がより迅速に可視化されることです。

明示的なコミット

クライアントが更新リクエストでcommit=trueパラメーターを含めると、更新の追加および削除によって影響を受けるすべてのインデックスセグメントが、インデックスの更新が完了するとすぐにディスクに書き込まれることが保証されます。

追加のパラメーターsoftCommit=trueが指定されている場合、Solrはソフトコミットを実行します。これは、バックグラウンドのマージとストレージ（SolrCloudを使用している場合はZooKeeperへのストレージ）が完了するのを待たずに次の処理に進むことができるため、ドキュメントの可視性を高める機能であるNear Real Timeストレージの実装です。

インデックス作成中の明示的なコミットリクエストの使用に関する詳細は、更新ハンドラーを使用したインデックス作成セクションにあります。

Near Real Time操作の詳細については、Near Real Timeユースケースを参照してください。

自動コミット

インデックス作成中に明示的なコミットコマンドを送信することを避け、コミットが発生するタイミングを制御するために、solrconfig.xmlでautoCommitパラメーターを構成することができます。

これは、コミット戦略をより細かく制御できるため、インデックスクライアントから明示的なコミットを送信するよりも推奨されます。solrconfig.xmlにはデフォルトが提供されていますが、それらはあなたのニーズに合わせて調整されている可能性は非常に低く、効果的に調整しないとパフォーマンスの問題を引き起こす可能性があることに注意してください。

これらの設定は、保留中の更新がインデックスに自動的にプッシュされる頻度を制御します。

maxDocs

オプション

デフォルト: なし

最後のコミット以降に発生した更新の数。

maxTime

オプション

デフォルト: なし

コミットされていない最も古い更新からの経過ミリ秒数。大量のドキュメントを送信する場合、このパラメーターはmaxDocsよりも推奨されます。

maxSize

オプション

デフォルト: なし

ハードコミットがトリガーされる、ディスク上のトランザクションログ（tlog）の最大サイズ。ドキュメントのサイズが不明で、トランザクションログのサイズを妥当なサイズに制限することが目的の場合に役立ちます。

有効な値は、バイト（サフィックスなしのデフォルト）、キロバイト（25kのようにkサフィックスで定義した場合）、メガバイト（m）、またはギガバイト（g）にすることができます。

openSearcher

オプション

デフォルト: true

コミットを実行するときに新しい検索を開くかどうか。これがfalseの場合、コミットは最近のインデックス変更を安定したストレージにフラッシュしますが、これらの変更を可視化するために新しい検索を開きません。

maxDocs、maxTime、またはmaxSizeの制限のいずれかに達すると、Solrは自動的にコミット操作を実行します。これらのしきい値の最初に達したものがコミットをトリガーします。

solrconfig.xmlにautoCommitタグがない場合、明示的なコミットのみがインデックスを更新します。autoCommitを使用するかどうかの決定は、アプリケーションのニーズによって異なります。

<autoCommit>
  <maxDocs>10000</maxDocs>
  <maxTime>30000</maxTime>
  <maxSize>512m</maxSize>
  <openSearcher>false</openSearcher>
</autoCommit>

autoSoftCommitタグを使用して、「ソフト」自動コミットを指定することもできます。

<autoSoftCommit>
  <maxTime>5000</maxTime>
</autoSoftCommit>

自動コミットのベストプラクティス

最適なautoCommit設定を決定することは、パフォーマンスと精度の間のトレードオフです。頻繁な更新を引き起こす設定は、新しいコンテンツがより迅速に検索可能になるため、検索の精度が向上しますが、頻繁な更新のためにパフォーマンスが低下する可能性があります。更新頻度が低いとパフォーマンスが向上する可能性がありますが、更新がクエリに表示されるまで時間がかかります。

以下は、2種類のコミットのNRT構成の例です。60秒ごとのハードコミットと、10秒ごとのソフトコミットです。これらは、Solrに付属している例の値ではありませんので注意してください。

<autoCommit>
  <maxTime>${solr.autoCommit.maxTime:60000}</maxTime>
  <openSearcher>false</openSearcher>
</autoCommit>

<autoSoftCommit>
   <maxTime>${solr.autoSoftCommit.maxTime:10000}</maxTime>
 </autoSoftCommit>
これらのパラメーターは、Java「システム変数」を定義することで、実行時にオーバーライドできます。たとえば、`-Dsolr.autoCommit.maxTime=15000を指定すると、ハードコミット間隔が15秒の値でオーバーライドされます。

autoCommit（openSearcher=falseを使用）とautoSoftCommitの選択は、異なる結果をもたらします。異常なシャットダウンが発生した場合、Solrがトランザクションログからコミットされていないドキュメントを再生するのに、autoCommitで指定された時間までかかる可能性があります。

autoSoftCommitに選択された時間は、ドキュメントがSolrに送信されてから検索可能になるまでの最大時間を決定し、トランザクションログには影響しません。

この値には、アプリケーションが許容できる限り長い間隔を選択してください。多くの場合、15〜60秒が妥当であり、要件によってはさらに長くなる場合もあります。時間が非常に短い間隔（たとえば1秒）に設定されている場合は、キャッシュ（特にqueryResultCacheとfilterCache）のユーティリティがほとんどなくなるため、キャッシュを無効にすることを検討してください。

特に検索がない場合の初期ロードなど、非常に大量のインデックス作成の場合は、maxTimeパラメーターに-1の値を指定して、autoSoftCommitをオフにすることを検討してください。

時間内コミット

autoCommitの代替として、Solrへの更新リクエスト（つまり、ドキュメントのプッシュ）時、または更新リクエストハンドラーで定義できるcommitWithinを使用できます。

commitWithin設定を使用すると、定義された時間内にドキュメントのコミットを強制的に実行できます。これは、Near Real Timeユースケースで最も頻繁に使用され、そのためデフォルトではソフトコミットを実行します。ただし、これは、ユーザーが管理するクラスター内のフォロワーサーバーに新しいドキュメントを複製しません。それが実装の要件である場合は、この例のようにパラメーターを追加して、ハードコミットを強制できます

<commitWithin>
  <softCommit>false</softCommit>
</commitWithin>

この構成では、更新メッセージの一部としてcommitWithinを呼び出すと、毎回自動的にハードコミットが実行されます。

トランザクションログ

トランザクションログ（tlog）は、最後のハードコミット以降の更新の「ローリングウィンドウ」です。現在のトランザクションログは閉じられ、何らかの種類のハードコミットが発生するたびに新しいトランザクションログが開かれます。ソフトコミットはトランザクションログに影響を与えません。

tlogが有効になっている場合、インデックスに追加されるドキュメントは、インデックス作成呼び出しがクライアントに返される前にtlogに書き込まれます。異常なシャットダウン（電源喪失、JVMクラッシュ、kill -9など）が発生した場合、Solrが停止したときにtlogに書き込まれたが、まだハードコミットでコミットされていないドキュメントは、起動時に再生されます。したがって、データは失われません。

Solrが正常にシャットダウンされた場合（bin/solr stopコマンドを使用）、Solrはtlogファイルとインデックスセグメントを閉じるため、起動時に再生する必要はありません。

混乱の1つは、トランザクションログに含まれるデータの量です。tlogにはすべてのドキュメントが含まれているのではなく、最後のハードコミット以降のドキュメントのみが含まれています。古いトランザクションログファイルは、不要になると削除されます。

上記から暗黙的に、ハードコミットが無効になっている場合、トランザクションログは永久に大きくなるということです。したがって、インデックス作成時にはハードコミットを有効にすることが重要です。

トランザクションログの構成

トランザクションログは、すべてのSolrCloudクラスターと、RealTime Get機能に必要です。solrconfig.xmlのupdateHandlerセクションで構成されます。

トランザクションログは、次のようなセクションのsolrconfig.xmlで構成されます。

<updateLog>
  <str name="dir">${solr.ulog.dir:}</str>
</updateLog>

必須のパラメーターは

dir

必須

デフォルト: なし

トランザクションログの場所。Solrのデフォルトのsolrconfig.xmlファイルでは、これは${solr.ulog.dir:}として定義されています。

デフォルト値で示されているように、トランザクションログの場所は、solrconfig.xmlで定義され、Solrが書き込みと読み取りができる限り、どこでも構いません。

インデックス作成のパフォーマンスと、レプリカが完全なリカバリに入る前に更新でどれだけ遅れる可能性があるかに影響を与える、3つの追加のエキスパートレベルの構成設定があります。これらの設定は、主にSolrCloudクラスター構成に影響を与えます

numRecordsToKeep

オプション

デフォルト: 100

すべてのトランザクションログファイルで保持する更新レコードの最小数。

maxNumLogsToKeep

オプション

デフォルト: 10

保持するトランザクションログファイルの最大数。

numVersionBuckets

オプション

デフォルト: 65336

並べ替えられた更新をチェックするときに、最大バージョン値を追跡するために使用されるバケットの数。大量のインデックス作成中にバージョンバケットへのアクセスの同期コストを削減するには、この値を増やします。これには、Solrコアごとに(8 バイト（long）* numVersionBuckets)のヒープスペースが必要です。

syncLevel

オプション

デフォルト: FLUSH

トランザクションログファイルの同期レベル。NONE、FLUSH、またはFSYNCを指定できます。何も設定されていない場合、FLUSHがデフォルトです。

これらの構成オプションは、次のように機能します

  • FSYNC：Solr内部バッファは、基礎となるファイルシステム固有のバッファに明示的にフラッシュされ、トランザクションログファイルにもフラッシュされます。これはよりコストのかかる操作ですが、コンテンツがトランザクションログファイルに書き込まれるため、より安全です。

  • FLUSH：Solr内部バッファのみを基礎となるファイルシステム固有のバッファに明示的にフラッシュしますが、このバッファはトランザクションログファイルに明示的にフラッシュされません。これはコストが安くなりますが、ファイルシステム固有のバッファもフラッシュする前にクラッシュが発生した場合、そのバッファのデータが失われるため、安全性も低くなります。

  • NONE：バッファの明示的なフラッシュはありません。この構成オプションは最も安価ですが、最も安全性が低くなります。

上記の上級設定を採用した、solrconfig.xmlの<updateHandler>の下に含める例

<updateLog>
  <str name="dir">${solr.ulog.dir:}</str>
  <int name="numRecordsToKeep">500</int>
  <int name="maxNumLogsToKeep">20</int>
  <int name="numVersionBuckets">65536</int>
  <str name="syncLevel">FSYNC</str>
</updateLog>

イベントリスナー

UpdateHandlerセクションは、更新関連のイベントリスナーを構成できる場所でもあります。これらは、コミット後（event="postCommit"）または最適化コマンド後（event="postOptimize"）にのみトリガーされるように構成できます。

ユーザーは、Solrプラグインでカスタムの更新イベントリスナークラスを作成できます。Solr 7.1以降、セキュリティ上の理由からRunExecutableListenerは削除されました。

その他の<updateHandler>オプション

場合によっては、複雑な更新（空間/形状など）は完了するまでに非常に長い時間がかかる場合があります。デフォルトの構成では、同じ内部バージョンバケットに分類される他の更新は無期限に待機します。最終的に、これらの未処理のリクエストが積み重なり、スレッドの枯渇や場合によってはOutOfMemoryエラーにつながる可能性があります。

パラメーターversionBucketLockTimeoutMsは、長時間の更新リクエストのタイムアウトを指定することで、それを防ぐのに役立ちます。この制限に達すると更新は失敗しますが、他のすべての更新を永遠にブロックすることはありません。

この設定にはメモリコストが伴います。デフォルト値の0（無制限タイムアウト）より大きな値を設定すると、Solrはバージョンバケットの内部実装を別のものを使用するようになり、それによって、Solrコアごとに約1.5MBから約6.8MBへとメモリ消費量が増加します。

solrconfig.xmlの<config>セクションでこのオプションを指定する例:

<updateHandler class="solr.DirectUpdateHandler2">
  ...
  <int name="versionBucketLockTimeoutMs">10000</int>
</updateHandler>