インデックス更新戦略

Version: 10.1
日本語翻訳に関する免責事項

このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。

インデックスの更新方法を使用して、インデックスを保守します。各インデックスは、インデックス更新戦略の一意のセットで構成できます。パフォーマンス上の理由から、インデックスごとに3つを超える更新方法を指定しないことをお勧めします。インデックスは、たとえばIndexing Managerやカスタムコードなどから手動で更新することもできます。

Sitecoreにはさまざまなインデックス更新戦略のセットが用意されており、このセットをさらに戦略で拡張できます。Sitecoreで提供されるすべてのストラテジーは、Sitecore.ContentSearch設定ファイルの次のノードで定義されます。

RequestResponse
sitecore/contentSearch/indexConfigurations/indexUpdateStrategies
<manual type="Sitecore.ContentSearch.Maintenance.Strategies.ManualStrategy,Sitecore.ContentSearch" />

Sitecoreには次の戦略が付属しています。

メモ

これらの戦略の一部は、CrawlingLogファイルを使用します。CrawlingLogファイル内のメッセージを有効にするには、パッチ・ファイルを使用して、Sitecore.Diagnostics.CrawlingロガーのDEBUG・レベルを有効にする必要があります。例えば：

RequestResponse
<logger name="Sitecore.Diagnostics.Crawling" additivity="false">
    <level value="DEBUG"/>
    <appender-ref ref="CrawlingLogFileAppender"/>
</logger>

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戦略をインデックスにアタッチする

この戦略をインデックスにアタッチするには、次の方法を使用します。

RequestResponse
<index id="sitecore_index" type="Sitecore.ContentSearch.SolrProvider.
          SolrIndex, Sitecore.ContentSearch.SolrProvider">
   <param desc="name">$(id)</param>
   <param desc="folder">$(id)</param>
   <strategies hint="list:AddStrategy">
      <strategy ref="contentSearch/indexConfigurations/indexUpdateStrategies/rebuildAfterFullPublish" />
   </strategies>
   <Analyzer ref="search/analyzer" />

ベストプラクティス

このストラテジを同期ストラテジと組み合わせることはできませんが、他のストラテジと組み合わせることはできます。

この戦略ではインデックスが完全に再構築されるため、SwitchOnRebuildSolrSearchIndexと組み合わせる必要があります。

OnPublishEndAsync戦略

この戦略は、設定ファイルで次のように定義します。

RequestResponse
<onPublishEndAsync type="Sitecore.ContentSearch.Maintenance.Strategies.
           OnPublishEndAsynchronousStrategy, Sitecore.ContentSearch">
          <param desc="database">web</param>
          <CheckForThreshold>true</CheckForThreshold>
</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テーブルには、インデックスの最終更新タイムスタンプより後の日付のエントリが必要です。

項目の変更に関連する未処理のイベントの数がしきい値を超えると、増分更新ではなく、完全なインデックス再構築がトリガーされます。

アイテムの変更に関連するイベントは次のとおりです。

  • RemovedVersionRemoteEvent

  • SavedItemRemoteEvent

  • DeletedItemRemoteEvent

  • MovedItemRemoteEvent

  • AddedVersionRemoteEvent

  • CopiedItemRemoteEvent

  • RestoreItemCompletedEvent

未処理のイベントは、スタンプ値がLAST_UPDATED_TIMESTAMPプロパティの値よりも高いアイテム変更イベントです。このプロパティは、PropertyStoreProvider設定のdefaultStore属性によって決定されるシステム プロパティ テーブルに格納されます。このプロパティは、検索インデックスとインスタンスごとに一意です (例: CORE_SITECORE_MASTER_INDEX_MyMachineName-MySite.local_LAST_UPDATED_TIMESTAMP)。

しきい値はContentSearch.FullRebuildItemCountThreshold設定によって設定され、すべてのインデックス更新ストラテジーで共有されます。この設定は非表示になっています:設定では使用できませんが、手動で追加できます。設定のデフォルト値は100,000です。

しきい値の最適値は、次の条件によって異なります。

  • 検索インデックス内のドキュメントの合計数。たとえば、検索インデックスに50,000個のドキュメントが含まれている場合、しきい値を25,000に設定できます。

  • add操作とremove操作の比率 (更新はremoveとaddに相当します)。remove操作がadd操作やupdate操作よりも頻繁に行われる場合は、しきい値を下げることができます。

操作が多数ある場合は、delete、add、およびupdateのすべての操作を個別に処理するよりも、インデックスを最初から作成する (add操作を使用して) 方が高速かどうかを検討してください。

しきい値のチェックは、ストラテジごとに無効にできます <CheckForThreshold>false<CheckForThreshold>。この設定をtrueに設定した場合は、このストラテジを使用するインデックスに対してもSwitchOnRebuildSolrSearchIndex実装を使用することをお勧めします。

ContentSearch.FullRebuildItemCountThreshold設定の値のデフォルトは100,000です。

OnPublishEndAsync戦略をインデックスにアタッチする

この戦略をインデックスにアタッチするには、次の方法を使用します。

RequestResponse
<index id="sitecore_index" type="Sitecore.ContentSearch.SolrProvider.SolrSearchIndex, 
         Sitecore.ContentSearch.SolrProvider">
    <param desc="name">$(id)</param>
    <param desc="core">$(id)</param>
    <param desc="propertyStore"
        ref="contentSearch/indexConfigurations/databasePropertyStore"
        param1="$(id)" />
   <strategies hint="list:AddStrategy">
      <strategy ref="contentSearch/indexConfigurations/indexUpdateStrategies/onPublishEndAsync" />
   </strategies>

ベストプラクティス

この戦略を次の戦略と組み合わせないでください。

  • 同期

  • インターバル非同期

  • OnPublishEndAsyncSingleInstance

次の戦略と組み合わせることができます。

  • RebuildAfterFullPublish (英語)

  • リモートリビルド

この戦略は、EventQueueを既に有効にしているマルチサーバー/マルチインスタンス環境で使用できます。

OnPublishEndAsyncSingleInstance戦略

この戦略は、設定ファイルで次のように定義します。

RequestResponse
<onPublishEndAsyncSingleInstance type="Sitecore.ContentSearch.Maintenance.Strategies.OnPublishEndAsynchronousSingleInstanceStrategy, Sitecore.ContentSearch" singleInstance="true">
  <param desc="database">web</param>
  <CheckForThreshold>true</CheckForThreshold>
</onPublishEndAsyncSingleInstance>

加工

OnPublishEndAsync戦略と同様に、この戦略はOnPublishEndイベントによってトリガーされます。イベント キューによって決定された項目の変更に対して増分更新操作を開始します。

これらの戦略の主な違いは、OnPublishEndAsyncSingleInstance戦略がトリガされると、イベント レコードが1回だけ取得され、アタッチされているすべてのインデックスで再利用されるのに対し、OnPublishEndAsync戦略ではインデックスごとにレコードが個別に取得される点です。

この異なる動作により、データベースの負荷が軽減され、Sitecoreインスタンスによるリソース消費が減少します。

OnPublishEndAsyncSingleInstanceストラテジーのインデックスへのアタッチ

この方針をインデックスにアタッチするには、次の方法を使用します。

RequestResponse
<index id="sitecore_web_index" type="Sitecore.ContentSearch.SolrProvider.SolrSearchIndex, Sitecore.ContentSearch.SolrProvider">
    ...
   <strategies hint="list:AddStrategy">
        <strategy ref="contentSearch/indexConfigurations/indexUpdateStrategies/onPublishEndAsyncSingleInstance" />
    </strategies>
        ...
</index>

ベストプラクティス

パブリッシュされたコンテンツを含む同じデータベースをカバーする複数のインデックスがある場合は、onPublishEndAsyncSingleInstance戦略を使用することをお勧めします。

この戦略を次の戦略と組み合わせないでください。

  • 同期

  • インターバル非同期

  • OnPublishEndAsync

次の戦略と組み合わせることができます。

  • RebuildAfterFullPublish (英語)

  • リモートリビルド

IntervalAsynchronous戦略

この戦略は、設定ファイルで次のように定義します。

RequestResponse
<intervalAsyncMaster type="Sitecore.ContentSearch.Maintenance.Strategies.
          IntervalAsynchronousStrategy, Sitecore.ContentSearch">
   <param desc="database">master</param>
   <param desc="interval">00:00:10</param>
   <CheckForThreshold>true</CheckForThreshold>
</intervalAsyncMaster>

  • 処理のアイテム変更を検索するデータベースは、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秒ごとに起動するように設定されています。

RequestResponse
<intervalAsync type="Sitecore.ContentSearch.Maintenance.Strategies.
         IntervalAsynchronousStrategy, Sitecore.ContentSearch">
   <param desc="database">web</param>
   <param desc="interval">00:00:10</param>
   <CheckForThreshold>true</CheckForThreshold>
</intervalAsync>

しきい値はContentSearch.FullRebuildItemCountThreshold設定によって設定され、すべてのインデックス更新ストラテジーで共有されます。この設定は非表示になっています:設定では使用できませんが、手動で追加できます。設定のデフォルト値は100,000です。

しきい値の最適値は、次の条件によって異なります。

  • 検索インデックス内のドキュメントの合計数。たとえば、検索インデックスに50,000個のドキュメントが含まれている場合、しきい値を25,000に設定できます。

  • add操作とremove操作の比率 (更新はremoveとaddに相当します)。remove操作がadd操作やupdate操作よりも頻繁に行われる場合は、しきい値を下げることができます。

操作が多数ある場合は、delete、add、およびupdateのすべての操作を個別に処理するよりも、インデックスを最初から作成する (add操作を使用して) 方が高速かどうかを検討してください。

しきい値のチェックは、ストラテジごとに無効にできます <CheckForThreshold>false<CheckForThreshold>。この設定をtrueに設定した場合は、このストラテジを使用するインデックスに対してもSwitchOnRebuildSolrSearchIndex実装を使用することをお勧めします。

Sitecoreが提供する設定ファイルでは、ContentSearch.FullRebuildItemCountThreshold設定は有効になっていません。デフォルトは100,000です。

インデックスへのIntervalAsynchronousストラテジーのアタッチ

この戦略をインデックスにアタッチするには、次の方法を使用します。

RequestResponse
<index id="sitecore_index" type="Sitecore.ContentSearch.SolrProvider.SolrSearchIndex, 
 Sitecore.ContentSearch.SolrProvider">
 <param desc="name">$(id)</param>
 <param desc="core">$(id)</param>
 <param desc="propertyStore"
 ref="contentSearch/indexConfigurations/databasePropertyStore"
 param1="$(id)" />
 <strategies hint="list:AddStrategy">
 <strategy ref="contentSearch/indexConfigurations/indexUpdateStrategies/intervalAsync" />
 </strategies>

ベストプラクティス

この戦略を次の戦略と組み合わせないでください。

  • シンクロナスストラテジー

  • OnPublishEndAsync

  • OnPublishEndAsyncSingleInstance

次の戦略と組み合わせることができます。

  • RebuildAfterFullPublish (英語)

  • リモートリビルド

この戦略は、masterデータベース インデックスや、使用するリソースをできるだけ少なくする単一サーバー環境に使用することをお勧めします。

この戦略は、頻繁に更新する必要のない重要度の低いインデックスにも役立ちます。必要に応じて間隔を調整できます。

この戦略は、Sitecoreが提供するセットアップのコア データベースとマスター データベースに対して作成されます。

RequestResponse
            <intervalAsyncCore type="Sitecore.ContentSearch.Maintenance.Strategies.
                     IntervalAsynchronousStrategy, Sitecore.ContentSearch">
               <param desc="database">core</param>
               <param desc="interval">00:01:00</param>
               <CheckForThreshold>true</CheckForThreshold>
            </intervalAsyncCore>
            <intervalAsyncMaster type="Sitecore.ContentSearch.Maintenance.Strategies.
                     IntervalAsynchronousStrategy, Sitecore.ContentSearch">
               <param desc="database">master</param>
               <param desc="interval">00:00:10</param>
               <CheckForThreshold>true</CheckForThreshold>
            </intervalAsyncMaster>

同期戦略

この戦略は、リアルタイムに最も近いインデックス更新戦略です。また、CPUとI/Oの点で最もコストのかかる戦略でもあります。

この戦略を使用する前に、ベスト プラクティスについて理解しておく必要があります。

この方針は、次のように指定します。

RequestResponse
<sync type="Sitecore.ContentSearch.Maintenance.Strategies.SynchronousStrategy, Sitecore.ContentSearch" />

このストラテジーをインデックスにアタッチして初期化すると、CrawlingLogファイルに次のメッセージが表示されます。

Initializing SynchronousStrategy for index '<index_name>'.

このストラテジがトリガーされると、CrawlingLogファイルに次のメッセージが表示されます。

SynchronousStrategy triggered on index '<index_name>'

加工

この戦略は、ItemSavedやItemSavedRemoteなどの低レベルのDataEngineイベントにサブスクライブします。単一サーバーインスタンスで使用すると、項目の更新直後にインデックスが更新されることが保証されます。

マルチサーバー環境では、この戦略はリモートItemSavedRemoteイベントをブロードキャストするEventQueueを使用します。アイテムがパブリッシュされ、ItemSavedRemoteイベントが発生すると、ストラテジがトリガーされます。

同期ストラテジーのインデックスへのアタッチ

この戦略をインデックスにアタッチするには、次の方法を使用します。

RequestResponse
<index id="sitecore_index" type="Sitecore.ContentSearch.SolrProvider.SolrIndex, 
 Sitecore.ContentSearch.SolrProvider">
 <param desc="name">$(id)</param>
 <param desc="core">$(id)</param>
 <param desc="propertyStore"
 ref="contentSearch/indexConfigurations/databasePropertyStore"
 param1="$(id)" />
 <strategies hint="list:AddStrategy">
 <strategy ref="contentSearch/indexConfigurations/indexUpdateStrategies/sync" />
 </strategies>

ベストプラクティス

この戦略は、インデックスを即時に更新する必要があり、処理リソースが豊富な専用のインデックス サーバー インフラストラクチャがある場合は、この戦略を使用します。CMサーバで同期方式を使用するのは、masterデータベースを処理するインデックスと、インデックス更新のタイミングが重要な場合のみです。

この戦略を、多くのエントリが追加および変更されるCMサーバーで使用すると、システムのパフォーマンスが大幅に低下する可能性があります。ほとんどの場合、masterデータベース用に構成されたIntervalAsyncronous 戦略で十分です。

BulkUpdateContextで発生した変更はこの戦略では処理されず、検索インデックスを同期に戻すには、インデックスを完全に再構築する必要があります。BulkUpdateContextを定期的に使用する場合は、非同期戦略を使用することをお勧めします。

この方針は、次の方針とのみ組み合わせることができます。

  • リモートリビルド

この戦略には、次の前提条件があります。

  • この戦略では、項目の変更が発生するのと同じインスタンスで戦略を使用する場合、EventQueueを有効にする必要はありません。たとえば、ソリューションにCMインスタンスが1つしかない場合は、同期戦略を使用してmasterデータベースの変更を処理できます。ただし、複数のCMインスタンスがある場合は、異なるインスタンス間でイベントを共有するためにEventQueueを有効にする必要があります。

RemoteRebuild戦略

この戦略は、OnIndexingEndedRemoteイベントにサブスクライブします。このイベントは、特定のインデックスが再構築されたときにトリガーされます。この方針は、完全なインデックス再構築が行われる場合にのみアクティブになります。

このメカニズムを使用して、インデックスの再構築を強制するときにリモート・インデックスを再構築します。この戦略は、次のように指定します。

RequestResponse
<remoteRebuild type="Sitecore.ContentSearch.Maintenance.Strategies.
          RemoteRebuildStrategy, Sitecore.ContentSearch" />

RemoteRebuildストラテジーのインデックスへのアタッチ

この戦略をインデックスにアタッチするには、次の方法を使用します。

RequestResponse
<index id="sitecore_index" type="Sitecore.ContentSearch.SolrProvider.SolrSearchIndex, 
 Sitecore.ContentSearch.SolrProvider">
 <param desc="name">$(id)</param>
 <param desc="core">$(id)</param>
 <param desc="propertyStore"
 ref="contentSearch/indexConfigurations/databasePropertyStore"
 param1="$(id)" />
 <strategies hint="list:AddStrategy">
 <strategy ref="contentSearch/indexConfigurations/indexUpdateStrategies/remoteRebuild" />
 </strategies>

ベストプラクティス

この戦略は、他の戦略と組み合わせることができます。これは、各Sitecoreインスタンスがインデックスの独自のコピーを保持するマルチサーバー環境で使用します。その後、1つのCMサーバから完全な再構築をトリガすると、この戦略でインデックスが構成されているすべてのリモート・サーバが再構築されます。

この戦略には、次の前提条件があります。

  • リモート・サーバー上のインデックスの名前は、強制的に再構築したインデックスの名前と同じである必要があります。

  • EventQueueを有効にする必要があります。

  • システム イベント キュー ストレージ (デフォルトではcore ) に割り当てるデータベースは、再構築が行われるSitecoreインスタンスと他のインスタンス間で共有する必要があります。

手動戦略

この方法では、インデックスの自動更新が無効になります。この戦略をインデックスに使用する場合は、このインデックスを手動で再構築する必要があります。

この戦略は、次のように指定します。

RequestResponse
<manual type="Sitecore.ContentSearch.Maintenance.Strategies.ManualStrategy, 
          Sitecore.ContentSearch" />

このストラテジーをインデックスにアタッチして初期化すると、CrawlingLogファイルに次のメッセージが表示されます。

Initializing ManualStrategy for index '<index_name>'.

Index will have to be rebuilt manually

インデックスへの手動ストラテジーのアタッチ

この戦略をインデックスにアタッチするには、次の方法を使用します。

RequestResponse
<index id="sitecore_index" type="Sitecore.ContentSearch.SolrProvider.SolrSearchIndex, 
 Sitecore.ContentSearch.SolrProvider">
 <param desc="name">$(id)</param>
 <param desc="core">$(id)</param>
 <param desc="propertyStore"
 ref="contentSearch/indexConfigurations/databasePropertyStore"
 param1="$(id)" />
 <strategies hint="list:AddStrategy">
 <strategy ref="contentSearch/indexConfigurations/indexUpdateStrategies/manual" />
 </strategies>

ベストプラクティス

この戦略を他の戦略と組み合わせないでください。これは、インデックス作成プロセス全体を専用サーバーにアウトソーシングする必要があり、他のSitecoreインスタンスでインデックスを更新したくないという特別な状況のために予約されています。

何かフィードバックはありますか?

この記事を改善するための提案がある場合は、