JP2006107446A - ネットワーク・ドキュメントのバッチ索引付けのためのシステムおよび方法 - Google Patents

Abstract

【課題】 データベースに格納されている変更ログを含むネットワーク・サイトをホスティングするサーバの構造を利用して、検索クエリのためにドキュメントをバッチ索引付けするプロセスを提供すること。
【解決手段】 サイトのコンテンツはバッチ処理され、サーバからインデクサに一括して転送される。変更ログは、サイトのコンテンツへの変更を追跡する。インデクサは、変更ログを使用して索引への更新を増分的（incrementally）に要求し、変更をバッチ処理して、帯域幅使用率（bandwidth usage）およびプロセッサ・オーバーヘッド・コストが軽減されるようにする。
【選択図】 図３

Description

本発明は、ネットワークをクロールしてドキュメントを取り出すことに関し、より詳細には、ネットワーク・ドキュメントのバッチ索引付け（batch indexing）のためのシステムおよび方法に関する。

ネットワークおよびファイル・システムでコンテンツを検索する方法は、多くの形態で提供されてきたが、検索エンジンの変形による方法が最も一般的である。検索エンジンは、指定されたキーワードを求めてネットワーク上のドキュメントを検索し、キーワードが見つかったドキュメントのリストを返すプログラムである。多くの場合、ネットワーク上のドキュメントは、ネットワークを「クロールすること（crawling）」によって最初に識別される。

ネットワークをクロールすることは、ネットワーク・クローリング・プログラム、つまりクローラ（crawler）を使用して、ネットワーク上にあるドキュメントを識別することを示している。クローラは、ネットワーク・クロールの実行中に、１つまたは複数のネットワーク・ロケーションからドキュメントを自動的に見つけ出して収集するコンピュータ・プログラムである。クロールは、クロールのシードとして機能するドキュメント・アドレスのセットおよびクロールの範囲を定義するクロール制限規則のセット、をクローラに提供することによって開始する。クローラは、クロール中に取り出したドキュメントに参照されているリンク先ドキュメントのネットワーク・アドレスを再帰的に収集する。クローラは、Ｗｅｂサイトからドキュメントを取り出し、ドキュメントから受け取ったドキュメント・データを処理して、そのデータが引き続き他のプログラムによって処理されるように準備を整える。たとえば、クローラは、取り出されたデータを使用して、インターネットまたはイントラネット上で使用可能なドキュメントの索引を作成することもできる。「検索エンジン」はその後、索引を使用して、指定された基準を満たすドキュメントを探し出すことができる。

クロールにおいてドキュメントを取り出す際に、ネットワーク上の各ドキュメントに操作が実行され、ドキュメントを取得して、そのドキュメントのレコードを索引に取り込むことが行われる。ドキュメントに対するこれらの往復クエリは、帯域幅およびプロセッサ使用率に関して大量のオーバーヘッドを消費する可能性がある。さらに、検索エンジンによって正確な結果が提供されるために、索引はまたネットワーク上のドキュメントに関して正確である必要もある。ドキュメントの修正、ドキュメントの追加、ドキュメントの削除、または他の操作によって、ネットワーク上のドキュメントに変更があった場合、索引はこれらの変更を反映するように更新される必要がある。ただし、ネットワークのクロールは、高価な操作になる可能性がある。ネットワークをあちこち往復しなければならないために、インデクサおよびネットワーク間で使用可能な帯域幅を過度に使用してしまうおそれもある。

本発明の実施形態は、ドキュメントを求めてネットワークをクロールする場合に使用される帯域幅を軽減するＷｅｂサイトのバッチ索引付けのためのシステムおよび方法に関する。本発明は、ネットワーク・サイトをホスティングするサーバの構造を利用し、これは、データベースまたは他のリポジトリに格納されている変更ログを含む。本発明は、サイトのコンテンツをバッチ処理し、サーバからインデクサにそのコンテンツを一括して転送する。

本発明の１つの態様によれば、バッチ・サイズ制限は、ドキュメントのバッチをインデクサに送信するために設定される。各々のドキュメントに対応するメタデータは検査され、ドキュメントは選択され、バッチ内に含められる。ドキュメントのバッチは次に、インデクサに転送される。

本発明の１つの態様によれば、ネットワーク内のすべての変更は変更ログに記録される。変更ログは、追加、削除、修正、移動、名前変更、および他のドキュメント変更処理を記録する。変更ログは、どのドキュメントに変更が加えられたかを示している。一般に、ネットワーク上のほとんどのドキュメントは２つのクロール間では変更されない、しかし、変更ログがなければ、クローラはが各ドキュメントを往復して最終更新時間を取得することが必要になる。次に変更は、指定された数の変更をバッチ処理するサービス呼び出しを使用して、変更ログからインデクサによって取り出される。サービス呼び出しは、操作を繰り返して変更済みの各ドキュメントを取り出すことを防ぎ、代わりに多数の変更が一度にインデクサに転送されるようにする。したがって、ネットワークに送信する必要のあるデータベースクエリの数は軽減され、索引を更新するオーバーヘッドが効果的に減少することになる。

これ以降、本発明について、本明細書の一部を形成し、例示により本発明を実施するための特定の例示的な実施形態を示す添付の図を参照してさらに詳細に説明される。ただし、本発明は、多くのさまざまな形態で実施することができ、本明細書に示されている実施形態に限定されるものとして解釈すべきではない。むしろ、これらの実施形態は、本開示が十分かつ完全なものになるよう、また本発明の範囲を当業者に十分に伝えられるように提供されている。特に、本発明は、方法または装置として実施することができる。したがって、本発明は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態、またはソフトウェアおよびハードウェアの態様を組み合わせた実施形態をとることができる。したがって、以下の詳細な説明は、限定的な意味で解釈すべきではない。

例示的なオペレーティング環境
図１を参照すると、本発明を実装するための１つの例示的なシステムは、コンピュータ装置１００のようなコンピュータ装置を含んでいる。コンピュータ装置１００は、クライアント、サーバ、モバイル装置、または任意の他のコンピュータ装置として構成することができる。極めて基本的な構成において、コンピュータ装置１００は通常、少なくとも１つの処理装置１０２およびシステム・メモリ１０４を含んでいる。コンピュータ装置の正確な構成および種類に応じて、システム・メモリ１０４は揮発性（ＲＡＭなど）、不揮発性（ＲＯＭ、フラッシュ・メモリなど）、またはこの２つの組み合わせであってもよい。システム・メモリ１０４は通常、オペレーティング・システム１０５、１つまたは複数のアプリケーション１０６を含み、プログラム・データ１０７を含むこともできる。１つの実施形態において、アプリケーション１０６は、本発明の機能を実装するためのバッチ索引付けアプリケーション１２０を含んでいる。この基本構成は、図１において、破線１０８内のコンポーネントにより表されている。

コンピュータ装置１００は、追加の特徴または機能性を備えることもできる。たとえば、コンピュータ装置１００は、たとえば磁気ディスク、光ディスク、またはテープなどの追加のデータ記憶装置（取り外し可能および／または固定）を含むこともできる。そのような追加のストレージは、取り外し可能ストレージ１０９および固定ストレージ１１０によって図１に示されている。コンピュータ・ストレージ媒体は、コンピュータ可読命令、データ構造、プログラム・モジュール、または他のデータなどの情報のストレージのための任意の方法または技術において実装された揮発性および不揮発性の、取り外し可能および固定の媒体を含むことができる。システム・メモリ１０４、取り外し可能ストレージ１０９および固定ストレージ１１０はすべて、コンピュータ・ストレージ媒体の例である。コンピュータ・ストレージ媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュ・メモリその他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光ストレージ、磁気カセット、磁気テープ、磁気ディスク・ストレージまたはその他の磁気ストレージ装置、あるいは望ましい情報を格納するために使用することができ、コンピュータ装置１００によってアクセスすることができる他の媒体を含んでいるが、これらに限定されることはない。そのようなコンピュータ・ストレージ媒体は、装置１００の一部にすることができる。コンピュータ装置１００はさらに、キーボード、マウス、ペン、音声入力装置、タッチ入力装置などの入力装置１１２を備えることもできる。ディスプレイ、スピーカ、プリンタなどの出力装置１１４も含めることができる。

コンピュータ装置１００は、装置がネットワークなどを介して他のコンピュータ装置１１８と通信できるようにする通信接続１１６も含んでいる。通信接続１１６は、通信媒体の一例である。通信媒体は通常、搬送波またはその他の搬送機構などの、変調されたデータ信号の形態で、コンピュータ可読命令、データ構造、プログラム・モジュール、または他のデータによって具現化、任意の情報伝達媒体を含んでいる。「変調データ信号」という用語は、１つまたは複数の特性セットを備える信号、または信号の情報をコード化するような方法で変更された信号を意味する。たとえば、通信媒体は、有線ネットワークまたは直接配線接続のような有線媒体、および音響、ＲＦ、赤外線など無線媒体およびその他の無線媒体を含んでいるが、これらに限定されることはない。本明細書で使用されているコンピュータ可読媒体という用語は、ストレージ媒体および通信媒体を共に含んでいる。

バッチ索引付けの例示的な実施形態
以下の説明および特許請求の範囲全体を通じて、「ドキュメント」という用語は、ネットワーク・ドキュメント、ファイル、フォルダ、Ｗｅｂページ、およびその他のリソースなど、ネットワークの検索クエリまたはクロールの結果として返されるあらゆる可能なリソースを示している。

図２は、本発明が操作するネットワーク化システムの例示的なアーキテクチャを示している。サーバ２０４は、その上で実行するクローラ２０６を含んでいる。クローラ２０６は、図２に示されているリモート・サーバ２１８のような、ネットワーク２１６に接続された１つまたは複数のコンピュータ装置上に配布されているドキュメントを検索する。ネットワーク２１６は、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、またはサーバ２０４がリモート・サーバ２１８のようなリモート・コンピュータ装置と直接または間接的に通信できるようにするネットワークの組み合わせであってもよい。

クローラ２０６は、ネットワーク２１６に接続されたリモート・サーバ２１８でドキュメント２２２および２２４を検索する（「クロールする」）。クローラ２０６は、ドキュメント・データとしてドキュメントを取り出す。ドキュメント２２２および２２４からのドキュメント・データは、さまざまな方法で使用することができる。たとえば、クローラ２０６は、ドキュメント・データをインデクサ２０８に渡すことができる。インデクサ２０８は、ドキュメントの索引２１０を保持するコンピュータ・プログラムである。索引２１０に格納される情報のタイプは、インデクサ２０８の複雑さによって決まる。

本発明によれば、インデクサ２０８およびリモート・サーバ２１８は、Ｗｅｂサービス２５０に従って動作するように構成することができる。たとえば、リモート・サーバ２１８は、ワシントン州レドモンドのＭｉｃｒｏｓｏｆｔ Ｃｏｒｐｏｒａｔｉｏｎによって製造されたＷｉｎｄｏｗｓ（登録商標）ＳｈａｒｅＰｏｉｎｔ Ｓｅｒｖｉｃｅｓテクノロジに従って、Ｗｅｂサービス２５０を含むように構成することもできる。したがって、Ｗｅｂサービス呼び出しは、リモート・サーバ２１８上に位置するドキュメントについてＷｅｂサービス２５０にクエリを実行するために使用することができる。次にＷｅｂサービス２５０は、リモート・サーバ２１８上のドキュメントに関連付けられているデータベースによって公開されるアプリケーション・プログラミング・インターフェース（ＡＰＩ）と通信する。アプリケーション・プログラミング・インターフェースは、データベース内に存在するドキュメントを列挙し、ドキュメントに対応するドキュメント・データが返されてインデクサ２０８によって索引付けされるようにする。したがって、単一のＷｅｂサービス呼び出しに基づいてドキュメント・データの複数のセットが返されるために、リモート・サーバ２１８との間で往復するやりとりは大幅に軽減される。結果としての戻りは、効果的にまとめて「バッチ処理」される。他の実施形態では、ネットワーク・ドキュメントのバッチ索引付けを提供する際に、リモート・サーバ２１８上で他の常駐コードを使用したり、またはＷｅｂサービス呼び出し以外の通信プロトコルを使用したりすることもできる。インデクサおよびＷｅｂサービスとの間の通信については、以下の図３の説明で詳細に述べる。

パーソナル・コンピュータなどのクライアント・コンピュータ２１４は、ネットワーク２１２によってサーバに接続されている。ネットワーク２１２は、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、またはネットワークの組み合わせであってもよい。ネットワーク２１２は、ネットワーク２１６と同じか、または異なるネットワークであってもよい。クライアント・コンピュータ２１４は、ドキュメントを見つけてユーザに表示する「ブラウザ」２１５のような、コンピュータ・プログラムを含んでいる。

クライアント・コンピュータ２１４においてユーザが１つまたは複数のドキュメントを検索したい場合、クライアント・コンピュータ２１４は検索要求を検索エンジン２３０に送信する。検索エンジン２３０は、その関連付けられた索引２１０を調べて、検索要求に関連する可能性のあるドキュメントを見つける。検索エンジン２３０は、次に、それらのドキュメントのリストをクライアント・コンピュータ２１４のブラウザ２１５に返す。ユーザは、ドキュメントのリストを調べ、リモート・サーバ２１８などのリモート・コンピュータ装置から１つまたは複数のドキュメントを取り出すことができる。

さらにもう１つの実施形態において、サーバ２０４自身は、クローラ２０６によってアクセスされるドキュメント２３２および２３４を含むことができる。さらにクローラ２０６、インデクサ２０８、および検索エンジン２３０は、異なるコンピュータ上に常駐することができる。加えて、ブラウザ２１５およびクローラ２０６は、単一のコンピュータ上に常駐することができる。

図３は、本発明によるネットワーク・ドキュメントのバッチ索引付けのためのインデクサおよびサーバ間の例示的な通信システムの機能ブロック図を示している。システム３００は、インデクサ３０２およびサーバ３１０を含んでいる。サーバ３１０は、フロント・エンド３１２およびデータベース３１４を含んでいる。フロント・エンド３１２は、Ｗｅｂサービス３２０およびオブジェクト・モデル３２２を含んでいる。

インデクサ３０２は、ネットワーク上に位置するドキュメントの索引を保持する。インデクサはサーバ３１０と通信するために示されているが、他の中間機能ブロックがインデクサ３０２およびサーバ３１０間の通信を容易にすることもできる。たとえば、図２では、ネットワーク２１６にわたってインデクサ２０８およびリモート・サーバ２１８間の通信を提供するクローラ２０６を示している。少なくとも１つの実施形態において、中間機能ブロックは、本発明の機能に影響を与えていないため図示されていない。

インデクサ３０２は、Ｗｅｂサービス３２０と通信して、索引を取り込むためのドキュメント・データを取得する。次にＷｅｂサービス３２０は、オブジェクト・モデル３２２と通信して、データベース３１４にドキュメント・データを要求する。１つの実施形態において、データベース３１４は、示されている階層３３０に従って編成される。階層３３０は、サブ・サイトを含むサイトとして構造化される。各サブ・サイトは、他のコンテナまたはドキュメントをさらに含むことができる１つまたは複数のコンテナを含んでいる。１つの実施形態において、階層３３０は、コンピュータ装置のファイル・システムと同様に構造化される。

初期クロールに対して、インデクサ３０２はサーバ３１０に関連付けられているサイトを認識し、インデクサ３０２は、Ｗｅｂサービス３２０に、サイトに関する情報を要求するＷｅｂサービス呼び出しを提供する。この要求は、Ｗｅｂサービス３２０によってオブジェクト・モデル３２２に転送される。オブジェクト・モデル３２２は、データベース３１４に含まれているドキュメント、コンテナ、およびサイトのサブ・サイトの各々に対するオブジェクトを提供する。他の実施形態において、データベース３１４内の他の構造はさらに、オブジェクト・モデル３２２によって提供されたオブジェクトを有することもできる（たとえば、リスト、リスト項目、ドキュメント・ライブラリなど）。オブジェクト・モデル３２２は、サブサイト・オブジェクトのリストをＷｅｂサービス３２０に返すが、これがそのリストをＵＲＬ（Uniform Resource Locator）のリストとしてインデクサ３０２に伝搬する。１つの実施形態において、サブ・サイトのリストは、そのサブ・サイトの数が指定された数に満たない場合は、本発明のバッチ処理機能により、インデクサに提供されない。

サブ・サイトのリストを使用して、インデクサ３０２は、サイトに関する情報を要求する前述のＷｅｂサービス呼び出しと同様に、各サブ・サイトに関する情報を要求するＷｅｂサービス呼び出しを提供する。この場合も同様に、要求は、Ｗｅｂサービス３２０によってオブジェクト・モデル３２２に転送される。オブジェクト・モデル３２２は次に、要求が行われたサブ・サイト内のコンテナのリストをインデクサ３０２に返す。１つの実施形態において、サブ・サイトのリストは、そのサブ・サイトの数が指定された数に満たない場合は、本発明のバッチ処理機能により、インデクサに提供されない。データベース階層内のコンテナ、ドキュメント、または他のオブジェクト関連構造のバッチ処理は、オブジェクト関連構造に関するメタデータを調べること、インデクサ３０２に送信するために構造を一括して収集すること、を含む。サイトのバッチ索引付けのための例示的なプロセスについては、以下で図４を参照して説明される。

図４は、本発明による初期クロール中のバッチ索引付けについての例示的なプロセスの論理的流れ図を示している。プロセス４００は、ブロック４０２で開始する。ここでは、索引付けのためにドキュメント・データを要求するＷｅｂサービス呼び出しは、インデクサによって、ネットワーク・サイトをホスティングするサーバに送信されている。処理は、ブロック４０４に続く。

ブロック４０４において、Ｗｅｂサービスは、最大Ｎ個のドキュメントのドキュメント・メタデータを取得する。ここでＮは、指定されている制限（たとえば１０００項目）に従って設定される。ドキュメント・メタデータは、Ｗｅｂサービスによってデータベースから取り出される。他の実施例において、項目の制限は、別の制限に設定することもでき、また関連する制限を備えなくてもよい。メタデータは、インデクサに送信するためにドキュメントの効率的なバッチ処理を支援するドキュメント拡張子、ドキュメントサイズ、および他のメタデータ、を含んでいる。もう１つの実施形態において、コンテナはＮ項目よりも大きくすることができる。コンテナがＮ個以上の項目を含んでいる場合、Ｗｅｂサービスはさらに、Ｗｅｂサービスがデータベースから次のＮ個のドキュメントを取得することを知っているので、次のＷｅｂサービス呼び出しで渡されるｃｏｏｋｉｅを返す。Ｗｅｂサービスがドキュメント・メタデータを取得してしまうと、処理はブロック４０６に続く。

ブロック４０６において、クローラは、Ｗｅｂサービスによって取り出されたメタデータを処理し、メタデータに関連するドキュメントをバッチ・サイズ制限に従ってバッチにグループ化する。１つの実施形態において、バッチ・サイズ制限は、バイトによって（たとえば５０ＭＢ）バッチのサイズに関連付けられている。もう１つの実施形態において、バッチ・サイズ制限は、バッチに含まれているドキュメントの数に関連付けられている。さらにもう１つの実施形態において、インデクサは最大サイズ制限を設定し、次にＷｅｂサービスがドキュメントをバッチ処理するために最大値よりも少ない効率的なサイズを決定する。１つの効率的なサイズの決定は、データベースへのクエリの数が最小化されて、しかもインデクサおよびサーバ間の帯域幅使用率を最小化する場合のバッチ・サイズに対応する。

１つの実施形態において、特定のタイプであるドキュメントは、その拡張子（たとえばｍｐｇなど）に従ってバッチから除外することができる。たとえば、意味のある結果を検索クエリに提供するためには先ずレンダリングされなければならない特定のドキュメントは、バッチ索引付けの恩恵を受けることはなく、そのためドキュメントがレンダリングされた後に他の手段を通じて取得される。ムービーなどの他のドキュメントもまた、検索エンジンを使用してキーワード検索に意味のある結果を提供しない場合があり、そのためバッチからも除外される。もう１つの実施形態において、ドキュメントのサイズは、バッチ索引付けからこれを除外することができる。たとえば、ドキュメントのサイズがバッチ・サイズ制限を超える（たとえば５０Ｋよりも大きい）場合、そのドキュメントは他の手段（たとえば別の「ｇｅｔ ｄｏｃｕｍｅｎｔ」操作）によって取り出される。ドキュメントがバッチ処理されると、処理はブロック４０８に進む。

ブロック４０８において、ドキュメントのバッチは、クローラによってＷｅｂサービスに要求される。Ｗｅｂサービスは、データベースからドキュメントのバッチを取得し、ドキュメントをクローラに返す。クローラがドキュメントのバッチを受け取ると、処理は決定ブロック４１０に移動する。

決定ブロック４１０において、取り出されたドキュメント・メタデータに対応して、さらに多くのバッチがクローラによって取り出される必要があるかどうかの決定が行われる。さらに多くのバッチが取り出される必要がある場合、処理はブロック４０８に戻る。ただし、バッチがさらに取り出される必要がない場合、処理はブロック４１２に続く。

ブロック４１２において、取り出されたバッチに対応するドキュメントは、ドキュメントが索引になるようにクローラからインデクサに転送される。そのため、索引はドキュメントの変更に従って更新される。ドキュメントが転送されると、処理は決定ブロック４１４に続く。

決定ブロック４１４において、Ｎ個のドキュメントのメタデータを要求したＷｅｂサービス呼び出しに、ｃｏｏｋｉｅが関連付けられているかどうかの決定が行われる。ｃｏｏｋｉｅ、コンテナ内のドキュメントの数がＮよりも大きい場合に、特定のコンテナのドキュメントが、索引付けする同じコンテナの他のドキュメントに関連付けられていることを、確実にする。ドキュメントに関連付けられているｃｏｏｋｉｅがある場合、処理はブロック４０４に戻り、そこでｃｏｏｋｉｅに関連付けられているＮ個のドキュメントの次のセットについてプロセス４００が繰り返される。ただし、ドキュメントに関連付けられているｃｏｏｋｉｅがない場合、処理は、プロセス４００が終了するブロック４１６に進む。

プロセス４００は、ドキュメントの単一のコンテナに関連する、本発明の初期バッチ索引付けプロセスを説明している。ネットワーク上には複数のドキュメントからなる多くのコンテナが存在する場合もあり、プロセス４００は、ネットワーク上のすべてのドキュメントをバッチ索引付けするために必要に応じて繰り返すことができる。

図５は、本発明による変更ログの機能ブロック図を示している。変更ログ５００は、ネットワーク上のドキュメントに変更が発生するに連れて、変更ログが変更レコードで効果的に「満たされる」ように、構造化された複数の変更レコード（たとえば５０２）を含んでいる。特定のポイント（たとえば５０４および５０６）において、新しいクロールが発生して索引が更新され、更新済み索引に反映された最終変更レコードに関連付けられている変更ＩＤ（たとえば５１４）が記録される。１つの実施形態において、変更ログ５００は、サーバのデータベースに格納される（たとえば、図３のデータベース３１４）。

変更レコード（たとえば５０２）は、イベント・タイプ５１０、オブジェクト識別５１２、および変更ＩＤ（つまりトークン）５１４を含んでいる。イベント・タイプ５１０は、変更レコードに対応して発生した変更イベントのタイプを参照する。一部のイベント・タイプは、イベントの追加、削除、修正、移動、名前変更を含んでいる。これらのイベントは、オブジェクト識別５１２に従って特定のドキュメントに関連付けられている。オブジェクト識別５１２は、変更済みドキュメントに関連付けられている特定のオブジェクトを識別するのに十分な識別情報を参照する。オブジェクト識別５１２に含まれる一部の例示的な情報は、ドキュメントＩＤ、コンテナＩＤ、オブジェクトＩＤ、および／または変更済みドキュメントに対応してオブジェクトを識別するための他の識別子情報、を含んでいる。変更ＩＤ５１４は、変更レコード自体を識別し、更新プロセスが現在変更ログ５００内のどこにあるかのインディケーションを提供する。

最終更新が発生した変更ログ内のポイント（たとえば５０４および５０６）は、最終変更ＩＤまたは現行の変更ＩＤに関して識別することができる。最終変更ＩＤは、索引に反映されている最終変更の変更ログにおける位置の識別を参照する。現行の変更ＩＤは、変更ログのその位置に対してクエリが行われた時点の変更ログにおける現行位置の識別を参照する。インデクサによって要求された場合、最終変更ＩＤ（たとえば５０４）および現行の変更ＩＤ（たとえば５０６）の間に発生した変更のバッチは、解決されて索引を更新する。バッチ索引付けに変更ログを使用するためのプロセスについては、以下で図６および図７を参照して説明される。

図６は、本発明による初期クロール中の変更ログの使用を初期化するための例示的なプロセスの論理流れ図を示している。プロセス６００はブロック６０２において開始し、そこで、インデクサが初期クロールを開始する。処理は、ブロック６０４に続く。

ブロック６０４において、Ｗｅｂサービスは、変更ログ内の現行位置を求める要求をインデクサから受け取る。処理は、ブロック６０６に続く。

ブロック６０６において、Ｗｅｂサービスは、変更ログ内の現行位置を求める要求をデータベースに転送する。ここで、要求は変更ログ内の最終変更ＩＤを求める要求に対応している。要求がＷｅｂサービスによって転送されると、処理はブロック６０８に移動する。

ブロック６０８において、変更ログからの最終変更ＩＤは、Ｗｅｂサービスによってインデクサに転送される。インデクサは、その後の増分クロール（incremental crawls）で使用できるように最終変更ＩＤを格納する。増分クロール・プロセスについては、以下で図７を参照して説明される。最終変更ＩＤがインデクサによって格納されると、処理は、プロセス６００が終了するブロック６１０に進む。

１つの実施形態において、複数の変更ログは、複数のデータベースに対応するサーバ上にあってもよい。複数の変更ログの場合、最終変更ＩＤは、インデクサに返される前に集約される。

図７は、本発明による増分クロールのための例示的なプロセスの論理流れ図を示している。プロセス７００はブロック７０２において開始し、そこで、インデクサが増分クロールを開始する。処理は、ブロック７０４に続く。

ブロック７０４において、変更されたコンテンツを求める要求がインデクサからＷｅｂサービスによって受け取られる。この要求は、インデクサによって以前格納された最終変更ＩＤを含んでいる（前述の図６を参照）。要求がＷｅｂサービスによって受け取られると、処理はブロック７０６に続く。

ブロック７０６において、この要求は、最終変更ＩＤに対応する変更ログ内の位置以降に変更ログ内で発生した変更を求める要求として、データベースに転送される。この要求がデータベースによって受け取られると、処理はブロック７０８に続く。

ブロック７０８において、Ｗｅｂサービスは、最終変更ＩＤ以降に発生した変更の最初のバッチを取り出す。１つの実施形態において、この変更のバッチは、最終変更ＩＤ後に出現した最初の千個の変更レコードに対応する。Ｗｅｂサービスはさらに、現行の変更ＩＤを取り出す。変更のバッチおよび現行の変更ＩＤが取り出されると、処理はブロック７１０に続く。

ブロック７１０において、変更レコードのバッチは、変更済みのコンテンツを取り出すためにソートされる。たとえば、同じコンテナ内のドキュメントに発生した変更は、まとめてグループ化されるようにソートされる。変更済みコンテンツを取り出すために変更レコードをソートすることで、オブジェクト・モデルによってデータベースに行うクエリの数が減少する。変更レコードがソートされ、変更済みコンテンツが取り出されると、処理はブロック７１２に移動する。

ブロック７１２において、変更ログから取り出された変更レコードのバッチに対応するドキュメント内のバッチ処理された変更は、インデクサに転送される。さらにインデクサに転送されるのは、インデクサによって格納される現行の変更ＩＤである。インデクサは、次の増分クロールの最終変更ＩＤとして現行の変更ＩＤを使用する。現行の変更ＩＤがインデクサによって格納され、索引が転送された変更済みコンテンツに従って更新されると、処理はブロック７１４に進み、そこで、プロセス７００が終了する。

１つの実施形態において、複数の変更ログは、複数のデータベースに対応するサーバ上にあってもよい。複数の変更ログの場合、現行の変更ＩＤおよび変更済みコンテンツは、インデクサに返される前に集約される。

前述の仕様、例およびデータは、本発明の構造の製造および使用について詳細に説明している。本発明の多くの実施例は、本発明の精神および範囲を逸脱することなく実行することができるため、本発明は添付されている特許請求の範囲に属している。

本発明の１つの例示的な実施形態において使用することができる例示的なコンピュータ装置を示す図である。 本発明が操作するネットワーク化システムの例示的なアーキテクチャを示す図である。 本発明によるネットワーク・ドキュメントのバッチ索引付けのためのインデクサおよびサーバ間の例示的な通信システムを示す機能ブロック図である。 本発明による初期クロール中のバッチ索引付けの例示的なプロセスを示す論理流れ図である。 本発明による変更ログを示す機能ブロック図である。 本発明による初期クロール中の変更ログの使用を初期化するための例示的なプロセスを示す論理流れ図である。 本発明による増分クロールのための例示的なプロセスを示す論理流れ図である。

符号の説明

１００ コンピュータ装置
１０２ 処理装置
１０４ システム・メモリ
１０５ オペレーティング・システム
１０６ アプリケーション
１０７ プログラム・データ
１０９ 取り外し可能ストレージ
１１０ 固定ストレージ
１１２ 入力装置
１１４ 出力装置
１１６ 通信接続
１１８ 他のコンピュータ装置
１２０ バッチ索引付け（BACHED INDEXING）
２００ ネットワーク化システムの例示的なアーキテクチャ
２０４ サーバ
２０６ クローラ（CRAWLER）
２０８ インデクサ（INDEXER）
２１０ 索引
２１２ ネットワーク
２１４ クライアント
２１５ ブラウザ
２１６ ネットワーク
２１８ リモート・サーバ
２２２、２２４ ドキュメント
２３０ 検索エンジン
２３２、２３４ ドキュメント
２５０ Ｗｅｂサービス
３００ システム
３０２ インデクサ（INDEXER）
３１０ サーバ
３１２ フロント・エンド
３１４ データベース
３２０ Ｗｅｂサービス
３２２ オブジェクト・モデル

Claims (25)

1. リポジトリ内のドキュメントのバッチ索引付けのためのコンピュータ実装方法であって、
   前記リポジトリからドキュメントの第１のバッチを取得すること、
   ドキュメントの前記第１のバッチを索引付けすること、
   変更ログから、当該変更ログの以前のアクセス以降に変更されているドキュメントのリストを取得すること、
   前記リストに対応する前記リポジトリからドキュメントの第２のバッチを取得すること、および
   ドキュメントの前記第２のバッチを索引付けすること
   を備えることを特徴とする方法。
2. 前記変更ログ内の最終更新位置を記録することをさらに備え、前記変更ログはドキュメントの前記第２のバッチの変更に対応するレコードを含むことを特徴とする請求項１に記載のコンピュータ実装の方法。
3. 前記変更に対応する前記レコードはそれぞれ、イベント・タイプ、変更識別子、およびドキュメント識別ののうちの少なくとも１つを含むことを特徴とする請求項２に記載のコンピュータ実装の方法。
4. 前記第１のバッチドキュメントのサイズを制限するバッチ・サイズ制限を設定することをさらに備えることを特徴とする請求項１に記載のコンピュータ実装の方法。
5. ドキュメントの第１のバッチを取得することは、前記リポジトリ内の各ドキュメントに対応するメタデータを取得して、前記リポジトリ内のどのドキュメントをドキュメントの前記第１のバッチに含めるか否かを決定することをさらに備えることを特徴とする請求項１に記載のコンピュータ実装の方法。
6. 前記メタデータは、前記ドキュメントのサイズおよび前記ドキュメントの拡張子のうちの少なくとも１つに対応することを特徴とする請求項５に記載のコンピュータ実装の方法。
7. ドキュメントの第１のバッチを取得することは、ドキュメントの前記第１のバッチがドキュメントの前記第１のバッチよりも大きい数のドキュメントを含むドキュメント・コンテナに対応する場合、ドキュメントの前記第１のバッチにｃｏｏｋｉｅを関連付けることをさらに備えることを特徴とする請求項１に記載のコンピュータ実装の方法。
8. 変更されているドキュメントのリストを変更ログから取得する前に変更の要求を受け取ることをさらに備えることを特徴とする請求項１に記載のコンピュータ実装の方法。
9. ドキュメントの前記第２のバッチを取得することが前記リポジトリへのより少ない要求しか必要としないように、前記リポジトリに関連付けられている階層に従って変更されたドキュメントの前記リストをソートすることをさらに備えることを特徴とする請求項１に記載のコンピュータ実装の方法。
10. リポジトリ内のドキュメントのバッチ索引付けのためのシステムであって、
    検索クエリのためにドキュメントを索引付けするためのインデクサと、
    コンピュータ実行可能命令であって、
    前記リポジトリからドキュメントの第１のバッチを取得すること、
    ドキュメントの前記第１のバッチを前記インデクサに転送すること、
    変更ログから、前記変更ログの以前のアクセス以降に変更されているドキュメントのリストを取得すること、
    前記リストに対応する前記リポジトリからドキュメントの第２のバッチを取得すること、および
    ドキュメントの前記第２のバッチを前記インデクサに転送すること
    を備えるコンピュータ実行可能命令を実行するように構成されたサーバとして配置されたコンピュータ装置と
    を備えることを特徴とするシステム。
11. 前記変更ログ内の最終更新位置を記録することをさらに備え、前記変更ログはドキュメントの前記第２のバッチの変更に対応するレコードを含むことを特徴とする請求項１０に記載のシステム。
12. 前記変更に対応する前記レコードはそれぞれ、イベント・タイプ、変更識別子、およびドキュメント識別のうちの少なくとも１つを含むことを特徴とする請求項１１に記載のシステム。
13. 前記第１のバッチドキュメントのサイズを制限するバッチ・サイズ制限を設定することをさらに備えることを特徴とする請求項１０に記載のシステム。
14. ドキュメントの第１のバッチを取得することは、前記リポジトリ内の各ドキュメントに対応するメタデータを取得して、前記リポジトリ内のどのドキュメントをドキュメントの前記第１のバッチに含めるか否かを決定することをさらに備えることを特徴とする請求項１０に記載のシステム。
15. 前記メタデータは、前記ドキュメントのサイズおよび前記ドキュメントの拡張子のうちの少なくとも１つに対応することを特徴とする請求項１４に記載のシステム。
16. ドキュメントの第１のバッチを取得することは、ドキュメントの前記第１のバッチがドキュメントの前記第１のバッチよりも大きい数のドキュメントを含むドキュメント・コンテナに対応する場合、ドキュメントの前記第１のバッチにｃｏｏｋｉｅを関連付けることをさらに備えることを特徴とする請求項１０に記載のシステム。
17. 変更されているドキュメントのリストを変更ログから取得する前に変更の要求を受け取ることをさらに備えることを特徴とする請求項１０に記載のシステム。
18. ドキュメントの前記第２のバッチを取得することが前記リポジトリへのより少ない要求を必要とするように、前記リポジトリに関連付けられている階層に従って変更されたドキュメントの前記リストをソートすることをさらに備えることを特徴とする請求項１０に記載のシステム。
19. リポジトリ内のドキュメントのバッチ索引付けのためのコンピュータ実行可能命令を含むコンピュータ可読媒体であって、前記命令は、
    前記リポジトリからドキュメントの第１のバッチを取得すること、
    ドキュメントの前記第１のバッチをインデクサに転送すること、
    ドキュメントの第２のバッチの変更に対応するレコードを含む変更ログ内の最終更新位置を記録すること、
    前記最終更新位置を前記インデクサに転送すること、
    前記最終更新位置以降に変更されているドキュメントのリストを変更ログから取得すること、
    現在の更新位置を前記変更ログに記録すること、
    前記リストに対応する前記リポジトリからドキュメントの前記第２のバッチを取得すること、および
    ドキュメントの前記第２のバッチおよび前記現行の更新位置を前記インデクサに転送すること
    を備えるコンピュータ可読媒体。
20. 前記変更に対応する前記レコードはそれぞれ、イベント・タイプ、変更識別子、およびドキュメント識別ののうちの少なくとも１つを含むことを特徴とする請求項１９に記載のコンピュータ可読媒体。
21. ドキュメントの第１のバッチを取得することは、前記リポジトリ内の各ドキュメントに対応するメタデータを取得して、前記リポジトリ内のどのドキュメントをドキュメントの前記第１のバッチに含めるか否かを決定することをさらに備えることを特徴とする請求項１９に記載のコンピュータ可読媒体。
22. 前記メタデータは、前記ドキュメントのサイズおよび前記ドキュメントの拡張子のうちの少なくとも１つに対応することを特徴とする請求項２１に記載のコンピュータ可読媒体。
23. ドキュメントの第１のバッチを取得することは、ドキュメントの前記第１のバッチがドキュメントの前記第１のバッチよりも大きい数のドキュメントを含むドキュメント・コンテナに対応する場合、ドキュメントの前記第１のバッチにｃｏｏｋｉｅを関連付けることをさらに備えることを特徴とする請求項１９に記載のコンピュータ可読媒体。
24. ドキュメントの前記第２のバッチを取得することが前記リポジトリへのより少ない要求を必要とするように、前記リポジトリに関連付けられている階層に従って変更されたドキュメントの前記リストをソートすることをさらに備えることを特徴とする請求項１９に記載のコンピュータ可読媒体。
25. 前記最終更新位置を他の最終更新位置と集約すること、および
    ドキュメントを前記インデクサに提供するために追加のリポジトリが使用された場合に前記最終更新位置および前記現行の更新位置をインデクサに転送する前に、前記現行の更新位置を他の更新位置と集約すること
    をさらに備えることを特徴とする請求項１９に記載のコンピュータ可読媒体。
    
    

Images