トポロジ、クロールのメカニズム、およびクロールのスケジュール設定の原則に関する検索管理の基本知識があることを前提にしています。なるまでの期間は、鮮度に関する待ち時間を示します。複数の要因があります。スケジュール、変更の種類などです。(手動またはスケジュールに従って自動的に)、変更を識別、要求、および処理する必要があります。クロールを選ぶとホスト全体の検出が開始されます。増分クロールでは、前回のクロール実施時以降にホストで変更された項目のみが処理されます。スタンプを比較するか、そのリポジトリの既存の変更ログを使って行われます。変更ログにはドキュメントの変更履歴が記録されます。並行して実行できないことです。ソースに対する新たなクロールは開始できません。そのため、項目をインデックス登録する方法として先入れ先出し方式以外の選択肢はありません。レベルでのポリシー変更の場合、インデックスに登録されている項目ごとにセキュリティ記述子を更新するために、ホスト全体をインデックスに再登録する必要があります)。つの要因が組み合わさった結果、頻繁な増分クロールのスケジュールを設定したとしても、鮮度が変動します。モデルを現実と比較して示し、続いてそのシステムの鮮度を示します。ソース管理を可能にするオプションです。つの基本的な制約を克服することによって、一貫した鮮度を保証する設計になっています。個の深い変更によってそれ以降のすべての変更の鮮度が低下することがない詳細この背景で起きていることは、次のとおりです。分ごとにクロールが開始され、それは前回のセッションが完了しているかどうかには関係ありません。そのため、深い変更の直後に変更を行うときに、後ろで待機する必要がありません。セッションによって深いポリシー変更が処理されるのと並行して継続的に処理されます。分間隔で並行して発生する様子を示しています。これは、全体的な鮮度に影響を与えずに突発的なコンテンツの増加に対処するのに役立ちます。その後のグラフは、増分クロールではなく継続的クロールを使うことで実現される鮮度に対する影響を表します。ログおよびクロール履歴を使って背後で起きていることをより的確に把握する方法について、詳しくレビューしていきます。ソースに使えますか?いいえ。ソースのみに使えます。クロールが引き続き使えます。継続的クロールを使うと、リポジトリに追加の負荷が発生しますか?継続的クロールのフットプリントは、増分クロールと同程度です。このルールは、要求を行うことができる同時スレッドの最大数を決定します。スレッドに設定されていますが、ビジネスの要件や能力計画に応じて変更できます。クロールを設定する必要がありますか?継続的クロールを使う場合、増分クロールを構成する必要はありません。継続的クロールによってホストやリポジトリに追加の負荷が発生しますか?継続的クロールでは複数のセッションが同時に並行して実行できるため、ホストの負荷の増加はわずかです。設定に従っている必要があります。設定されていますが、変更できます。コンテンツをクロールできますか?はい。ファームは、継続的クロールの対象として構成できます。これはローカライズされたブログ投稿です。SharePoint」をご覧ください。FeedbackTrademarks。