検索結果の鮮度を実現する方法: SharePoint を対象にした継続的クロールについて
原文の記事の投稿日: 2012 年 9 月 15 日 (土曜日)
対象読者: 検索管理者/IT 担当者
前提条件: このブログは、読者に SharePoint Search のトポロジ、クロールのメカニズム、およびクロールのスケジュール設定の原則に関する検索管理の基本知識があることを前提にしています。
注: これは SharePoint 2013 の新機能です。
検索結果の鮮度とは
SharePoint サイトにドキュメントをアップロードした後、そのドキュメントが SharePoint 検索ポータルから "検索可能" になるまでの期間は、鮮度に関する待ち時間を示します。
鮮度を左右する要因
複数の要因があります。リポジトリのサイズ、変更率、リポジトリの要求応答時間、クロール スケジュール、変更の種類などです。この理由は、ドキュメントを "検索可能" にするためには、クロールをトリガーし (手動またはスケジュールに従って自動的に)、変更を識別、要求、および処理する必要があります。
何が問題なのか
従来、SharePoint Search のスケジュールに関するオプションには、フル クロールと増分クロールの 2 つがありました。フル クロールを選ぶとホスト全体の検出が開始されます。一方、増分クロールでは、前回のクロール実施時以降にホストで変更された項目のみが処理されます。この処理は、各ドキュメントのタイム スタンプを比較するか、そのリポジトリの既存の変更ログを使って行われます。変更ログにはドキュメントの変更履歴が記録されます。より高度な鮮度を実現するために推奨されるアプローチは、増分クロールをより積極的 (たとえば毎日ではなく 30 分おき) に実行することでした。
フル クロールと増分クロールの制約の 1 つは、並行して実行できないことです。つまり、フル クロールまたは増分クロールの実行中は、そのコンテンツ ソースに対する新たなクロールは開始できません。そのため、項目をインデックス登録する方法として先入れ先出し方式以外の選択肢はありません。さらに、一部の種類の変更では、実行時間が長くなります (たとえば、ホストのルート レベルでのポリシー変更の場合、インデックスに登録されている項目ごとにセキュリティ記述子を更新するために、ホスト全体をインデックスに再登録する必要があります)。これら 2 つの要因が組み合わさった結果、頻繁な増分クロールのスケジュールを設定したとしても、鮮度が変動します。これを説明するために、以下に増分クロールの期待されるメンタル モデルを現実と比較して示し、続いてそのシステムの鮮度を示します。
解決策: 継続的クロールの紹介
SharePoint のような種類のコンテンツ ソース用のクロール オプションとしてお勧めするのは、スケジュール不要のコンテンツ ソース管理を可能にするオプションです。基盤となるアーキテクチャは、フル クロールと増分クロールの 2 つの基本的な制約を克服することによって、一貫した鮮度を保証する設計になっています。
- 並行して実行できる
- 1 個の深い変更によってそれ以降のすべての変更の鮮度が低下することがない
詳細
この背景で起きていることは、次のとおりです。つまり、継続的クロールを選択すると、15 分ごとにクロールが開始され、それは前回のセッションが完了しているかどうかには関係ありません。そのため、深い変更の直後に変更を行うときに、後ろで待機する必要がありません。新たな変更は、別の継続的クロール セッションによって深いポリシー変更が処理されるのと並行して継続的に処理されます。次の図は、継続的クロールが 15 分間隔で並行して発生する様子を示しています。これは、全体的な鮮度に影響を与えずに突発的なコンテンツの増加に対処するのに役立ちます。その後のグラフは、増分クロールではなく継続的クロールを使うことで実現される鮮度に対する影響を表します。
その他に知っておく必要があること
この後のブログでは、継続的クロールでさまざまなシナリオ (エラー、セキュリティなど) を処理する方法や、クロール ログおよびクロール履歴を使って背後で起きていることをより的確に把握する方法について、詳しくレビューしていきます。
FAQ:
継続的クロールは、あらゆる種類のコンテンツ ソースに使えますか?
いいえ。継続的クロールは、SharePoint のような種類のコンテンツ ソースのみに使えます。その他すべての種類のコンテンツ ソースについては、オプションとして増分クロールとフル クロールが引き続き使えます。
継続的クロールを使うと、リポジトリに追加の負荷が発生しますか?
継続的クロールのフットプリントは、増分クロールと同程度です。要求が行われる頻度は変わっても、1 つのリポジトリまたはホストに対する同時要求数は、引き続き "クロール影響ルール" によって制御されます。このルールは、要求を行うことができる同時スレッドの最大数を決定します。その最大数は、既定では 12 スレッドに設定されていますが、ビジネスの要件や能力計画に応じて変更できます。
継続的クロールを使う場合、増分クロールかフル クロールを設定する必要がありますか?
継続的クロールを使う場合、増分クロールを構成する必要はありません。
継続的クロールによってホストやリポジトリに追加の負荷が発生しますか?
継続的クロールでは複数のセッションが同時に並行して実行できるため、ホストの負荷の増加はわずかです。ただし、ホストに対して可能な同時要求の最大数を制御する "クロール影響ルール" の設定に従っている必要があります。最大数は OOB によって 12 に設定されていますが、変更できます。
継続的クロールを使って以前のバージョンの SharePoint コンテンツをクロールできますか?
はい。検索アプリケーションは 2013 であることが必要ですが、以前のバージョンの SharePoint を実行しているコンテンツ ファームは、継続的クロールの対象として構成できます。
これはローカライズされたブログ投稿です。原文の記事は、「How can I achieve the best freshness of search results? Introducing Continuous Crawls for SharePoint」をご覧ください。