1. インデックスの設定

インデックス更新戦略

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

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

インデックスの更新戦略を使ってインデックスを管理します。各インデックスには固有のインデックス更新戦略セットを設定できます。パフォーマンスの理由から、1つのインデックスにつき3つ以上の更新戦略を指定するのは避けるべきです。

Sitecore多様なインデックス更新戦略を提供し、さらに多くの戦略を拡張することも可能です。Sitecoreで提供されるすべての戦略は、Sitecore.ContentSearch設定ファイルの以下のノードに定義されています。

sitecore/contentSearch/indexConfigurations/indexUpdateStrategies

Sitecoreには以下の戦略があります:

!注これらの戦略のいくつかはCrawlingLogファイルを使用します。CrawlingLogファイルのメッセージを有効にするには、Sitecore.Diagnostics.CrawlingロガーのDEBUGレベルを有効にするパッチファイルを使わなければなりません。例えば:

RebuildAfterFullPublish戦略

この戦略は設定ファイル上で次のように定義されています:

初期化時にこの戦略はOnFullPublishEndイベントにサブスクライブし、完全なインデックス再構築をトリガーします。

分散環境では、この戦略が設定されているすべてのリモートサーバーでインデックス再構築がトリガーされます。この場合、イベントキューを有効にする必要があります。

定期的にフルパブリッシュが必要な環境では、インクリメンタルインデックスの再構築は多くのリソースを消費するため、トリガーは避けるべきです。代わりに、この戦略はフルパブリッシュプロセスが完了するとフルインデックスリビルドをトリガーします。

この戦略をインデックスに付けると、初期化時にCrawlingLogファイル内に以下のメッセージが表示されます。

Initializing RebuildAfterFullPublishStrategy for index '<index_name>'

この戦略が発動すると、CrawlingLogファイルに以下のメッセージが表示されます。

RebuildAfterFullPublishStrategy triggered on index '<index_name>'

RebuildAfterFullPublish戦略をインデックスに付与する

この戦略をインデックスに次のように付与します:

$(id) $(id)

ベストプラクティス

この戦略は同期戦略と組み合わせるべきではありませんが、他の戦略と組み合わせることは可能です。

この戦略はインデックス全体の再構築を引き起こすため、SwitchOnRebuildSolrSearchIndexやSwitchOnRebuildLuceneIndexと組み合わせるべきです。

OnPublishEndAsync戦略

この戦略は設定ファイル上で次のように定義されています:

web true

初期化時にこの戦略はOnPublishEndイベントに従属し、インクリメンタルインデックスの再構築を引き起こします。

CMサーバーとCDサーバーが別々の場合、このイベントはEventQueueオブジェクトを通じてトリガーされます。つまり、この戦略がこの環境で機能するにはEventQueueオブジェクトを有効にしなければなりません。

!注OnPublishEndAsynchronousStrategyクラスのコンストラクタに渡される追加のdatabaseパラメータがあります。このパラメータは、アイテムの変更を検索するためのデータベースを定義します。

この戦略をインデックスに付けて初期化すると、CrawlingLogファイル内に以下のメッセージが表示されます。

Initializing OnPublishEndAsynchronousStrategy for index '<index_name>'.

この戦略が発動すると、CrawlingLogファイルに以下のメッセージが表示されます。

"<index_name> OnPublishEndAsynchronousStrategy executing."

加工

この戦略は、初期化されたデータベースのEventQueueオブジェクトを使用します:

web

つまり、この戦略はいくつかの要素に依存します。

  • このデータベースは設定ファイルの セクションで指定する必要があります。
  • EnableEventQueues設定はtrueでなければなりません。
  • 事前設定されたデータベース内の EventQueue テーブルには、インデックスの最後の更新タイムスタンプより後のエントリが必要です。

閾値はContentSearch.FullRebuildItemCountThreshold設定によって設定され、すべてのインデックス更新戦略で共有されます。設定は非表示で、設定内には含まれませんが、手動で追加できます。設定のデフォルト値は100,000です。

閾値の最適値は以下に依存します:

  • 検索インデックス内のドキュメントの総数。例えば、検索インデックスに50,000件のドキュメントが含まれている場合、しきい値は25,000に設定できます。
  • 追加操作と削除操作の比率(更新は削除してから追加することに相当します)。削除操作が追加や更新操作より頻繁であれば、閾値を下げることができます。

操作が多岐にわたる場合、削除、追加、更新のすべての操作を個別に処理するよりも、インデックスを一から作成(追加操作を使って)する方が速いかどうかを検討してください。

しきい値のチェックは各戦略ごとに無効にできます: false。この設定をtrueに設定した場合、この戦略を使うインデックスに対してもSwitchOnRebuildSolrSearchIndex実装を使用することを推奨します。

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

OnPublishEndAsync戦略をインデックスに付ける方法

この戦略をインデックスに次のように付与します:

$(id) $(id)

ベストプラクティス

この戦略を以下の戦略と組み合わせてはいけません。

  • 同期
  • 間隔非同期
  • OnPublishEndAsyncSingleInstance

以下の戦略と組み合わせることができます:

  • RebuildAfterFullPublish
  • リモートリビルド

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

OnPublishEndAsyncSingleInstance戦略

この戦略は設定ファイル上で次のように定義されています:

web true

加工

OnPublishEndAsync戦略と同様に、この戦略もOnPublishEndイベントによってトリガーされます。イベントキューによって決定されたアイテム修正に対して、増分的な更新操作を開始します。

これらの戦略の主な違いは、OnPublishEndAsyncSingleInstance戦略がトリガーされるとイベントレコードを一度だけ取得し、それに紐づいたすべてのインデックスで再利用するのに対し、OnPublishEndAsync戦略は各インデックスごとに個別にレコードを取得します。

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

OnPublishEndAsyncSingleInstance戦略をインデックスに付ける方法

この戦略をインデックスに次のように付けます:

... ...

ベストプラクティス

同じデータベースに複数のインデックスがあり、公開コンテンツも複数ある場合は、onPublishEndAsyncSingleInstance戦略の採用をお勧めします。

この戦略を以下の戦略と組み合わせてはいけません。

  • 同期
  • 間隔非同期
  • OnPublishEndAsync(公開終了時)を

以下の戦略と組み合わせることができます:

  • RebuildAfterFullPublish
  • リモートリビルド

間隔非同期戦略

この戦略は設定ファイル上で次のように定義されています:

master \`00:00\`:10 true
  • 処理のためのアイテム変更を調べるデータベースを database パラメータで指定します。
  • 戦略のトリガー頻度を interval パラメータで指定します。

この戦略をインデックスに付けて初期化すると、CrawlingLogファイル内に以下のメッセージが表示されます。

Initializing IntervalAsynchronousUpdateStrategy for index '<index_name>'.

この戦略が発動すると、CrawlingLogファイルに以下のメッセージが表示されます。

IntervalAsynchronousUpdateStrategy triggered on index '<index_name>'

加工

この戦略はOnPublishEndイベントではなく、時間間隔によってトリガーされます。ソースデータベースのEventQueueテーブルを使用します。 sourceデータベースは戦略のdatabaseパラメータによって指定されます。例えば:

web

この戦略を用いる前提条件は以下の通りです:

  • EnableEventQueues設定はtrueでなければなりません。
  • 参照されるデータベースは 設定セクションで定義されなければなりません
  • 参照されるデータベースは、クロール対象の検索インデックスで定義されている少なくとも1つのデータベースと一致しなければなりません

この戦略は、あらかじめ定義された区間値で初期化された内部タイマーを使用します。タイマーが発動したときに戦略が発動します。この例では、タイマーは10秒ごとに発動するように設定されています:

web \`00:00\`:10 true

閾値はContentSearch.FullRebuildItemCountThreshold設定によって設定され、すべてのインデックス更新戦略で共有されます。設定は非表示で、設定内には含まれませんが、手動で追加できます。設定のデフォルト値は100,000です。

閾値の最適値は以下に依存します:

  • 検索インデックス内のドキュメントの総数。例えば、検索インデックスに50,000件のドキュメントが含まれている場合、しきい値は25,000に設定できます。
  • 追加操作と削除操作の比率(更新は削除してから追加することに相当します)。削除操作が追加や更新操作より頻繁であれば、閾値を下げることができます。

操作が多岐にわたる場合、削除、追加、更新のすべての操作を個別に処理するよりも、インデックスを一から作成(追加操作を使って)する方が速いかどうかを検討してください。

しきい値のチェックは各戦略ごとに無効にできます: false。この設定をtrueに設定した場合、この戦略を使うインデックスに対してもSwitchOnRebuildSolrSearchIndex実装を使用することを推奨します。

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

間隔非同期戦略をインデックスに付ける方法

この戦略をインデックスに次のように付与します:

$(id) $(id)

ベストプラクティス

この戦略を以下の戦略と組み合わせてはいけません:

  • 同期戦略
  • OnPublishEndAsync(公開終了時)を
  • OnPublishEndAsyncSingleInstance

以下の戦略と組み合わせることができます:

  • RebuildAfterFullPublish
  • リモートリビルド

この戦略はマスターデータベースのインデックスや、できるだけリソースを使いたい単一サーバー環境に使うべきです。

この戦略は、頻繁に更新する必要のない重要度の低い指標にも有効です。ニーズに合わせて間隔を調整できます。

この戦略は、Sitecoreが提供する構成内のコアおよびマスターデータベース向けに作成されます:

core \`00:01\`:00 true master \`00:00\`:10 true

同期戦略

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

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

この戦略は次のように指定されています:

この戦略をインデックスに付けて初期化すると、CrawlingLogファイル内に以下のメッセージが表示されます。

Initializing SynchronousStrategy for index '<index_name>'.

この戦略が発動すると、CrawlingLogファイルに以下のメッセージが表示されます:

SynchronousStrategy triggered on index '<index_name>'

加工

この戦略は、ItemSavedやItemSavedRemoteなどの低レベルのDataEngineイベントに賛同します。シングルサーバーインスタンスで使用すると、アイテム更新の直後にインデックス更新が保証されます。

マルチサーバー環境では、この戦略はリモートItemSavedRemoteイベントをブロードキャストするEventQueueを使用します。アイテムが公開されItemSavedRemoteイベントが発生した際に、戦略が発動します。

同期戦略をインデックスに付ける

この戦略をインデックスに次のように付与します:

$(id) $(id)

ベストプラクティス

即時のインデックス更新が必要で、専用のインデックスサーバーインフラと十分な処理リソースがある場合はこの戦略を使います。同期戦略は、マスターデータベースを処理するインデックスやインデックス更新のタイミングが重要な場合に限り、CMサーバーで使うべきです。

多くのエントリを追加・変更するCMサーバーでこの戦略を使用すると、システム性能を著しく低下させる可能性があります。ほとんどの場合、マスターデータベース向けに設定されたInterval Asyncronous戦略で十分です。

BulkUpdateContextで起こる変更はこの戦略では処理されず、検索インデックスを同期させるためにインデックス全体の再構築が必要です。BulkUpdateContextを定期的にご利用の場合は、非同期戦略の使用を推奨します。

この戦略は以下の戦略と組み合わせるしかできません:

  • リモートリビルド

この戦略には以下の前提条件があります:

  • この戦略は、アイテム変更が起こる同じインスタンスでEventQueueを有効にする必要はありません。例えば、ソリューションがCMインスタンスが1つだけの場合、同期戦略を使って マスター データベースの変更処理が可能です。しかし、複数のCMインスタンスがある場合は、イベントキューを有効にして異なるインスタンス間でイベントを共有する必要があります。

リモートリビルド戦略

この戦略はOnIndexingEndedRemoteイベントに賛同します。このイベントは特定のインデックスが再構築されたときにトリガーされます。この戦略は、完全なインデックス再構築が行われた場合にのみ発動します。

この仕組みを使って、インデックスの再構築を強制する際にリモートインデックスを再構築します。この戦略は次のように指定しています:

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

この戦略をインデックスに次のように付与します:

$(id) $(id)

ベストプラクティス

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

この戦略には以下の前提条件があります:

  • リモートサーバーのインデックス名は、強制的に再構築させたインデックス名と同一でなければなりません。
  • イベントキューを有効にする必要があります。
  • システムイベントキューストレージに割り当てるデータベース(デフォルトでcore )は、再構築が行われるSitecoreインスタンスと他のインスタンス間で共有されなければなりません。

手動戦略

この戦略は自動インデックス更新を無効にします。この戦略をインデックスに使う場合は、手動でインデックスを再構築しなければなりません。

この戦略を次のように指定しています:

この戦略をインデックスに付けて初期化すると、CrawlingLogファイルに以下のメッセージが表示されます。

Initializing ManualStrategy for index '<index_name>'.

Index will have to be rebuilt manually

マニュアル戦略をインデックスに付ける

この戦略をインデックスに次のように付与します:

$(id) $(id)

ベストプラクティス

この戦略は他の戦略と組み合わせてはいけません。これは、インデックス作成全体を専用サーバーにアウトソースしなければならず、他のSitecoreインスタンスでインデックス更新を望まない場合に限定されます。

この記事を改善するための提案がある場合は、 お知らせください!