インデックス更新戦略
このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。
インデックスの更新方法を使用して、インデックスを保守します。各インデックスは、インデックス更新戦略の一意のセットで構成できます。パフォーマンス上の理由から、インデックスごとに3つを超える更新方法を指定しないでください。
Sitecoreにはさまざまなインデックス更新戦略のセットが用意されており、このセットをさらに戦略で拡張できます。Sitecoreで提供されるすべてのストラテジーは、Sitecore.ContentSearch設定ファイルの次のノードで定義されます。
Sitecoreには次の戦略が付属しています。
-
RebuildAfterFullPublish (英語)
-
OnPublishEndAsync
-
インターバル非同期
-
同期
-
リモートリビルド
-
TimedIndexRefresh(タイムドインデックスリフレッシュ)
-
手動
RebuildAfterFullPublish戦略
RebuildAfterFullPublish戦略
この戦略は、設定ファイルで次のように定義します。
<rebuildAfterFullPublish type="Sitecore.ContentSearch.Maintenance.Strategies. RebuildAfterFullPublishStrategy,Sitecore.ContentSearch" />
初期化中に、この戦略はOnFullPublishEndイベントにサブスクライブし、完全なインデックスの再構築をトリガーします。
分散環境では、インデックスの再構築は、このストラテジが構成されているすべてのリモート・サーバでトリガされます。この場合、イベントキューを有効にする必要があります。
完全な発行を定期的に実行する必要がある環境では、インデックスの増分再構築をトリガーしないでください。これは、多くのリソースを使用するためです。代わりに、この戦略では、完全な発行プロセスが完了したときに完全なインデックスの再構築がトリガーされます。
このストラテジをインデックスにアタッチすると、初期化時にCrawlingLogファイルに次のメッセージが表示されます。
Initializing RebuildAfterFullPublishStrategy for index '<index_name>'
このストラテジがトリガーされると、CrawlingLogファイルに次のメッセージが表示されます。
RebuildAfterFullPublishStrategy triggered on index '<index_name>'
RebuildAfterFullPublish戦略をインデックスにアタッチする
この戦略をインデックスにアタッチするには、次の方法を使用します。
ベストプラクティス
このストラテジを同期ストラテジと組み合わせる必要はありませんが、他のストラテジと組み合わせることはできます。
この戦略ではインデックスが完全に再構築されるため、SwitchOnRebuildLuceneIndexまたは SwitchOnRebuildSolrSearchIndexと組み合わせる必要があります。
この戦略をOnPublishEndAsync戦略と組み合わせて使用する場合は、最初にトリガーされるように、リストの最初のエントリとして登録する必要があります。
OnPublishEndAsync戦略
OnPublishEndAsync戦略
この戦略は、設定ファイルで次のように定義します。
初期化中に、このストラテジーはOnPublishEndイベントをサブスクライブし、増分インデックス再構築をトリガーします。
CMサーバとCDサーバが別々にある場合、このイベントはEventQueueオブジェクトを介してトリガされます。つまり、このストラテジがこの種の環境で機能するには、EventQueueオブジェクトを有効にする必要があります。
OnPublishEndAsynchronousStrategyクラスのコンストラクタに渡される追加のdatabaseパラメータがあります。このパラメータは、アイテムの変更を検索するデータベースを定義します。
このストラテジをインデックスにアタッチして初期化すると、CrawlingLogファイルに次のメッセージが表示されます。
Initializing OnPublishEndAsynchronousStrategy for index '<index_name>'.
このストラテジがトリガーされると、CrawlingLogファイルに次のメッセージが表示されます。
"<index_name> OnPublishEndAsynchronousStrategy executing."
加工
この戦略では、初期化されたデータベースのEventQueueオブジェクトを使用します。
<param desc="database">web</param>
これは、この戦略がいくつかのことに依存していることを意味します。
-
このデータベースは、設定ファイルの <databases /> セクションで指定する必要があります。
-
EnableEventQueues設定はtrueである必要があります。
-
事前構成済みデータベース内のEventQueueテーブルには、インデックスの最終更新タイムスタンプより後の日付のエントリが必要です。
この戦略では、履歴テーブルのエントリ数がIndexing.FullRebuildItemCountThreshold設定で定義された数を超えた場合に、インデックスの完全な再構築が強制されます。これは、イベントキューの過剰な処理を防ぐためです。ほとんどの場合、これは大規模な発行またはデプロイがあったために発生し、これにより常に完全なインデックスの再構築がトリガーされます。
この動作は、設定ファイルの次のプロパティがtrueに設定されている場合にのみトリガーされます (これがデフォルトです)。
<CheckForThreshold>true</CheckForThreshold>
この設定をtrueとして指定する場合は、このストラテジを使用するインデックスに対してSwitchOnRebuildLuceneIndexまたはSwitchOnRebuildSolrSearchIndex実装も使用することをお勧めします。
Indexing.FullRebuildItemCountThreshold設定の値のデフォルトは100000です。
OnPublishEndAsync戦略をインデックスにアタッチする
この戦略をインデックスにアタッチするには、次の方法を使用します。
ベストプラクティス
この戦略を次の戦略と組み合わせないでください。
-
同期
-
インターバル非同期
次の戦略と組み合わせることができます。
-
RebuildAfterFullPublish (英語)
-
リモートリビルド
この戦略は、EventQueueを既に有効にしているマルチサーバー/マルチインスタンス環境で使用する必要があります。
IntervalAsynchronous戦略
IntervalAsynchronous戦略
この戦略は、設定ファイルで次のように定義します。
-
処理のアイテム変更を検索するデータベースは、databaseパラメータを使用して指定します。
-
ストラテジートリガーの頻度は、intervalパラメーターで指定します。
このストラテジーをインデックスにアタッチして初期化すると、CrawlingLogファイルに次のメッセージが表示されます。
Initializing IntervalAsynchronousUpdateStrategy for index '<index_name>'.
このストラテジがトリガーされると、CrawlingLogファイルに次のメッセージが表示されます。
IntervalAsynchronousUpdateStrategy triggered on index '<index_name>'
加工
この戦略は、OnPublishEndイベントではなく、時間間隔によってトリガーされます。ソースデータベースのEventQueueテーブルを使用します。 sourceデータベースは、ストラテジーのdatabaseパラメータによって指定されます。例えば:
<param desc="database">web</param>
この戦略を使用するための前提条件は次のとおりです。
-
EnableEventQueues設定はtrueである必要があります。
-
参照されるデータベースは、<databases> 構成セクションで定義する必要があります
-
参照されるデータベースは、クロールする検索インデックスで定義されている少なくとも1つのデータベースと一致する必要があります
この戦略では、事前定義された間隔値で初期化された内部タイマーを使用します。このストラテジーは、タイマーが発火したときにトリガーされます。この例では、タイマーは10秒ごとに起動するように設定されています。
この戦略では、履歴テーブルのエントリ数がIndexing.FullRebuildItemCountThreshold設定で指定した数を超えた場合に、インデックスの完全な再構築が強制されます。これは通常、大量の公開またはデプロイが行われたことを意味し、これにより常に完全なインデックスの再構築がトリガーされます。
この動作は、このプロパティをtrue (既定値) に設定した場合にのみトリガーされます。
<CheckForThreshold>true</CheckForThreshold>
この設定をtrueに設定した場合は、SwitchOnRebuildLuceneIndexまたはSwitchOnRebuildSolrSearchIndex実装を使用する必要があります。
Sitecoreが提供する設定ファイルでは、Indexing.FullRebuildItemCountThreshold設定は有効になっていません。デフォルトは100000です。
インデックスへのIntervalAsynchronousストラテジーのアタッチ
この戦略をインデックスにアタッチするには、次の方法を使用します。
ベストプラクティス
この戦略を次の戦略と組み合わせないでください。
-
シンクロナスストラテジー
-
OnPublishEndAsync
次の戦略と組み合わせることができます。
-
RebuildAfterFullPublish (英語)
-
リモートリビルド
この方法は、masterデータベース インデックスや、使用するリソースをできるだけ少なくする単一サーバー環境で使用する必要があります。
この方法は、頻繁に更新する必要のない重要度の低いインデックスにも役立ちます。必要に応じて間隔を調整できます。
この戦略は、Sitecoreが提供するセットアップのコア データベースとマスター データベースに対して作成されます。
同期戦略
同期戦略
この戦略は、リアルタイムに最も近いインデックス更新戦略です。また、CPUとI/Oの点で最もコストのかかる戦略でもあります。
この戦略を使用する前に、ベスト プラクティスについて理解しておく必要があります。
この方針は、次のように指定します。
このストラテジをインデックスにアタッチして初期化すると、CrawlingLogファイルに次のメッセージが表示されます。
Initializing SynchronousStrategy for index '<index_name>'.
このストラテジがトリガーされると、CrawlingLogファイルに次のメッセージが表示されます。
SynchronousStrategy triggered on index '<index_name>'
加工
この戦略は、ItemSavedやItemSavedRemoteなどの低レベルのDataEngineイベントにサブスクライブします。単一サーバーインスタンスで使用すると、項目の更新直後にインデックスが更新されることが保証されます。
マルチサーバー環境では、この戦略はリモートItemSavedRemoteイベントをブロードキャストするEventQueueを使用します。アイテムがパブリッシュされ、ItemSavedRemoteイベントが発生すると、ストラテジがトリガーされます。
同期ストラテジーのインデックスへのアタッチ
この戦略をインデックスにアタッチするには、次の方法を使用します。
ベストプラクティス
この戦略は、インデックスを即時に更新する必要があり、処理リソースが豊富な専用のインデックス サーバー インフラストラクチャがある場合は、この戦略を使用します。同期戦略は、マスター・データベースを処理するインデックスと、インデックス更新のタイミングが重要な場所のCMサーバーでのみ使用してください。
この戦略を、多くのエントリが追加および変更されるCMサーバーで使用すると、システムのパフォーマンスが大幅に低下する可能性があります。ほとんどの場合、masterデータベース用に構成されたIntervalAsyncronous戦略で十分です。
この方針は、次の方針とのみ組み合わせることができます。
-
リモートリビルド
この戦略には、次の前提条件があります。
-
EventQueueを有効にする必要があります。
RemoteRebuild戦略
RemoteRebuild戦略
この戦略は、OnIndexingEndedRemoteイベントにサブスクライブします。このイベントは、特定のインデックスが再構築されたときにトリガーされます。この方針は、完全なインデックス再構築が行われる場合にのみアクティブになります。
このメカニズムを使用して、インデックスの再構築を強制するときにリモート・インデックスを再構築します。この戦略は、次のように指定します。
RemoteRebuildストラテジーのインデックスへのアタッチ
この戦略をインデックスにアタッチするには、次の方法を使用します。
ベストプラクティス
この戦略は、他の戦略と組み合わせることができます。これは、各Sitecoreインスタンスがインデックスの独自のコピーを保持するマルチサーバー環境で使用します。その後、1つのCMサーバから完全な再構築をトリガすると、この戦略でインデックスが構成されているすべてのリモート・サーバが再構築されます。
この戦略には、次の前提条件があります。
-
リモート・サーバー上のインデックスの名前は、強制的に再構築したインデックスの名前と同じである必要があります。
-
EventQueueを有効にする必要があります。
-
システム イベント キュー ストレージ (デフォルトではcore ) に割り当てるデータベースは、再構築が行われるSitecoreインスタンスと他のインスタンス間で共有する必要があります。
TimedIndexRefresh戦略
TimedIndexRefresh戦略
監視可能なクローラを使用する場合は、インデックス操作の影響を考慮する必要があります。観測可能なクローラは、常に新しいアイテムをリッスンします。クローラは、新しい項目の通知を受け取ると、インデックス操作が処理されるまで、その項目をメモリにキャッシュします。これには、次の影響があります。
-
再構築: インデックスを再構築する (既存のコンテンツをすべてクリアし、新しいアイテムをインデックス化する) と、クローラが現在保持しているアイテムのみが挿入されます。
-
インデックスの頻度: 各クローラがクロールされた各項目をメモリにキャッシュするため、メモリ使用量が大きくなりすぎる前に項目がメモリからフラッシュされるように、一貫した頻度でインデックスを作成する必要があります。
-
更新のみ: データのソースはフィードのみであり、一度にすべてのデータにアクセスできないため、インデックスで更新メソッドのみを呼び出す必要があります。
インデックスでTimedIndexRefresh戦略を使用すると、これらの問題を解決できます。この戦略では、クローラからのデータでインデックスが更新されますが、インデックスはリセットされません。
構成
このストラテジを設定するには、設定ファイルに以下を追加します。
intervalパラメーターを指定する必要があります。この例では、毎分実行するように設定されています。
手動戦略
手動戦略
この方法では、インデックスの自動更新が無効になります。この戦略をインデックスに使用する場合は、このインデックスを手動で再構築する必要があります。
この戦略は、次のように指定します。
このストラテジーをインデックスにアタッチして初期化すると、CrawlingLogファイルに次のメッセージが表示されます。
Initializing ManualStrategy for index '<index_name>'.
Index will have to be rebuilt manually
インデックスへの手動ストラテジーのアタッチ
この戦略をインデックスにアタッチするには、次の方法を使用します。
ベストプラクティス
この戦略を他の戦略と組み合わせないでください。これは、インデックス作成プロセス全体を専用サーバーにアウトソーシングする必要があり、他のSitecoreインスタンスでインデックスを更新したくないという特別な状況のために予約されています。