情報検索システム、検索サーバ及びプログラム
【課題】従来の情報検索システムは、検索用インデクスのオンラインアップデートを実現するため、インデクスのコピーを格納する物理ストレージを検索用と更新用の２系統用意する必要がある。
【解決手段】ＯＳの提供するスナップショット機能により、オリジナルのインデクスの複製を作成し、その複製に対して検索エンジンをアタッチして利用するとともに、オリジナルのインデクスデータに対してインデクス更新処理を適用する。
【解決手段】ＯＳの提供するスナップショット機能により、オリジナルのインデクスの複製を作成し、その複製に対して検索エンジンをアタッチして利用するとともに、オリジナルのインデクスデータに対してインデクス更新処理を適用する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インデックス容量の増大を抑制可能な情報検索システム及び検索サーバに関する。
【背景技術】
【０００２】
情報爆発時代の到来により、組織・企業内において取り扱われるデータ量は指数関数的に増加している。なお、増加の著しいデータの多くは、ファイル等の非構造型データであると言われている。データ量の増加に伴い、情報の管理・再利用による業務効率の向上が求められている。これに伴い、組織・企業内におけるファイル検索技術のニーズが大きく拡大している。こうした背景に加え、近年における大量データ処理技術やファイル検索技術の発展・普及により、企業内におけるエンタープライズサーチの導入が進んでいる。
【０００３】
検索システムの性能要件に挙げられる項目の一つに、インデクスの更新処理に要する時間（以下「更新処理時間」という。）がある。更新処理時間は、定期的に実行されるインデクス更新処理のバッチ処理時間が短いほど良い。
【０００４】
また、検索システムの性能要件に挙げられる他の項目に、検索サービスを止めることなくインデクスを定期的に更新する機能、すなわち、検索サービスの可用性がある。検索サービスを停止しないインデクスの更新には、検索用と更新用の２つのインデクスを用いる方法がある。この方法は、検索用インデクスを利用して検索サービスを提供しつつ、バックグラウンドで更新用インデクスを更新する。具体的には、前回のインデクス更新時から新しく更新のあったファイルのみを差分インデクスとして構成し、更新用インデクスをマージする。ただし、この方法は、インデクスデータの保持領域を物理的に２つ保持する必要があり、ストレージ容量が最小必要量の２倍になってしまう。
【０００５】
例えば特許文献１には、インデクスデータを圧縮・削減する方式として、以下の方法が開示されている。外部文書番号と内部文書番号をテーブルで管理し、文書に更新が発生すると、編集により存在位置が変更された文字列に関する位置情報のみをインデクスに追加する。これにより、高速なインデクス更新機能を実現するとともに、位置情報の二重登録を防止する。その結果、総インデクス容量の増加を抑えている。
【０００６】
一方、特許文献２には、以下の方法が開示されている。インデクスの生成時、各文書の文字列を単語ごとに分割し、各単語が先頭から数えて何番目に位置するかを示す位置情報の数字を求める。その後、各単語の位置を示す数字を予め設定された固定長以下の数値に集約する。最後に、位置情報の列を１つの転置リストにマッピングして保存する。これにより、インデクスサイズを削減する。また、固定長の代わりに、任意に指定された区切り文字を用いて位置情報を集約することにより、誤検出の可能性はあるものの検出漏れを防いでいる。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００１−１４３４２号公報
【特許文献２】特開２０１０−２６２３７９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
前述した特許文献１及び２に係る発明では、個々のインデクスデータのデータ格納方式を工夫することにより、インデクスデータ自体の圧縮・削減を実現する。しかし、検索サービスを無停止のままインデクスを更新するには、依然として、２系統のインデクスデータを物理的に保持することに変わりはなく、２重化によるデータ容量の大幅な増加を防ぐことは難しい。また、インデクスの最適化処理に関する効率化を実現する方式でもない。
【０００９】
本発明は、インデクスの２重化によるデータ容量の物理的な増大を防ぎつつ、オンラインによるインデクスの更新を実現する。
【課題を解決するための手段】
【００１０】
前述した課題を解決するため、本発明に係る情報検索システムにおいては、オリジナルのインデクスファイルのスナップショットを作成し、検索用インデクスにはスナップショット側のデータを利用し、更新にはオリジナルのデータを利用する。
【発明の効果】
【００１１】
本発明によれば、インデックス更新中の可用性を維持しつつも、必要とされる物理的なストレージ容量を削減することができる。上述した以外の課題、構成及び効果は、以下の説明により明らかにされる。
【図面の簡単な説明】
【００１２】
【図１】本形態例に係る情報検索システムの構成を説明する図。
【図２】スナップショットを利用したインデクス更新処理の概念を示す図。
【図３】クローリング管理DBテーブルの構成例を示す図。
【図４】インデクス生成・更新に関する全体処理を説明するフローチャート。
【図５】クローリング処理を説明するフローチャート。
【図６】差分インデクス生成処理を説明するフローチャート。
【図７】インデクス更新処理を説明するフローチャート。
【発明を実施するための形態】
【００１３】
以下の実施の形態においては、便宜上その必要があるときは、複数のセクションまたは実施の形態に分割して説明する。以下の実施の形態において、要素の数等（個数、数値、量、範囲等を含む）に言及する場合、特に明示した場合および原理的に明らかに特定の数に限定される場合等を除き、その特定の数に限定されるものではなく、特定の数以上でも以下でもよい。
【００１４】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一の機能を有する部材には同一または関連する符号を付し、その繰り返しの説明は省略する。また、以下の実施の形態では、特に必要なとき以外は同一または同様な部分の説明を原則として繰り返さない。
【００１５】
図１に、形態例に係る情報検索システムの全体構成を示す。当該システムは、利用者端末１０１、ファイルサーバ１０２、インデクス生成サーバ１０３、検索サーバ１０４で構成される。本形態例の場合、ファイルサーバ１０２とインデクス生成サーバ１０３はＬＡＮ１０５を介して接続され、利用者端末１０１、インデクス生成サーバ１０３、検索サーバ１０４はＬＡＮ１０５を介して接続される。本形態例では、ＬＡＮ１０５を介して各装置が接続されているが、インターネット等のネットワーク経由で接続されてもよい。
【００１６】
図１には、インデクス生成サーバ１０３と検索サーバ１０４が物理的に別のマシン上で稼働する例を表しているが、これらのサーバは物理的に同一のマシン上で稼働してもよい。
【００１７】
ファイルサーバ１０２には、検索対象となるファイル１０６が格納されている。
インデクス生成サーバ１０３には、クローリングモジュール１０７、インデクス生成モジュール１０８、検索エンジン１０９、クローリング管理ＤＢ１１０が配置される。クローリングモジュール１０７は、ファイルサーバ１０２を探索して更新ファイルを発見し、ダウンロードする機能を提供する。インデクス生成モジュール１０８は、ダウンロードされたデータから差分インデクスを生成する。検索エンジン１０９は、インデクス生成・検索機能を提供するモジュールであり、オープンソースの検索エンジンとして、Apache LuceneやSennaがある。検索エンジン１０９は、差分インデクス生成時にインデクス生成モジュール１０８により利用される。クローリング管理ＤＢ１１０は、前回のクローリング時からのファイル・ディレクトリの更新を管理する。
【００１８】
検索サーバ１０４には、検索エンジン１０９、検索サービス１１１、インデクス管理サービス１１２、ファイルシステム１１３、ボリューム管理サービス１１４、検索用インデクス１１５、オリジナルインデクス１１６が配置される。検索サービス１１１は、利用者端末１０１から検索要求を受け付けると、検索エンジン１０９を使用して検索結果を生成して応答する。インデクス管理サービス１１２は、インデクス生成サーバ１０３で生成された差分インデクスと削除ファイルリストに基づいてオリジナルインデクス１１６に対して更新処理を行う。この他、インデクス管理サービス１１２は、オリジナルインデクス１１６の更新後にボリューム管理サービス１１４が提供するスナップショット機能により検索用インデクス１１５を生成する。また、インデクス管理サービス１１２は、生成した検索用インデクス１１５を検索可能にする検索エンジン１０９が提供する検索コアのアタッチ機能を提供する。例えば、Apache Luceneをベースにした検索サービスを実現するSolrには、前述の検索コアに相当するSolrCoreが存在し、インデクスがアタッチされたSolrCoreを動的に切り替えることにより、検索可能なインデクスのリアルタイムの切り替え機能を実現する。ボリューム管理サービス１１４は、論理ボリュームを構成可能にする検索サーバのOSに搭載されたサービスであり、例えばLinuxにおけるLVM（Logical Volume Manager）が一例である。ボリューム管理サービス１１４は、構成されたボリュームに対してスナップショットを作成する機能を提供する。スナップショット機能はCopy On Writeにより、瞬間的にボリュームのコピーを生成する機能であり、生成されたコピーはRead Onlyでアクセス可能である。
【００１９】
図２に、スナップショットを利用したインデクス更新処理の概念を示す。検索用インデクスとして検索コア２０１がアタッチしているN（自然数）世代目インデクス２０２は、オリジナルインデクス２０３を格納する論理ボリュームに対してスナップショットで生成され、コピーされたボリューム上のインデクスである。検索エンジン１０９は、検索要求に対し、検索用インデクス１１５であるN世代目インデクス２０２にアクセスして検索処理を実行する。検索処理において、インデクスへのアクセスはRead Onlyである。このため、スナップショット上のインデクスデータに対し、検索コア２０１をアタッチして検索処理することができる。
【００２０】
次回更新時には、オリジナルインデクス２０３に対して更新処理を行う。このとき、スナップショット上のN世代目インデクス２０２のデータをそのままにして、オリジナルインデクス２０３のデータを更新することができる。更新後は、新たにスナップショットを生成し、そのスナップショット上のインデクスデータをN+1世代目インデクスとする。このN+1世代目インデクスに検索コア２０１をアタッチして検索可能にした後、N世代目インデクスを格納するスナップショットを削除する。このようにスナップショットを利用することで、インデクスを物理的に完全に２重化する方式に比べ、インデクスが使用するストレージ容量を圧縮・削減することができる。
【００２１】
図３に、クローリング管理ＤＢ１１０に登録されているテーブルの構造例を示す。テーブルの属性値には、パス名３０１、ハッシュ値３０２、削除フラグ３０３がある。パス名３０１は、検索対象となるファイルサーバ内に格納されているファイル・ディレクトリのファイルパスを記録する。ハッシュ値３０２は、ファイル・ディレクトリの属性情報（ファイルパス、更新日時、所有者、ACL等）のハッシュ値を格納する。ハッシュ値３０２は、各ファイルパスで指定されたファイルの更新の検知に利用される。
【００２２】
削除フラグ３０３は、前回のクローリング時と比較して、登録エントリに対応するファイル・ディレクトリが削除されているかどうかをチェックするために使用するフラグ情報である。削除フラグ３０３は、クローリング時に初期値として「１」が設定され、クローリングで存在が確認されたファイル・ディレクトリに「０」が設定される。全てのファイル・ディレクトリのクローリングが完了した時点で、削除フラグ３０３が「１」のエントリを調べると、削除ファイルリストを作成することができる。
【００２３】
インデクス生成サーバ１０３は、削除ファイルリストと、新規作成・更新のあったファイルに関する差分インデクスを生成し、検索サーバ１０４に転送する。検索サーバ１０４は、転送された削除ファイルリストと差分インデクスを用い、現在利用されているインデクスの更新処理を実行する。
【００２４】
図４に、インデクスの生成・更新処理を説明するフローチャートを示す。インデクスの生成・更新処理は、インデクス生成サーバ１０３及び検索サーバ１０４上で定期的に実行される処理である。インデクスの生成・更新処理は、前回の実行後に新規に作成・更新又は削除されたファイル・ディレクトリに対し、現在の検索サーバ１０４上で利用されているインデクスを更新する処理である。
【００２５】
インデクスの生成・更新処理が開始されると、インデクス生成サーバ１０３は、検索対象となるファイルサーバ１０２に対してクローリング処理が実行される（ステップ４０１）。クローリング処理においては、前回のインデクス生成・更新処理以降に削除されたファイルリスト（削除ファイルリスト）の作成と、新規に作成・更新されたファイルのダウンロードが実行される。その後、ダウンロードされたファイルデータを用いた差分インデクスの生成処理が行われる（ステップ４０２）。次に、生成された差分インデクスと削除ファイルリストは検索サーバ１０４に転送され（ステップ４０３）、検索サーバ１０４上で、転送されたデータに基づいて現在検索に利用しているインデクスの更新処理を実行する（ステップ４０４）。フローチャートにおいて、サブルーチンとして定義したクローリング処理、差分インデクス生成処理、インデクス更新処理の詳細については、以降のフローチャートで説明する。
【００２６】
図５に、クローリング処理のフローチャートを示す。クローリング処理は、インデクス生成サーバ内のクローリングモジュール１０７で実行される。クローリングモジュール１０７は、探索対象であるファイルサーバ１０２のディレクトリを探索するが、探索される各ファイル・ディレクトリに関してループ処理を行う（ステップ５０１）。
【００２７】
まず、クローリングモジュール１０７は、探索対象とするファイル・ディレクトリのファイル属性値を取得し、ハッシュ値を計算する（ステップ５０２）。次に、ファイルパスをキーとしてクローリング管理ＤＢ１１０をチェックし、指定されたファイルパスのエントリがＤＢ内に存在するか否かをチェックする（ステップ５０３）。
【００２８】
クローリング管理ＤＢ１１０にファイルパスが存在しない場合（ステップ５０３で否定結果の場合）、当該ファイルパスのファイル・ディレクトリは、前回のクローリング時以降に新規生成されたことを意味する。このため、クローリングモジュール１０７は、クローリング管理ＤＢ１１０にエントリを追加し、ファイルの場合はデータをダウンロードする（ステップ５０４）。ファイル・ディレクトリが存在するため、クローリングモジュール１０７は、削除フラグをクリアして（ステップ５０７）、ループの次の探索ファイル・ディレクトリ処理に移行する。
【００２９】
一方、クローリング管理ＤＢ１１０にファイルパスが存在しない場合（ステップ５０３で肯定結果の場合）、クローリングモジュール１０７は、計算したファイル属性値のハッシュ値が、クローリング管理ＤＢ１１０に登録されているハッシュ値と等しいがどうかチェックする（ステップ５０５）。
【００３０】
計算したハッシュ値が登録されているハッシュ値が同じ場合（ステップ５０５で肯定結果の場合）、前回のクローリング時から更新されていないことを意味する。この場合、クローリングモジュール１０７は、データのダウンロード処理は行わず、削除フラグをクリアしてループ処理の次のステップに移る（ステップ５０７）。
【００３１】
計算されたハッシュ値が登録されているハッシュ値と異なる場合（ステップ５０５で否定結果の場合）、前回のクローリング時よりファイル・ディレクトリが更新されていることを意味する。この場合、クローリングモジュール１０７はエントリのハッシュ値を更新し、ファイルの場合はデータをダウンロードする（ステップ５０６）。その後、クローリングモジュール１０７は、削除フラグをクリアしてループ処理の次のステップに移る（ステップ５０７）。
【００３２】
探索・ダウンロード処理のループが終了した段階で、クローリングモジュール１０７は、クローリング管理ＤＢ１１０の削除フラグをチェックし、削除フラグが「１」のエントリのファイルパスを全て取得して削除ファイルリストを生成し、その後、次回クローリング処理のために全エントリの削除フラグを「１」に初期化する（ステップ５０８）。
【００３３】
図６に、差分インデクス生成処理のフローチャートを示す。差分インデクス生成処理は、インデクス生成モジュール１０８により実行される。本モジュールは、クローリング処理によりダウンロードされた新規作成・更新されたファイル群に逐次アクセスし、差分インデクスに登録処理を行うループ処理を実行する（ステップ６０１）。
【００３４】
ループ処理が開始されると、インデクス生成モジュール１０８は、ファイルからテキストデータを抽出し（ステップ６０２）、ファイルのメタデータを抽出する（ステップ６０３）。その後、インデクス生成モジュール１０８は、差分インデクスに追加登録するためのデータを作成する。インデクス生成モジュール１０８は、そのデータを入力値として検索エンジン１０９を利用し、作成されたデータを差分インデクスに追加登録する（ステップ６０４）。全てのダウンロードデータが差分インデクスに登録されるまでループ処理を続ける。本処理で生成される差分インデクスは、前回のインデクス生成・更新処理以降に新規作成・更新されたファイル群に関するインデクスである。
【００３５】
図７に、インデクス更新処理のフローチャートを示す。本処理は、検索サーバ１０４上でインデクス管理サービスにより実行される処理であり、インデクス生成サーバ１０３で生成された差分インデクス及び削除ファイルリストに基づいて、N世代目の検索用インデクスであるN世代目インデクスを更新する処理である。
【００３６】
まず始めに、インデクス管理サービスは、N世代目インデクスのスナップショットの元となるオリジナルインデクスに対し、削除ファイルリストに記録されたファイルに関するエントリを削除する（ステップ７０１）。
【００３７】
次に、インデクス管理サービスは、オリジナルインデクスに差分インデクスをマージする（ステップ７０２）。例えば、Luceneの場合、インデクス管理サービスは、差分インデクスをオリジナルインデクスにマージするために、まず、差分インデクスに登録されているファイル群の中からオリジナルインデクスに登録されているものを削除する。その後、インデクス管理サービスは、差分インデクスのデータをオリジナルインデクスに追加する。
【００３８】
次に、インデクス管理サービスは、更新されたオリジナルインデクスを記録しているボリュームのスナップショットを作成する（ステップ７０３）。その後、インデクス管理サービスは、作成したスナップショット上のインデクスを、N+1代目インデクスとして新規に生成した検索コア２０１にアタッチし（ステップ７０４）、アタッチした検索コア２０１のウォームアップ処理を実行する（ステップ７０５）。ウォームアップ処理とは、検索履歴情報を用いて、N+1世代目インデクスにアタッチした検索コアが内部的にアタッチしたインデクスに対してクエリを発行し、結果をキャッシュする処理で、次回クエリ時の応答性能の向上に行われる。ウォームアップ処理が終わると、インデクス管理サービスは、N世代目インデクスとN+1世代目インデクスのそれぞれがアタッチされている検索コア２０１をスワップする（ステップ７０６）。
【００３９】
このスワップ処理により、N+1世代目インデクスが検索可能となる。最後に、インデクス管理サービスは、N世代目インデクスにアタッチされている検索コア２０１を破棄し、N世代目インデクスを保持するスナップショットを削除する（ステップ７０７）。
【００４０】
以上の機能構成を採用することにより、検索サービスを稼働させたまま、動的にインデクスを更新することができる。この際、インデクスの更新はスナップショットの更新により実行する。従って、本形態例に係る情報検索システムは、検索用と更新用の２つのインデクスデータを物理的に保持する必要がない。従って、必要なストレージ容量を節減することができる。
【符号の説明】
【００４１】
１０１…利用者端末
１０２…ファイルサーバ
１０３…インデクス生成サーバ
１０４…検索サーバ
１０５…LAN
１０６…ファイル
１０７…クローリングモジュール
１０８…インデクス生成モジュール
１０９…検索エンジン
１１０…クローリング管理ＤＢ
１１１…検索サービス
１１２…インデクス管理サービス
１１３…ファイルシステム
１１４…ボリューム管理サービス
１１５…検索用インデクス
１１６…オリジナルインデクス
２０１…検索コア
２０２…N世代目インデクス
２０３…オリジナルインデクス
２０４…N+1世代目インデクス
３０１…パス名
３０２…ハッシュ値
３０３…削除フラグ
【技術分野】
【０００１】
本発明は、インデックス容量の増大を抑制可能な情報検索システム及び検索サーバに関する。
【背景技術】
【０００２】
情報爆発時代の到来により、組織・企業内において取り扱われるデータ量は指数関数的に増加している。なお、増加の著しいデータの多くは、ファイル等の非構造型データであると言われている。データ量の増加に伴い、情報の管理・再利用による業務効率の向上が求められている。これに伴い、組織・企業内におけるファイル検索技術のニーズが大きく拡大している。こうした背景に加え、近年における大量データ処理技術やファイル検索技術の発展・普及により、企業内におけるエンタープライズサーチの導入が進んでいる。
【０００３】
検索システムの性能要件に挙げられる項目の一つに、インデクスの更新処理に要する時間（以下「更新処理時間」という。）がある。更新処理時間は、定期的に実行されるインデクス更新処理のバッチ処理時間が短いほど良い。
【０００４】
また、検索システムの性能要件に挙げられる他の項目に、検索サービスを止めることなくインデクスを定期的に更新する機能、すなわち、検索サービスの可用性がある。検索サービスを停止しないインデクスの更新には、検索用と更新用の２つのインデクスを用いる方法がある。この方法は、検索用インデクスを利用して検索サービスを提供しつつ、バックグラウンドで更新用インデクスを更新する。具体的には、前回のインデクス更新時から新しく更新のあったファイルのみを差分インデクスとして構成し、更新用インデクスをマージする。ただし、この方法は、インデクスデータの保持領域を物理的に２つ保持する必要があり、ストレージ容量が最小必要量の２倍になってしまう。
【０００５】
例えば特許文献１には、インデクスデータを圧縮・削減する方式として、以下の方法が開示されている。外部文書番号と内部文書番号をテーブルで管理し、文書に更新が発生すると、編集により存在位置が変更された文字列に関する位置情報のみをインデクスに追加する。これにより、高速なインデクス更新機能を実現するとともに、位置情報の二重登録を防止する。その結果、総インデクス容量の増加を抑えている。
【０００６】
一方、特許文献２には、以下の方法が開示されている。インデクスの生成時、各文書の文字列を単語ごとに分割し、各単語が先頭から数えて何番目に位置するかを示す位置情報の数字を求める。その後、各単語の位置を示す数字を予め設定された固定長以下の数値に集約する。最後に、位置情報の列を１つの転置リストにマッピングして保存する。これにより、インデクスサイズを削減する。また、固定長の代わりに、任意に指定された区切り文字を用いて位置情報を集約することにより、誤検出の可能性はあるものの検出漏れを防いでいる。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００１−１４３４２号公報
【特許文献２】特開２０１０−２６２３７９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
前述した特許文献１及び２に係る発明では、個々のインデクスデータのデータ格納方式を工夫することにより、インデクスデータ自体の圧縮・削減を実現する。しかし、検索サービスを無停止のままインデクスを更新するには、依然として、２系統のインデクスデータを物理的に保持することに変わりはなく、２重化によるデータ容量の大幅な増加を防ぐことは難しい。また、インデクスの最適化処理に関する効率化を実現する方式でもない。
【０００９】
本発明は、インデクスの２重化によるデータ容量の物理的な増大を防ぎつつ、オンラインによるインデクスの更新を実現する。
【課題を解決するための手段】
【００１０】
前述した課題を解決するため、本発明に係る情報検索システムにおいては、オリジナルのインデクスファイルのスナップショットを作成し、検索用インデクスにはスナップショット側のデータを利用し、更新にはオリジナルのデータを利用する。
【発明の効果】
【００１１】
本発明によれば、インデックス更新中の可用性を維持しつつも、必要とされる物理的なストレージ容量を削減することができる。上述した以外の課題、構成及び効果は、以下の説明により明らかにされる。
【図面の簡単な説明】
【００１２】
【図１】本形態例に係る情報検索システムの構成を説明する図。
【図２】スナップショットを利用したインデクス更新処理の概念を示す図。
【図３】クローリング管理DBテーブルの構成例を示す図。
【図４】インデクス生成・更新に関する全体処理を説明するフローチャート。
【図５】クローリング処理を説明するフローチャート。
【図６】差分インデクス生成処理を説明するフローチャート。
【図７】インデクス更新処理を説明するフローチャート。
【発明を実施するための形態】
【００１３】
以下の実施の形態においては、便宜上その必要があるときは、複数のセクションまたは実施の形態に分割して説明する。以下の実施の形態において、要素の数等（個数、数値、量、範囲等を含む）に言及する場合、特に明示した場合および原理的に明らかに特定の数に限定される場合等を除き、その特定の数に限定されるものではなく、特定の数以上でも以下でもよい。
【００１４】
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一の機能を有する部材には同一または関連する符号を付し、その繰り返しの説明は省略する。また、以下の実施の形態では、特に必要なとき以外は同一または同様な部分の説明を原則として繰り返さない。
【００１５】
図１に、形態例に係る情報検索システムの全体構成を示す。当該システムは、利用者端末１０１、ファイルサーバ１０２、インデクス生成サーバ１０３、検索サーバ１０４で構成される。本形態例の場合、ファイルサーバ１０２とインデクス生成サーバ１０３はＬＡＮ１０５を介して接続され、利用者端末１０１、インデクス生成サーバ１０３、検索サーバ１０４はＬＡＮ１０５を介して接続される。本形態例では、ＬＡＮ１０５を介して各装置が接続されているが、インターネット等のネットワーク経由で接続されてもよい。
【００１６】
図１には、インデクス生成サーバ１０３と検索サーバ１０４が物理的に別のマシン上で稼働する例を表しているが、これらのサーバは物理的に同一のマシン上で稼働してもよい。
【００１７】
ファイルサーバ１０２には、検索対象となるファイル１０６が格納されている。
インデクス生成サーバ１０３には、クローリングモジュール１０７、インデクス生成モジュール１０８、検索エンジン１０９、クローリング管理ＤＢ１１０が配置される。クローリングモジュール１０７は、ファイルサーバ１０２を探索して更新ファイルを発見し、ダウンロードする機能を提供する。インデクス生成モジュール１０８は、ダウンロードされたデータから差分インデクスを生成する。検索エンジン１０９は、インデクス生成・検索機能を提供するモジュールであり、オープンソースの検索エンジンとして、Apache LuceneやSennaがある。検索エンジン１０９は、差分インデクス生成時にインデクス生成モジュール１０８により利用される。クローリング管理ＤＢ１１０は、前回のクローリング時からのファイル・ディレクトリの更新を管理する。
【００１８】
検索サーバ１０４には、検索エンジン１０９、検索サービス１１１、インデクス管理サービス１１２、ファイルシステム１１３、ボリューム管理サービス１１４、検索用インデクス１１５、オリジナルインデクス１１６が配置される。検索サービス１１１は、利用者端末１０１から検索要求を受け付けると、検索エンジン１０９を使用して検索結果を生成して応答する。インデクス管理サービス１１２は、インデクス生成サーバ１０３で生成された差分インデクスと削除ファイルリストに基づいてオリジナルインデクス１１６に対して更新処理を行う。この他、インデクス管理サービス１１２は、オリジナルインデクス１１６の更新後にボリューム管理サービス１１４が提供するスナップショット機能により検索用インデクス１１５を生成する。また、インデクス管理サービス１１２は、生成した検索用インデクス１１５を検索可能にする検索エンジン１０９が提供する検索コアのアタッチ機能を提供する。例えば、Apache Luceneをベースにした検索サービスを実現するSolrには、前述の検索コアに相当するSolrCoreが存在し、インデクスがアタッチされたSolrCoreを動的に切り替えることにより、検索可能なインデクスのリアルタイムの切り替え機能を実現する。ボリューム管理サービス１１４は、論理ボリュームを構成可能にする検索サーバのOSに搭載されたサービスであり、例えばLinuxにおけるLVM（Logical Volume Manager）が一例である。ボリューム管理サービス１１４は、構成されたボリュームに対してスナップショットを作成する機能を提供する。スナップショット機能はCopy On Writeにより、瞬間的にボリュームのコピーを生成する機能であり、生成されたコピーはRead Onlyでアクセス可能である。
【００１９】
図２に、スナップショットを利用したインデクス更新処理の概念を示す。検索用インデクスとして検索コア２０１がアタッチしているN（自然数）世代目インデクス２０２は、オリジナルインデクス２０３を格納する論理ボリュームに対してスナップショットで生成され、コピーされたボリューム上のインデクスである。検索エンジン１０９は、検索要求に対し、検索用インデクス１１５であるN世代目インデクス２０２にアクセスして検索処理を実行する。検索処理において、インデクスへのアクセスはRead Onlyである。このため、スナップショット上のインデクスデータに対し、検索コア２０１をアタッチして検索処理することができる。
【００２０】
次回更新時には、オリジナルインデクス２０３に対して更新処理を行う。このとき、スナップショット上のN世代目インデクス２０２のデータをそのままにして、オリジナルインデクス２０３のデータを更新することができる。更新後は、新たにスナップショットを生成し、そのスナップショット上のインデクスデータをN+1世代目インデクスとする。このN+1世代目インデクスに検索コア２０１をアタッチして検索可能にした後、N世代目インデクスを格納するスナップショットを削除する。このようにスナップショットを利用することで、インデクスを物理的に完全に２重化する方式に比べ、インデクスが使用するストレージ容量を圧縮・削減することができる。
【００２１】
図３に、クローリング管理ＤＢ１１０に登録されているテーブルの構造例を示す。テーブルの属性値には、パス名３０１、ハッシュ値３０２、削除フラグ３０３がある。パス名３０１は、検索対象となるファイルサーバ内に格納されているファイル・ディレクトリのファイルパスを記録する。ハッシュ値３０２は、ファイル・ディレクトリの属性情報（ファイルパス、更新日時、所有者、ACL等）のハッシュ値を格納する。ハッシュ値３０２は、各ファイルパスで指定されたファイルの更新の検知に利用される。
【００２２】
削除フラグ３０３は、前回のクローリング時と比較して、登録エントリに対応するファイル・ディレクトリが削除されているかどうかをチェックするために使用するフラグ情報である。削除フラグ３０３は、クローリング時に初期値として「１」が設定され、クローリングで存在が確認されたファイル・ディレクトリに「０」が設定される。全てのファイル・ディレクトリのクローリングが完了した時点で、削除フラグ３０３が「１」のエントリを調べると、削除ファイルリストを作成することができる。
【００２３】
インデクス生成サーバ１０３は、削除ファイルリストと、新規作成・更新のあったファイルに関する差分インデクスを生成し、検索サーバ１０４に転送する。検索サーバ１０４は、転送された削除ファイルリストと差分インデクスを用い、現在利用されているインデクスの更新処理を実行する。
【００２４】
図４に、インデクスの生成・更新処理を説明するフローチャートを示す。インデクスの生成・更新処理は、インデクス生成サーバ１０３及び検索サーバ１０４上で定期的に実行される処理である。インデクスの生成・更新処理は、前回の実行後に新規に作成・更新又は削除されたファイル・ディレクトリに対し、現在の検索サーバ１０４上で利用されているインデクスを更新する処理である。
【００２５】
インデクスの生成・更新処理が開始されると、インデクス生成サーバ１０３は、検索対象となるファイルサーバ１０２に対してクローリング処理が実行される（ステップ４０１）。クローリング処理においては、前回のインデクス生成・更新処理以降に削除されたファイルリスト（削除ファイルリスト）の作成と、新規に作成・更新されたファイルのダウンロードが実行される。その後、ダウンロードされたファイルデータを用いた差分インデクスの生成処理が行われる（ステップ４０２）。次に、生成された差分インデクスと削除ファイルリストは検索サーバ１０４に転送され（ステップ４０３）、検索サーバ１０４上で、転送されたデータに基づいて現在検索に利用しているインデクスの更新処理を実行する（ステップ４０４）。フローチャートにおいて、サブルーチンとして定義したクローリング処理、差分インデクス生成処理、インデクス更新処理の詳細については、以降のフローチャートで説明する。
【００２６】
図５に、クローリング処理のフローチャートを示す。クローリング処理は、インデクス生成サーバ内のクローリングモジュール１０７で実行される。クローリングモジュール１０７は、探索対象であるファイルサーバ１０２のディレクトリを探索するが、探索される各ファイル・ディレクトリに関してループ処理を行う（ステップ５０１）。
【００２７】
まず、クローリングモジュール１０７は、探索対象とするファイル・ディレクトリのファイル属性値を取得し、ハッシュ値を計算する（ステップ５０２）。次に、ファイルパスをキーとしてクローリング管理ＤＢ１１０をチェックし、指定されたファイルパスのエントリがＤＢ内に存在するか否かをチェックする（ステップ５０３）。
【００２８】
クローリング管理ＤＢ１１０にファイルパスが存在しない場合（ステップ５０３で否定結果の場合）、当該ファイルパスのファイル・ディレクトリは、前回のクローリング時以降に新規生成されたことを意味する。このため、クローリングモジュール１０７は、クローリング管理ＤＢ１１０にエントリを追加し、ファイルの場合はデータをダウンロードする（ステップ５０４）。ファイル・ディレクトリが存在するため、クローリングモジュール１０７は、削除フラグをクリアして（ステップ５０７）、ループの次の探索ファイル・ディレクトリ処理に移行する。
【００２９】
一方、クローリング管理ＤＢ１１０にファイルパスが存在しない場合（ステップ５０３で肯定結果の場合）、クローリングモジュール１０７は、計算したファイル属性値のハッシュ値が、クローリング管理ＤＢ１１０に登録されているハッシュ値と等しいがどうかチェックする（ステップ５０５）。
【００３０】
計算したハッシュ値が登録されているハッシュ値が同じ場合（ステップ５０５で肯定結果の場合）、前回のクローリング時から更新されていないことを意味する。この場合、クローリングモジュール１０７は、データのダウンロード処理は行わず、削除フラグをクリアしてループ処理の次のステップに移る（ステップ５０７）。
【００３１】
計算されたハッシュ値が登録されているハッシュ値と異なる場合（ステップ５０５で否定結果の場合）、前回のクローリング時よりファイル・ディレクトリが更新されていることを意味する。この場合、クローリングモジュール１０７はエントリのハッシュ値を更新し、ファイルの場合はデータをダウンロードする（ステップ５０６）。その後、クローリングモジュール１０７は、削除フラグをクリアしてループ処理の次のステップに移る（ステップ５０７）。
【００３２】
探索・ダウンロード処理のループが終了した段階で、クローリングモジュール１０７は、クローリング管理ＤＢ１１０の削除フラグをチェックし、削除フラグが「１」のエントリのファイルパスを全て取得して削除ファイルリストを生成し、その後、次回クローリング処理のために全エントリの削除フラグを「１」に初期化する（ステップ５０８）。
【００３３】
図６に、差分インデクス生成処理のフローチャートを示す。差分インデクス生成処理は、インデクス生成モジュール１０８により実行される。本モジュールは、クローリング処理によりダウンロードされた新規作成・更新されたファイル群に逐次アクセスし、差分インデクスに登録処理を行うループ処理を実行する（ステップ６０１）。
【００３４】
ループ処理が開始されると、インデクス生成モジュール１０８は、ファイルからテキストデータを抽出し（ステップ６０２）、ファイルのメタデータを抽出する（ステップ６０３）。その後、インデクス生成モジュール１０８は、差分インデクスに追加登録するためのデータを作成する。インデクス生成モジュール１０８は、そのデータを入力値として検索エンジン１０９を利用し、作成されたデータを差分インデクスに追加登録する（ステップ６０４）。全てのダウンロードデータが差分インデクスに登録されるまでループ処理を続ける。本処理で生成される差分インデクスは、前回のインデクス生成・更新処理以降に新規作成・更新されたファイル群に関するインデクスである。
【００３５】
図７に、インデクス更新処理のフローチャートを示す。本処理は、検索サーバ１０４上でインデクス管理サービスにより実行される処理であり、インデクス生成サーバ１０３で生成された差分インデクス及び削除ファイルリストに基づいて、N世代目の検索用インデクスであるN世代目インデクスを更新する処理である。
【００３６】
まず始めに、インデクス管理サービスは、N世代目インデクスのスナップショットの元となるオリジナルインデクスに対し、削除ファイルリストに記録されたファイルに関するエントリを削除する（ステップ７０１）。
【００３７】
次に、インデクス管理サービスは、オリジナルインデクスに差分インデクスをマージする（ステップ７０２）。例えば、Luceneの場合、インデクス管理サービスは、差分インデクスをオリジナルインデクスにマージするために、まず、差分インデクスに登録されているファイル群の中からオリジナルインデクスに登録されているものを削除する。その後、インデクス管理サービスは、差分インデクスのデータをオリジナルインデクスに追加する。
【００３８】
次に、インデクス管理サービスは、更新されたオリジナルインデクスを記録しているボリュームのスナップショットを作成する（ステップ７０３）。その後、インデクス管理サービスは、作成したスナップショット上のインデクスを、N+1代目インデクスとして新規に生成した検索コア２０１にアタッチし（ステップ７０４）、アタッチした検索コア２０１のウォームアップ処理を実行する（ステップ７０５）。ウォームアップ処理とは、検索履歴情報を用いて、N+1世代目インデクスにアタッチした検索コアが内部的にアタッチしたインデクスに対してクエリを発行し、結果をキャッシュする処理で、次回クエリ時の応答性能の向上に行われる。ウォームアップ処理が終わると、インデクス管理サービスは、N世代目インデクスとN+1世代目インデクスのそれぞれがアタッチされている検索コア２０１をスワップする（ステップ７０６）。
【００３９】
このスワップ処理により、N+1世代目インデクスが検索可能となる。最後に、インデクス管理サービスは、N世代目インデクスにアタッチされている検索コア２０１を破棄し、N世代目インデクスを保持するスナップショットを削除する（ステップ７０７）。
【００４０】
以上の機能構成を採用することにより、検索サービスを稼働させたまま、動的にインデクスを更新することができる。この際、インデクスの更新はスナップショットの更新により実行する。従って、本形態例に係る情報検索システムは、検索用と更新用の２つのインデクスデータを物理的に保持する必要がない。従って、必要なストレージ容量を節減することができる。
【符号の説明】
【００４１】
１０１…利用者端末
１０２…ファイルサーバ
１０３…インデクス生成サーバ
１０４…検索サーバ
１０５…LAN
１０６…ファイル
１０７…クローリングモジュール
１０８…インデクス生成モジュール
１０９…検索エンジン
１１０…クローリング管理ＤＢ
１１１…検索サービス
１１２…インデクス管理サービス
１１３…ファイルシステム
１１４…ボリューム管理サービス
１１５…検索用インデクス
１１６…オリジナルインデクス
２０１…検索コア
２０２…N世代目インデクス
２０３…オリジナルインデクス
２０４…N+1世代目インデクス
３０１…パス名
３０２…ハッシュ値
３０３…削除フラグ
【特許請求の範囲】
【請求項１】
ファイルサーバに接続された情報処理システムにおいて、
前記ファイルサーバに格納されたファイル群の中から、新規生成・更新、及び、削除されたファイル群を探索する処理機能と、
新規生成・更新されたファイル群をダウンロードする処理機能と、
削除されたファイル群に関する削除ファイルリストを生成する処理機能と、
ダウンロードされたファイル群のインデクスを生成する処理機能と、
前記インデクス及び前記削除ファイルリストを用い、記憶領域に格納されたインデクスを更新する処理機能と、
更新後のインデクスデータを格納する論理ボリュームのスナップショットを作成する処理機能と、
前記スナップショットされたボリューム上のインデクスデータを検索可能なインデクスとして設定する処理機能と
を有することを特徴とする情報処理システム。
【請求項２】
請求項１に記載の情報処理システムにおいて、
前記ファイルサーバに格納されたファイル群の中から、新規生成・更新、及び削除されたファイル群を探索する処理機能は、前回のインデクス更新処理時における前記ファイルサーバ内の全ファイル・ディレクトリのパス名を鍵とする各ファイル・ディレクトリの属性情報のハッシュ値及び削除フラグを格納したＤＢに照会し、新規生成・更新ファイルの検知及び削除されたファイルを認識することを特徴とする情報処理システム。
【請求項３】
請求項１に記載の情報処理システムにおいて、
N（自然数）＋１番目のインデクスを検索可能なインデクスとして設定した後に、N番目のインデクスデータを保持するスナップショットを削除する処理機能を有する
ことを特徴とする情報処理システム。
【請求項４】
インデクス生成サーバに接続される検索サーバにおいて、
前回のインデクス生成以降、ファイルサーバで新規に生成・更新されたファイル群のインデクスと前記ファイルサーバから削除されたファイル群に関する削除ファイルリストを、前記インデクス生成サーバから受信する処理機能と、
前記インデクス及び前記削除ファイルリストを用い、記憶領域に格納されたインデクスを更新する処理機能と、
更新後のインデクスデータを格納する論理ボリュームのスナップショットを作成する処理機能と、
前記スナップショットされたボリューム上のインデクスデータを検索可能なインデクスとして設定する処理機能と
を有することを特徴とする検索サーバ。
【請求項５】
請求項４に記載の検索サーバにおいて、
N（自然数）＋１番目のインデクスを検索可能なインデクスとして設定した後に、N番目のインデクスデータを保持するスナップショットを削除する処理機能を有する
ことを特徴とする検索サーバ。
【請求項６】
ファイルサーバに接続された情報処理システムに搭載されるコンピュータに、
前記ファイルサーバに格納されたファイル群の中から、新規生成・更新、及び、削除されたファイル群を探索する処理機能、
新規生成・更新されたファイル群をダウンロードする処理機能、
削除されたファイル群に関する削除ファイルリストを生成する処理機能、
ダウンロードされたファイル群のインデクスを生成する処理機能、
前記インデクス及び前記削除ファイルリストを用い、記憶領域に格納されたインデクスを更新する処理機能、
更新後のインデクスデータを格納する論理ボリュームのスナップショットを作成する処理機能、
前記スナップショットされたボリューム上のインデクスデータを検索可能なインデクスとして設定する処理機能
を実行させるプログラム。
【請求項７】
請求項６に記載のプログラムにおいて、
前記ファイルサーバに格納されたファイル群の中から、新規生成・更新、及び削除されたファイル群を探索する処理機能は、前回のインデクス更新処理時における前記ファイルサーバ内の全ファイル・ディレクトリのパス名を鍵とする各ファイル・ディレクトリの属性情報のハッシュ値及び削除フラグを格納したＤＢに照会し、新規生成・更新ファイルの検知及び削除されたファイルを認識することを特徴とするプログラム。
【請求項８】
請求項６に記載のプログラムにおいて、
N（自然数）＋１番目のインデクスを検索可能なインデクスとして設定した後に、N番目のインデクスデータを保持するスナップショットを削除する処理機能を有する
ことを特徴とするプログラム。
【請求項９】
インデクス生成サーバに接続される検索サーバに搭載されるコンピュータに、
前回のインデクス生成以降、ファイルサーバで新規に生成・更新されたファイル群のインデクスと前記ファイルサーバから削除されたファイル群に関する削除ファイルリストを、前記インデクス生成サーバから受信する処理機能、
前記インデクス及び前記削除ファイルリストを用い、記憶領域に格納されたインデクスを更新する処理機能、
更新後のインデクスデータを格納する論理ボリュームのスナップショットを作成する処理機能、
前記スナップショットされたボリューム上のインデクスデータを検索可能なインデクスとして設定する処理機能
を実行させるプログラム。
【請求項１０】
請求項９に記載のプログラムにおいて、
N（自然数）＋１番目のインデクスを検索可能なインデクスとして設定した後に、N番目のインデクスデータを保持するスナップショットを削除する処理機能を有する
ことを特徴とするプログラム。
【請求項１】
ファイルサーバに接続された情報処理システムにおいて、
前記ファイルサーバに格納されたファイル群の中から、新規生成・更新、及び、削除されたファイル群を探索する処理機能と、
新規生成・更新されたファイル群をダウンロードする処理機能と、
削除されたファイル群に関する削除ファイルリストを生成する処理機能と、
ダウンロードされたファイル群のインデクスを生成する処理機能と、
前記インデクス及び前記削除ファイルリストを用い、記憶領域に格納されたインデクスを更新する処理機能と、
更新後のインデクスデータを格納する論理ボリュームのスナップショットを作成する処理機能と、
前記スナップショットされたボリューム上のインデクスデータを検索可能なインデクスとして設定する処理機能と
を有することを特徴とする情報処理システム。
【請求項２】
請求項１に記載の情報処理システムにおいて、
前記ファイルサーバに格納されたファイル群の中から、新規生成・更新、及び削除されたファイル群を探索する処理機能は、前回のインデクス更新処理時における前記ファイルサーバ内の全ファイル・ディレクトリのパス名を鍵とする各ファイル・ディレクトリの属性情報のハッシュ値及び削除フラグを格納したＤＢに照会し、新規生成・更新ファイルの検知及び削除されたファイルを認識することを特徴とする情報処理システム。
【請求項３】
請求項１に記載の情報処理システムにおいて、
N（自然数）＋１番目のインデクスを検索可能なインデクスとして設定した後に、N番目のインデクスデータを保持するスナップショットを削除する処理機能を有する
ことを特徴とする情報処理システム。
【請求項４】
インデクス生成サーバに接続される検索サーバにおいて、
前回のインデクス生成以降、ファイルサーバで新規に生成・更新されたファイル群のインデクスと前記ファイルサーバから削除されたファイル群に関する削除ファイルリストを、前記インデクス生成サーバから受信する処理機能と、
前記インデクス及び前記削除ファイルリストを用い、記憶領域に格納されたインデクスを更新する処理機能と、
更新後のインデクスデータを格納する論理ボリュームのスナップショットを作成する処理機能と、
前記スナップショットされたボリューム上のインデクスデータを検索可能なインデクスとして設定する処理機能と
を有することを特徴とする検索サーバ。
【請求項５】
請求項４に記載の検索サーバにおいて、
N（自然数）＋１番目のインデクスを検索可能なインデクスとして設定した後に、N番目のインデクスデータを保持するスナップショットを削除する処理機能を有する
ことを特徴とする検索サーバ。
【請求項６】
ファイルサーバに接続された情報処理システムに搭載されるコンピュータに、
前記ファイルサーバに格納されたファイル群の中から、新規生成・更新、及び、削除されたファイル群を探索する処理機能、
新規生成・更新されたファイル群をダウンロードする処理機能、
削除されたファイル群に関する削除ファイルリストを生成する処理機能、
ダウンロードされたファイル群のインデクスを生成する処理機能、
前記インデクス及び前記削除ファイルリストを用い、記憶領域に格納されたインデクスを更新する処理機能、
更新後のインデクスデータを格納する論理ボリュームのスナップショットを作成する処理機能、
前記スナップショットされたボリューム上のインデクスデータを検索可能なインデクスとして設定する処理機能
を実行させるプログラム。
【請求項７】
請求項６に記載のプログラムにおいて、
前記ファイルサーバに格納されたファイル群の中から、新規生成・更新、及び削除されたファイル群を探索する処理機能は、前回のインデクス更新処理時における前記ファイルサーバ内の全ファイル・ディレクトリのパス名を鍵とする各ファイル・ディレクトリの属性情報のハッシュ値及び削除フラグを格納したＤＢに照会し、新規生成・更新ファイルの検知及び削除されたファイルを認識することを特徴とするプログラム。
【請求項８】
請求項６に記載のプログラムにおいて、
N（自然数）＋１番目のインデクスを検索可能なインデクスとして設定した後に、N番目のインデクスデータを保持するスナップショットを削除する処理機能を有する
ことを特徴とするプログラム。
【請求項９】
インデクス生成サーバに接続される検索サーバに搭載されるコンピュータに、
前回のインデクス生成以降、ファイルサーバで新規に生成・更新されたファイル群のインデクスと前記ファイルサーバから削除されたファイル群に関する削除ファイルリストを、前記インデクス生成サーバから受信する処理機能、
前記インデクス及び前記削除ファイルリストを用い、記憶領域に格納されたインデクスを更新する処理機能、
更新後のインデクスデータを格納する論理ボリュームのスナップショットを作成する処理機能、
前記スナップショットされたボリューム上のインデクスデータを検索可能なインデクスとして設定する処理機能
を実行させるプログラム。
【請求項１０】
請求項９に記載のプログラムにおいて、
N（自然数）＋１番目のインデクスを検索可能なインデクスとして設定した後に、N番目のインデクスデータを保持するスナップショットを削除する処理機能を有する
ことを特徴とするプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２０１３−７３５５７（Ｐ２０１３−７３５５７Ａ）
【公開日】平成２５年４月２２日（２０１３．４．２２）
【国際特許分類】
【出願番号】特願２０１１−２１４００３（Ｐ２０１１−２１４００３）
【出願日】平成２３年９月２９日（２０１１．９．２９）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
【出願人】（０００２３３０５５）株式会社日立ソリューションズ (1,610)
【公開日】平成２５年４月２２日（２０１３．４．２２）
【国際特許分類】
【出願日】平成２３年９月２９日（２０１１．９．２９）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．Ｌｉｎｕｘ
【出願人】（０００２３３０５５）株式会社日立ソリューションズ (1,610)
[ Back to top ]