xDBインデックスの変更追跡
このページの翻訳はAIによって自動的に行われました。可能な限り正確な翻訳を心掛けていますが、原文と異なる表現や解釈が含まれる場合があります。正確で公式な情報については、必ず英語の原文をご参照ください。
xDBは連絡先、インタラクション、ファセットの変更を追跡します。xConnect Search Indexerはこのデータを使って 、コレクションデータベース内のデータとインデックスを同期させます。
xDBコレクションSQLプロバイダーによる変更の追跡
xDBコレクションSQLプロバイダーを使用している場合、xConnectはSQL Serverの変更追跡機能を使用します。変更追跡の保持期間は、SQL Serverで変更がどれくらいの期間保存されるかを決定します。
以下のことをお勧めします:
- すべてのシャードで自動クリーンアップを有効にしてください。これはデフォルトで 当てはまり ます。
- インデクサーを注意深く監視してください。
- 変更追跡の保持期間はできるだけ短く保ちましょう。
!警告変更追跡値を設定する際は、IT部門がシステムのダウンタイム中にインデクサーを修正できるよう十分な時間を確保することをお勧めします。ダウンタイム中に修正できれば、インデックスの再構築を避けられるかもしれません。デフォルトでは、値は5日間に設定されています。
xConnect検索インデクサーの設定方法については、Configure the xConnect Search Indexerを参照してください。
ライブインデックス作成への影響
保持期間は、インデックス作成者がオフライン後にインデックスを再開できるかどうかに影響します。保持期間がダウンタイム期間より短い場合、インデックス作成者はダウンタイム中に収集されたデータをインデックス化できません。この場合、インデックスを一から再構築しなければなりません。
指数再構築への影響
インデックス再構築は論理的に2つのステップで行われます:
- インデックス再構築がトリガーされるまでのすべてのデータのインデックス化。
- インデックス再構築後に収集されたすべてのデータの定期的なインデックス化。この期間は SyncLatestChangesIntervalSecを使って設定できます。詳細は 「xConnect Searchインデクサーの設定」をご覧ください。
ステップ2が設定された保持期間より長くかかる場合、インデクサーは前回の同期以降に収集したデータをインデックス化できません。もしそうなったら、すべてのシャードの保持期間を延長し、再構築を一から始めます。
性能への影響
変更追跡が有効な各テーブルには、変更された各行に関するデータを保存する内部テーブルがあります。
異なる保持時間やテーブルサイズは、以下の方法でパフォーマンスに影響を与えます:
- 保持期間が短いことで高性能になり、容量を節約できます。しかし、システムが故障した場合は インデクサーを再構築しなければなりません。
- 保持期間が長くなるほど、内部テーブルが大きくなります。これによりデータベース全体のサイズが増加し、忙しいシステムではパフォーマンスの問題を引き起こすことがあります。
- 内部テーブルが大きいほど自動クリーンアップの処理は遅くなります。ただし、自動クリーンアッププロセスを無効にしないことをお勧めします。自動クリーンアッププロセスを無効にすると、時間とともにシステムにさらに大きなテーブルが増えます。
xDBコレクションのMongoDBプロバイダーによる変更の追跡
xDBコレクションMongoDBプロバイダーを使用している場合、xConnectはTTLインデックスを持つChangesというカスタムコレクションを使用します。保持期間はプログラムで制御され、SQLの変更追跡と同じデフォルト(5日間)を使用します。
詳細については、「xConnect Search Indexerの設定」をご覧ください。