--- title: "xConnect Search Indexerの設定" slug: "configuring-the-xconnect-search-indexer" abstract: "Search Indexerの設定概要と、異なる検索コレクション提供者の設定。" --- # xConnect Search Indexerの設定 このトピックでは、xConnect Searchインデクサーに影響を与える設定について説明します。xConnect Searchインデクサーには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は、基盤となるプロバイダーの変更 [追跡保持期間設定](https://doc.sitecore.com/xp/ja/developers/91/sitecore-experience-platform/tracking-changes-to-the-xdb-index.html "Tracking changes to the xDB index")の影響を受けます。 単一マシンのオンプレミス展開では、インデクサーの設定は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(負の値)にするか、要素を完全に削除してください。 詳細については、以下をご覧ください: - [匿名連絡先のインデックス化を可能にする](https://doc.sitecore.com/xp/ja/developers/91/sitecore-experience-platform/enable-indexing-of-anonymous-contacts-in-the-xdb-index.html "Enable indexing of anonymous contacts in the xDB index") - [個人情報(PII)の機密データのインデックス化を可能にする](https://doc.sitecore.com/xp/ja/developers/91/sitecore-experience-platform/enable-indexing-of-pii-sensitive-data-in-the-xdb-index.html "Enable indexing of PII sensitive data in the xDB index") ## 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インデックス](https://docs.mongodb.com/manual/core/index-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エラーを返す](https://docs.microsoft.com/en-us/rest/api/searchservice/http-status-codes)場合は、この値を上げてみてください。値を上げることで、システムが関連するエラーを返す時間が取れるかもしれません。 [Azure Searchトラフィックを早期](https://azure.microsoft.com/en-us/blog/analyzing-your-azure-search-traffic/)かつ頻繁に分析することを推奨します。 RetryCount プロバイダーがインデクサーにエラーを報告するまでに何回リトライするかを制御します。プロバイダーがこの値を超えた場合、エラーをログします。ModifyをModify MaximumRetryDelayMillisecondsと共に。 MaximumWaitTimeoutMilliseconds インデックス変更を待つ最大時間を制御します。制限に達した場合、インデックスを再度試み、ログに次のエントリを追加します: *インデックス内の待機中のドキュメントはタイムアウトにより失敗*します。繰り返しタイムアウトの問題はAzure Searchが重負荷にさらされていることを示しています。この場合は、Azure Searchパーティションの使用や設定値の増加を検討してください。 DataReplicationTimeoutMilliseconds Azure Searchレプリカを使用している場合、この設定は変更を最初に検出した後の待機時間を制御します。この待ち時間が経過すると、インデクサはxConnect Searchサービスに変更が検索可能であることを信号します。この遅延により、データがレプリカ間で伝播する時間が確保されます。現在、すべてのレプリカでデータが利用可能かどうかを判断する方法はなく、この設定の調整は困難です。 レプリカを使っていない場合は、これを0に設定できます。 ## SC。Xdb.Collection.IndexWriter.SOLR.xml 以下の設定はSolr検索プロバイダー専用です。 ファイルパス:C:\\<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は、 MaximumRetryDelayMillisecondsと共に修正します。 Encoding Solr投稿のエンコーディングを制御します。テストされたのはutf-8のみです。