(57)【要約】【課題】  検索クエリーに応じてキャッシュを担当するサーバを動的に選択決定することで負荷分散をはかり、検索径路の最適化を行なう。【解決手段】  各サーバ１〜４は、クライアントから検索クエリーを受信し、検索結果を返信する手段と、自身が前記受信した検索クエリーに対応するキャッシュを担当しない場合に他のサーバに前記キャッシュを担当しているか否かを問い合わせる手段と、前記問い合わせ結果から前記受信した検索クエリーが初出の検索クエリーである場合に、当該検索クエリーに係る単体検索リクエストを発行し、この検索結果に応じて当該検索クエリーに対応するキャッシュ担当のサーバを選択する手段と、キャッシュ担当サーバの情報を前記クライアントに送信する手段とを備える。【選択図】    図１
2006195533.tif 000002
【特許請求の範囲】
【請求項１】
Ｐ２Ｐネットワークシステムにおけるサーバであってインデックス情報を保持するインデックスサーバにおいて、
クライアントから検索クエリーを受信し、検索結果を返信する手段と、
自身が前記受信した検索クエリーに対応するキャッシュを担当しない場合に他のサーバに前記キャッシュを担当しているか否かを問い合わせる手段と、
前記問い合わせ結果から前記受信した検索クエリーが初出の検索クエリーである場合に、当該検索クエリーに係る単体検索リクエストを発行し、この検索結果に応じて当該検索クエリーに対応するキャッシュ担当のサーバを選択する手段と、
キャッシュ担当サーバの情報を前記クライアントに送信する手段と、
を備えたことを特徴とするインデックスサーバ。
【請求項２】
自身が前記受信した検索クエリーに対応するキャッシュを担当している場合に、他のサーバからインデックスの最終更新日時を取得して前記キャッシュの作成日時と比較し、この比較結果に応じて前記他のサーバの検索結果に基づいた前記キャッシュの更新および前記キャッシュの作成日時の更新を行う手段をさらに備えたことを特徴とする請求項１に記載のインデックスサーバ。
【請求項３】
前記他のサーバの検索スコアの方が自身の検索スコアよりも高い場合に、自身のキャッシュを破棄し、最多スコアのサーバを当該検索クエリーに対応するキャッシュ担当に選択する手段をさらに備えたことを特徴とする請求項２に記載のインデックスサーバ。
【請求項４】
前記問い合わせ結果から前記受信した検索クエリーが既出の検索クエリーであり且つ他のサーバがキャッシュを担当している場合に、前記キャッシュを担当しているサーバに対して分散検索リクエストを発行し、この検索結果を受信して前記クライアントへ応答する手段をさらに備えたことを特徴とする請求項１から３のいずれかの項に記載のインデックスサーバ。
【請求項５】
Ｐ２Ｐネットワークシステムにおいて、
請求項１から４のいずれかの項に記載のインデックスサーバと、
前記サーバの任意の一個に対して検索クエリーを発行するクライアントと、
を有することを特徴とするＰ２Ｐネットワークシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インデックスサーバ及びＰ２Ｐ（Peer to Peer）ネットワーシステムに関する。
【背景技術】
【０００２】
アクセス権限にかかわる検索時間の短縮化、およびファイル操作の効率化を図ることができる分散ファイル共有システムが知られている（例えば、特許文献１参照）。また、インデックス情報を保持するインデックスサーバを動的に生成配置するＰ２Ｐシステム「ＡｍｏｒｐｈｉｃＮｅｔ」では、インデックスサーバのアクセス負荷を分散するために、子のインデックスサーバを生成し、インデックスサーバを複数分散させることが可能になっている（例えば、非特許文献１参照）。
【特許文献１】特開２００３−１６２４４１号公報
【非特許文献１】「インデスサーバを動的生成配置するＰ２ＰシステムＡｍｏｒｐｈｉｅＮｅｔ」，ＦＩＴ（情報科学技術フォーラム）２００２，ｐｐ．２１７−２１８、インターネットＵＲＬ（ｈｔｔｐ：／／ｗｗｗ．ｉｐｓｊ．ｏｒ．ｊｐ／１０ｊｉｇｙｏ／ｆｉｔ／ｆｉｔ２００２／ＬＭ＿３．ｐｄｆ）
【発明の開示】
【発明が解決しようとする課題】
【０００３】
上記した特許文献１、あるいは非特許文献１に開示された技術によれば、子のインデックスサーバにインデックス情報がない場合、子のインデックスサーバから親のインデックスサーバに対して検索が行われる。従って、親のインデックスサーバが保持しているインデックス情報を検索するような場合は、検索負荷が集中してボトルネックとなる。
また、単純にクラスタリングをおこない、子インデックスサーバを複数並列配置した場合、インデックスサーバ間の連携がないため、同じ検索クリエーが異なるインデックスサーバで発行されるようなケースでは冗長となる。
【０００４】
本発明は上記事情に鑑みてなされたものであり、検索クエリーに応じてキャッシュを担当するサーバを動的に選択決定することで負荷分散を図ると共に、検索径路の最適化が可能なインデックスサーバ及びＰ２Ｐネットワーシステムを提供することを目的とする。
【課題を解決するための手段】
【０００５】
上記の課題を解決するために、本発明に係るインデックスサーバは、Ｐ２Ｐネットワークシステムにおけるサーバであってインデックス情報を保持するインデックスサーバにおいて、クライアントから検索クエリーを受信し、検索結果を返信する手段と、自身が前記受信した検索クエリーに対応するキャッシュを担当しない場合に他のサーバに前記キャッシュを担当しているか否かを問い合わせる手段と、前記問い合わせ結果から前記受信した検索クエリーが初出の検索クエリーである場合に、当該検索クエリーに係る単体検索リクエストを発行し、この検索結果に応じて当該検索クエリーに対応するキャッシュ担当のサーバを選択する手段と、キャッシュ担当サーバの情報を前記クライアントに送信する手段とを備えたことを特徴とする。
【０００６】
本発明に係るインデックスサーバにおいては、自身が前記受信した検索クエリーに対応するキャッシュを担当している場合に、他のサーバからインデックスの最終更新日時を取得して前記キャッシュの作成日時と比較し、この比較結果に応じて前記他のサーバの検索結果に基づいた前記キャッシュの更新および前記キャッシュの作成日時の更新を行う手段をさらに備えたことを特徴とする。
【０００７】
本発明に係るインデックスサーバにおいては、前記他のサーバの検索スコアの方が自身の検索スコアよりも高い場合に、自身のキャッシュを破棄し、最多スコアのサーバを当該検索クエリーに対応するキャッシュ担当に選択する手段をさらに備えたことを特徴とする。
【０００８】
本発明に係るインデックスサーバにおいては、前記問い合わせ結果から前記受信した検索クエリーが既出の検索クエリーであり且つ他のサーバがキャッシュを担当している場合に、前記キャッシュを担当しているサーバに対して分散検索リクエストを発行し、この検索結果を受信して前記クライアントへ応答する手段をさらに備えたことを特徴とする。
【０００９】
本発明に係るＰ２Ｐネットワークシステムは、Ｐ２Ｐネットワークシステムにおいて、請求項１から４のいずれかの項に記載のインデックスサーバと、前記サーバの任意の一個に対して検索クエリーを発行するクライアントとを有することを特徴とする。
【発明の効果】
【００１０】
本発明によれば、検索クエリーに応じてキャッシュを担当するサーバが動的に決定されるため、一つのキャッシュに負荷が集中することはなくなり、負荷分散の面で効果が得られる。
また、本発明によれば、キャッシュが形成される２回目以降の検索では、クライアントが、キャッシュ担当サーバの情報を活用することにより、同じ検索クエリーは、キャッシュ担当サーバに発行されることになる。この場合、キャッシュを担当するサーバは、他のサーバに比較して、検索クエリーに対して最も多くの検索結果を持つ。この検索結果は、クライアントとキャッシュ担当サーバ間のみを移動するため、分散検索のネットワーク中にトラフィックは発生しない。また、個々のサーバが検索クエリー結果をキッシュするような場合、分散検索のネットワーク中に、その都度検索結果の断片が流通することになるが、この場合には最終更新日時のトラフィックのみで検索が完了する。また、キャッシュの更新が必要になった場合にも、トラフィックの発生は最低限で済む。
【発明を実施するための最良の形態】
【００１１】
図１は、本発明の一実施形態に係るＰ２Ｐネットワークシステムの構成の一例を示す図である。
図１において、符号１〜符号４は、インデックス情報を保持するクラスタ構成のサーバ（それぞれ、サーバ＃０〜＃３）であり、クライアント５とはそれぞれが同じ条件で接続される。なお、ここでは、クライアント５を１個しか示していないが複数のクライアントでＰ２Ｐネットワークを構築しているものとする。
【００１２】
上記システム構成において、クライアント５は、いずれのサーバ１〜４にリクエストを発行してもよく、そのためのアクセス径路が確保されている。また、サーバ１〜４は、いずれも以下に列挙する同等の機能を備え、サーバ１〜４間の通信径路も確保されてあるものとする。
それぞれのサーバ１〜４が同等に持つ機能とは、（１）単純クエリー機能と、（２）最終更新日時取得機能と、（３）グローバルキャッシュ保持クエリー機能と、（４）グローバル検索機能であり、いずれの機能も各サーバ１〜４に内蔵されたメモリにプログラムされており、それぞれのサーバ１〜４において制御中枢となる各ＣＰＵがメモリからプログラムを読み出し実行することによって実現されるものである。
【００１３】
（１）単純クエリー機能
クライアント５から検索クエリーを受信して該当するローカルコンテンツのファイルリストを応答する機能である。
（２）最終更新日時取得機能
ローカルコンテンツの最終更新日時を応答する機能である。
（３）グローバルキャッシュ保持クエリー機能
クライアント５から検索クエリーを受信し、当該検索クエリーの全サーバにおける結果のキャッシュであるグローバルキャッシュを待っている場合には値として“ｔｒｕｅ（真）”を返し、クライアント５に対してグローバルキャッシュの存在を表明する機能である。
【００１４】
（４）グローバル検索機能
自サーバ（例えば、サーバ＃０）が上記したグローバルキャッシュを持っている場合には、他サーバ（例えば、サーバ＃１〜＃３）の最終更新日時とキュッシュを比較し、キャッシュを更新した上でレスポンスを返す。一方、自サーバがグローバルキャッシュを持っていない場合には、他サーバにグローバルキャッシュ保持クエリーを発行して、ネットワーク上にグローバルキャッシュの存在を検索する機能である。検索の結果、グローバルキャッシュが見つかった場合には、該当サーバにグローバル検索要求を発行して、得られた結果を返す。見つからない場合には、自身が他のサーバに単体検索リクエストを発行して、検索結果を返す。このとき、自サーバの検索スコアが最多だった場合には、自サーバにグローバルキャッシユを新規作成する。否の場合には、推奨ホストとして最多スコアのサーバを設定する。
なお、グローバル検索機能のレスポンスには、検索クエリーと検索クエリー結果と推奨ホストが記述される。次回以降、同じ検索クエリーを発行する場合には推奨ホストにアクセスすれば最も良いパフォーマンスが得られる。
【００１５】
なお、（２）最終更新日時取得機能は、グローバルキャッシュを持つ場合、他のサーバにおけるキャッシュの最終更新日時とキャッシュの作成日時を比較し、キャッシュを更新して応答する。
【００１６】
また、（４）グローバル検索機能は、グローバルキャッシユを持たない場合、他のサーバにマルチスレッド型の単体検索リクエストを発行してグローバルキャッシュの存在をチェックし、見つかった場合、グローバルキャッシュを持つサーバに対して分散検索リクエストを発行して得られる結果をクライアントに応答し、見つからなかった場合、他の全てのサーバに分散検索リクエストを発行してその検索結果をクライアントに応答する。
【００１７】
また、（４）グローバル検索機能は、他のサーバからの応答に基づき検索スコアを計算し、自身の検索スコアが最多であった場合、グローバルキャッシャを新規に作成し、最多でなかった場合、最多スコアを持つ他のサーバを検索クエリーに応答するサーバとして選択する。
【００１８】
図２〜図５に、本実施形態の動作がネットワーク上に概念的に示されている。図２はリクエストの受付け処理、図３は初出検索クエリー発行ケース、図４は既出検索クエリーのキャッシュ担当サーバへのリクエスト発行ケース、図５は既出クエリーの非キャッシュ担当サーバへのリクエスト発行ケースのそれぞれを示す。
以下、図２〜図５を参照しながら、図１に示す本実施形態の概略動作について説明する。
【００１９】
先ず、リクエストの受付けについて図２を参照しながら説明する。クライアント５は任意のサーバ１〜４に対してリクエストを発行することができる（Ｓ２１）。リクエストを受信した各サーバ１〜４は、リクエストが以下のいずれに該当するかを判断してそのリクエストを処理する。
すなわち、「初出の検索クエリー」、「既出の検索クエリーであり、自身がキャッシュを担当している場合」、「既出の検索クエリーであるが、他のサーバがキャッシュを担当している場合」のいずれに該当するか判断する。このため、各サーバ１〜４は、他のサーバからの当該検索クエリーのキャッシュを担当しているか否かの問い合わせを処理する機能を有する（Ｓ２３）。この問合せの結果に基づき上記判断が実行される。なお、リクエストを受信したサーバ自身がそのクエリーキャッシュを担当している場合、他のサーバへの問合せは発生しない（Ｓ２２）。
【００２０】
ここで、検索クエリーが初出であった場合には、図３に示されるように、リクエストを受信したサーバ１（＃０）からマルチスレッド型の単体検索リクエストが発行され（Ｓ３１）、他のサーバ２〜４からの検索結果がサーバ１（＃０）に集約される（Ｓ３２）。
サーバ１（＃０）では、その検索結果を評価して、検索リクエストに対して最も多くの検索結果を返すサーバ２（＃１）を選択決定し（Ｓ３３）、検索結果、検索クエリー、キャッシュ担当サーバのそれぞれの情報を要求のあったクライアント５に返す（Ｓ３４）。この後、以下に説明する手順に従いキャッシュ担当サーバが決定され、ネットワーク上の特定の検索クエリーに対応する唯一のキャッシュ担当サーバが決まる。
【００２１】
キャッシュ担当サーバの決定にあたり、単体検索リクエストを受信したサーバ１（＃０）とキャッシュ担当サーバとが一致する場合には、サーバ１（＃０）がキャッシュ担当になり、検索結果をキャッシュする（Ｓ３５）。
リクエストを受信したサーバ１（＃０）とキャッシュ担当サーバ（例えば、サーバ４）とが不一致の場合には、サーバ１（＃０）からサーバ４（＃３）に対して分散検索リクエストを発行する（Ｓ３５）。このことにより、サーバ４（＃３）では初出の「検索クエリーの処理」が繰り返され（Ｓ３６）、最終的に、サーバ４（＃３）がキャッシュ担当サーバになり、ここでキャッシュが構築される（Ｓ３７）。
【００２２】
一方、既出の検索クエリーのキャッシュ担当サーバへのリクエス発行のケースが図４に示されている。
ここでは、分散検索リクエストを受信したサーバがキャッシュの更新を行い、当該キャッシュをクライアント５に返す。具体的に、キャッシュ担当サーバ１（＃０）は、それぞれのサーバ２、３、４に対して、最終更新日付を取得するクエリーを発行し（Ｓ４１）、キャッシユの作成日時と比較する。ここで、キャッシュの作成日時が新しい場合にはキャッシュは更新されない。一方、キャッシュの作成日時が古い場合には該当サーバに対して単体検索リクエストを発行して検索結果とキャッシュの作成日時を更新する（Ｓ４３、Ｓ４４）。このような方法で、キャッシュは常に最新の情報に維持される。
【００２３】
なお、その際、他のサーバのスコアが高い場合にはキャッシュを破棄し（Ｓ４６）、分散検索リクエストをスコアが高いサーバに発行する（Ｓ４６）。分散検索リクエストを受信したサーバ４（＃３）では、分散検索の再実行により上記した初出の検索クエリーの処理が繰り返され（Ｓ４７）、最終的にサーバ４（＃３）にキャッシュが構築され、サーバ４（＃３）がキャッシュ担当サーバになる（Ｓ４８）。上記方法により、キャッシュ担当サーバは動的に決定される。
【００２４】
また、既出の検索クエリーの非キャッシュ担当サーバへのリクエスト発行のケースが図５に示されている。
ここでは、分散検索リクエストを受信したサーバ１（＃０）がキャッシュを担当しているサーバ４（＃３）に対して分散検索リクエストを発行する（Ｓ５１）。サーバ４（＃３）では、上記したキャッシュを担当する場合の処理が実行され、キャッシュの更新を行った上で検索結果を作成する（Ｓ５２）。続いて、サーバ１（＃０）は、サーバ４（＃３）から取得した検索結果をクライアント５に返す（Ｓ５３、Ｓ５４）。
【００２５】
上述したように、サーバ１〜４は、クライアント５から検索クエリーを受信してグローバルキャッシュを持つことを表明し、グローバルキャッシュを持つ場合、他のサーバにおけるキャッシュの最終更新日時とキャッシュの作成日時を比較してキャッシュを更新して応答する。グローバルキャッシユを持たない場合、他のサーバにマルチスレット型の単体検索リクエストを発行してグローバルキャッシュの存在をチェックし、見つかった場合、グローバルキャッシュを持つサーバに対して分散検索リクエストを発行して得られる結果を応答し、見つからなかった場合、他の全てのサーバに分散検索リクエストを発行してその検索結果を応答する。
【００２６】
図６、図７に上記した分散検索リクエスト実行のための処理の流れがフローチャートで示されている。以下、図６、図７に示すフローチャートを参照しながらサーバにおける分散検索クエリー実行の流れを説明する。
あるサーバ（例えば、サーバ４）が、クライアント５から検索クエリーを受信した他のサーバ（例えば、サーバ１）から分散検索リクエスト（クエリー）を受信したとする（図６、Ｓ６１）。このとき、サーバ４は、自身がキャッシュ担当であるか否かを判断し（Ｓ６２）、キャッシュを担当している場合、他のサーバ１、２、３に対して最終更新日時を取得するクエリーを発行し、自身のキャッシュの作成日時と比較する（Ｓ６３）。このことにより更新されたサーバの有無を調べ（Ｓ６４）、更新されたサーバがある場合、キャッシュの作成日時が新しいときはキャッシュを更新することなく、キャッシュの更新日時が古いときはそのサーバに対して単体検索リクエストを発行し、検索結果とキャッシュの作成日時を更新する（Ｓ６６）。そしてキャッシュの更新を行い、キャッシュを常に最新の状態に維持する（Ｓ６７）。なお、更新されたサーバがない場合はキャッシュをクライアント５に返して終了する（Ｓ６５）。
【００２７】
一方、キャッシュの更新後（Ｓ６７）、更新されたサーバとヒット数（スコア）の比較を行い（図７、Ｓ７４）、更新されたサーバの方のヒット数が多い場合、キャッシュをクライアント５に返す（Ｓ７６）。このとき、キャッシュ担当サーバは、最多検索結果サーバに変更されている。そして、キャッシュを破棄して分散検索リクエストをスコアが高いサーバに発行する（Ｓ７８）。このとき、発行されたサーバでは、初出の検索クエリーの処理が繰り返され、最終的にキャッシュが構築されてキャッシュ担当サーバになる。このようにして、キャッシュ担当サーバが動的に決定される。
なお、Ｓ７４の処理で、更新されたサーバの方のヒット数が少ない場合は、クライアント５にキャッシュを返して終了する（Ｓ７５）。
【００２８】
また、Ｓ６２の処理において、キャッシュ担当サーバでない場合ことが確認されると、他のサーバに対してキャッシュ問い合わせクエリーを発行し（Ｓ６８）、キャッシュ担当サーバの存在を調べる（Ｓ６９）。
キャッシュ担当サーバが存在する場合、そのキャシュ担当サーバへ分散検索リクエスト（クエリー）を発行し（Ｓ７０）、そのクエリー結果をクライアント５にそのまま返して終了する（Ｓ７１）。このとき、キャッシュ担当サーバが通知される。また、キャッシュ担当サーバが存在しない場合、全てのサーバに対して単体検索リクエスト（クエリー）を発行し（Ｓ７２）、結果を集約してキャッシュ担当サーバを決定する（Ｓ７３）。続いてクライアント５に集約結果を返し（Ｓ７９）、このとき、最多検索結果のサーバがキャッシュ担当サーバとして通知される。
【００２９】
次に、キャッシュ担当の有無を調べ（Ｓ８０）、キャッシュ担当である場合はキャッシュを形成し（Ｓ８１）、否の場合は、最多検索結果のサーバへ分散検索検索リクエストを発行し（Ｓ８２）、このとき、最多検索結果のサーバにおいてキャッシュが形成される。
【００３０】
図８は、本発明のクラスタ構成のサーバを持つＰ２Ｐネットワーシステムにおけるインデックス情報検索方法を適用した例と従来例との性能対比をグラフ表示した図である。
ここでは、いずれも縦軸に検索に要した計測時間、横軸に試行回数を割付け、教育施設の取得を検索クエリーとした場合のそれぞれのサーバ（ここでは、新宿のデータを持つ“shinjuku”、ショットガンのデータを持つ“shotgum”、渋谷のデータを持つ“shibuya”、学校のデータを持つ“school”）からのデータ取得に関するバフォーマンスを示してある。
【００３１】
図８から、従来のマルチスレッド型の単体検索（図中、Ｘ）では、平均的に本発明を適用した分散検索（Ｙ）より遅く、かつ、ばらつきが大きいことが確認できる。また、サーバ“shinjuku”、サーバ“shibuya”に比較して、サーバ“school”のバフォーマンスが優れ、従って本発明方法によれば短時間に検索が可能であり、キャッシュ担当（“school”）であれば更に時間短縮されることがわかる。
【００３２】
上述した実施形態によれば、検索クエリーに応じてキャッシュを担当するサーバを動的に決定することができ、このことにより、一つのキャッシュに負荷が集中することはなくなり、負荷分散が図れる。また、キャッシュが形成される２回目以降の検索では、クライアントが、キヤッシュ担当サーバの情報を活用することにより、同じ検索クエリーは、キャッシュ担当サーバに発行されることになる。この場合、キャッシュを担当するサーバは、他のサーバに比較して、検索クエリーに対して最も多くの検索結果を持つ。この検索結果は、クライアントとキャッシュ担当サーバ間のみを移動するため、分散検索のネットワーク中にトラフィックは発生しない。また、個々のサーバが検索クエリー結果をキッシュするような場合で、分散検索のネットワーク中に、その都度検索結果の断片が流通することになるが、この場合には最終更新日時のトラフィックのみで検索が完了する。キャッシュの更新が必要になった場合にも、トラフィックの発生は最低限で済む。
【００３３】
以上、本発明の実施形態を図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、本発明の要旨を逸脱しない範囲の設計変更等も含まれる。
【図面の簡単な説明】
【００３４】
【図１】本発明の実施形態に係わるＰ２Ｐネットワークシステムのシステム構成の一例を示す図である。
【図２】本発明の実施形態の動作をネットワーク上に概念的に示す図である。
【図３】本発明の実施形態の動作をネットワーク上に概念的に示す図である。
【図４】本発明の実施形態の動作をネットワーク上に概念的に示す図である。
【図５】本発明の実施形態の動作をネットワーク上に概念的に示す図である。
【図６】本発明の実施形態の動作を示すフローチャートである。
【図７】本発明の実施形態の動作を示すフローチャートである。
【図８】本発明を適用した例と従来例との性能対比をグラフ表示した図である。
【符号の説明】
【００３５】
１〜４…サーバ、５…クライアント。
【図１】
2006195533.tif 000003
【図２】
2006195533.tif 000004
【図３】
2006195533.tif 000005
【図４】
2006195533.tif 000006
【図５】
2006195533.tif 000007
【図６】
2006195533.tif 000008
【図７】
2006195533.tif 000009
【図８】
2006195533.tif 000010