1. xDB検索インデックス

xConnect Search Indexerの設定

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

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

このトピックでは、xConnect Search Indexerに影響を与える設定について説明します。xConnect Search Indexerには6つのXML設定ファイルがあります。汎用構成からプロバイダー固有の構成へと、これらはsc.Xconnect.SearchIndex.xml、sc.Xdb.Collection.IndexerSettings.xml、sc.Xdb.Collection.Data.Sql.xml、sc.Xdb.Collection.Data.MongoDb.xml、sc.Xdb.Collection.IndexWriter.AzureSearch.xml、sc.Xdb.Collection.IndexWriter.SOLR.xmlです。

xConnect Search Indexerは、基盤となるプロバイダーの変更 追跡保持期間設定の影響を受けます。

単一マシンのオンプレミス展開では、インデクサーの設定はC:\>Path to xConnect>\App_data\jobs\continuous\IndexWorker\App_data\Configの下に位置します。

!重要xConnect Searchインデクサーは \App_data\Configサブフォルダ内のすべての設定を使用しません。例えば、インデクサーはsc.Xdb.Collection.RepositorySettings.xmlの設定を使用しません。

SC。XConnect.SearchIndexer.xml

以下の設定は、インデクサーが変更を確認する頻度を制御します。

ファイルパス: C:\\App_data\jobs\continuous\IndexWorker\App_data\Config\Sitecore\SearchIndexer\sc.XConnect.SearchIndexer.xml

舞台設定

概要

Frequency

インデクサーが変更を確認する頻度を制御します。

インデクサーが0.20秒間話し中なら、0.05秒待ってから再度試みます。

インデクサが0.25秒以上忙しい場合は、前のセットをインデックスした直後に変更をチェックします。

DelayAfterError

エラーが発生した後にインデクサーが再試行までどれくらい待つかを制御します。

DelayAfterRecurringError

インデクサーが RecurringErrorThresholdに到達した後に再試行するまでの待ち時間を制御します。

エラーが発生した場合は、ログエントリ数を減らすためにこの値を増やします。

RecurringErrorThreshold

DelayAfterRecurringError設定が発動するまでにエラーが何回発生するかを制御します。

SC。Xdb.Collection.IndexerSettings.xml

以下の設定はインデックス再構築中のメモリ使用を制御します。

ファイルパス: C:\\App_data\jobs\continuous\IndexWorker\App_data\Config\Sitecore\SearchIndexer\sc.Xdb.Collection.IndexerSettings.xml

舞台設定

概要

IncomingDataLagOnCompletion

インデックス再構築の最後にインデクサは、入力データを追いつかなければなりません。インデクサが IncomingDataLagOnCompletionで指定された値より小さい差で遅れている場合、コアは入れ替わります。

ParallelizationDegree

インデックス再構築時に処理される並列データストリームの数を制御します。 BatchSize と組み合わせてインデックス再構築中のメモリ使用量を調整します。

インデクサがメモリを過剰に消費している場合は、この値を減らします。

インデクサがあまりメモリを消費していなければ、この値を増やしてみることもできます。

BatchSize

インデックス再構築時に並列ストリームごとに1つの接点やインタラクションを1つにロードする数を制御します。インデックス再構築中のメモリ使用量を調整するには、 ParallelizationDegreeと組み合わせて使用してください。

インデックスの再構築がメモリを過剰に消費している場合は、この値を減らします。

インデクサがあまりメモリを消費していなければ、この値を増やしてみることもできます。

SplitRecordsThreshold

インデクサが同時にメモリに読み込むレコード数(コアあたり)の上限を制御します。

インデクサがメモリを使いすぎている場合は、この値を減らします。

分割を無効にするには、値を0(負の値)にするか、要素を完全に削除してください。

SyncLatestChangesIntervalSec

インデクサーとデータベース間の同期頻度を制御します。秒単位で測定されます。デフォルト値は3600秒です。同期間のデータ損失を避けるため、この値は常に 変更追跡保持期間より高く設定することを推奨します。

詳細については、以下をご覧ください:

SC。Xdb.Collection.Data.Sql.xml

SQL xDBコレクションプロバイダーを使用している場合、以下の設定が適用されます。

ファイルパス: C:\\App_data\jobs\continuous\IndexWorker\App_data\Config\Sitecore\Collection\sc.Xdb.Collection.Data.Sql.xml

舞台設定

概要

NumberOfChangeVersions

変更テーブルが返すトランザクション数(レコードではなく)を制御します。例えば、500トランザクションには500件以上の変更が含まれることがあります。

インデクサが遅れて保留中の変更数を低く保つのを防ぐため、デフォルト値は高(50000)に設定されています。しかし、高い値はインデクサのメモリ要件を増加させます。

インデクサがメモリを過剰に消費している場合は、 SplitRecordsThresholdの値を減らしてみてください。 NumberOfChangeVersions 設定を減らしても効果があまりありません。なぜなら、変更テーブルから読み込まれるデータ(ID、ファセットキー、変更の種類)はごくわずかだからです。

GetChangesCommandTimeoutInSeconds

get changesコマンドのタイムアウトを制御します。インデックス作成中にタイムアウトが発生した場合は、この値を増やしてください。

CommandTimeoutInSeconds

GETやSAVEなどの収集提供者コマンドのタイムアウトを制御します。

AbsoluteExpiration

SQLプロバイダーはシャードクラスタ構成に関するメタデータをキャッシュします。この設定はキャッシュの有効期限を制御します。

SC。Xdb.Collection.Data.MongoDb.xml

MongoDB xDBコレクションプロバイダーを使用している場合、以下の設定が適用されます。

ファイルパス: C:\\App_data\jobs\continuous\IndexWorker\App_data\Config\Sitecore\Collection\sc.Xdb.Collection.Data.MongoDb.xml

舞台設定

デフォルト

概要

ContactIdentifierIndexLockTimeInSeconds

60

識別子の最大ロック時間。指定された時間内に割り当てられたロックを解除してください。

NumberOfRecordChangesToReadInRequest

100

変更追跡は、バッチエンティティの変更を変更追跡コレクション内のドキュメントにまとめます。プロバイダーは変更追跡コレクションのために指定された数のドキュメントを1バッチで読み取ります。この設定はデータの読み取りや変更のパフォーマンスに影響を与えます。エンティティの変更の小規模なバッチが多数ある場合、値を増加させることができます。

NumberOfChangesPerBatch

100000

プロバイダーが要請時に返す最大の変更回数

WaitTimeForBatchToCompleteInSeconds

100

単一バッチの変更を保存するのにかかる最大時間(秒数)。

MaximumNumberOfRetriesForReadOperations

6

故障時のデータ読み取り操作を再試行する最大数。

DelayBetweenRetriesForReadOperationsInMilliseconds

5000

2回のデータベース読み取り試行間の遅延時間(ミリ秒)。

MaximumNumberOfRetriesForInitializationOperations

6

失敗時のプロバイダー初期化操作を再試行する最大数。

DelayBetweenRetriesForInitializationOperations(ミリ秒単位)

5000

2回のプロバイダー初期化操作試行間の遅延時間(ミリ秒)。

ExpireAfterSeconds

432000

変更コレクションのTTLインデックスのexpireAfterSecondsオプションです。指定された時間が経ったら変更追跡データを削除してください。

SC。Xdb.Collection.IndexWriter.AzureSearch.xml

以下の設定は、その提供者ごとにごAzure Searchです。

ファイルパス: C:\<Path to xConnect>\App_data\jobs\continuous\IndexWorker\App_data\Config\Sitecore\SearchIndexer\sc.Xdb.Collection.IndexWriter.AzureSearch.xml

舞台設定

概要

MaximumUpdateBatchSize

1つの投稿で送信される接触ややり取りの数を制御します。1000件を超えてはいけません。大きな接触ややり取りで投稿が拒否された場合は、この値を減らします。

ParallelizationDegree

複数のAzure Searchパーティションを使用する場合は、この値を増やすことを推奨します。この値を上げるとメモリ消費量が増加します。

この値を変更する際は、忙しいインデクサのメモリ使用状況を監視することをお勧めします。メモリ使用状況を監視するには、パフォーマンスカウンター IndexWriteAvgTime と IndexWriteAvgBatchSizeを使用します。

> [!注]
> この設定を設定から削除すると、プロバイダーはホストマシン上の利用可能なコア数にフォールバックします。

MaximumRetryDelayMilliseconds

負荷で一時的に故障した際にプロバイダーが待つ最大時間を制御Azure Search

Azure Searchが一貫して 503エラーを返す場合は、この値を上げてみてください。値を上げることで、システムが関連するエラーを返す時間が取れるかもしれません。

Azure Searchトラフィックを早期かつ頻繁に分析することを推奨します。

RetryCount

プロバイダーがインデクサーにエラーを報告するまでに何回リトライするかを制御します。プロバイダーがこの値を超えた場合、エラーをログします。ModifyをModify MaximumRetryDelayMillisecondsと共に。

MaximumWaitTimeoutMilliseconds

インデックス変更を待つ最大時間を制御します。制限に達した場合、インデックスを再度試み、ログに次のエントリを追加します: インデックス内の待機中のドキュメントはタイムアウトにより失敗します。繰り返しタイムアウトの問題はAzure Searchが重負荷にさらされていることを示しています。この場合は、Azure Searchパーティションの使用や設定値の増加を検討してください。

DataReplicationTimeoutMilliseconds

Azure Searchレプリカを使用している場合、この設定は変更を最初に検出した後の待機時間を制御します。この待ち時間が経過すると、インデクサはxConnect Searchサービスに変更が検索可能であることを信号します。この遅延により、データがレプリカ間で伝播する時間が確保されます。現在、すべてのレプリカでデータが利用可能かどうかを判断する方法はなく、この設定の調整は困難です。

レプリカを使っていない場合は、これを0に設定できます。

SC。Xdb.Collection.IndexWriter.SOLR.xml

以下の設定はSolr検索プロバイダー専用です。

ファイルパス: C:\<Path to xConnect>\App_data\jobs\continuous\IndexWorker\App_data\Config\Sitecore\SearchIndexer\sc.Xdb.Collection.IndexWriter.SOLR.xml

舞台設定

概要

MaximumUpdateBatchSize

1つの投稿における連絡先ややり取りの数を制御します。

MaximumDeleteBatchSize

1つの投稿における連絡ややり取りの削除回数を制御します。削除は通常IDに影響しますが、Solrの OR 条項の制限は子文書の削除にも影響を与える可能性があります。

MaximumCommitMilliseconds

Solrでソフトコミットされるデータの速度を制御 commitWithin。

ParallelizationDegree

複数のSolrレプリカを使用している場合は、この値を増やすことを検討してください。この値を上げるとメモリ消費量が増加します。

この値を変更する際は、ビジーインデクサーのメモリ使用状況を監視することをお勧めします。インデクサーを監視するには、パフォーマンスカウンタ IndexWriteAvgTime と IndexWriteAvgBatchSizeを使用します。

> [!注]
> この設定を設定から削除すると、プロバイダーはホストマシン上の利用可能なコア数にフォールバックします。

MaximumRetryDelayMilliseconds

Solrが負荷で一時的に故障した際にプロバイダーが待つ最大時間を制御します。

もしSolrが一貫して503エラーを返すなら、この値を上げることを検討してください。値を上げることで、システムが関連するエラーを返す時間が取れるかもしれません。

RetryCount

プロバイダーがインデクサーにエラーを報告するまでに何回リトライするかを制御します。プロバイダーがこのリトライ回数に達すると、インデクサーはエラーをログします。ModifyはModified MaximumRetryDelayMillisecondsと共に。

Encoding

Solr投稿のエンコーディングを制御します。テストされたのはutf-8のみです。

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