JP6167015B2 - 情報処理システム、管理プログラム、及びインデックス管理方法 - Google Patents

Description

本発明は、データ、及びそのデータのメタデータを用いて検索用に構築されたインデックスを複数台の情報処理装置に分散させて管理させるための技術に関する。

コンピュータ等の情報処理装置に蓄積させるデータ量は増大傾向にある。そのため、現在では、大量のデータをより低コストで管理することが強く求められている。分散オブジェクトストレージは、大量のデータを低コストで管理可能な技術の１つとして着目されている。

分散オブジェクトストレージは、複数台のサーバを用いた情報処理システムとして構築される。分散オブジェクトストレージでは、データはオブジェクトとして管理され、オブジェクトは、分散オブジェクトストレージを構成するサーバに分散して保存される。オブジェクトの分散により、そのオブジェクトの保存、及び計算（処理）に利用可能な各リソース量は共に、サーバの台数に応じて向上することになる。そのため、分散オブジェクトストレージでは、サーバの追加により、記憶容量、及びパフォーマンスを共に向上させることができる。

オブジェクトの分散により、処理の負荷も分散させることができる。そのため、サーバに要求される性能も抑えられる。このことから、分散オブジェクトストレージでは、サーバの台数を増やすスケールアウトに要するコストを抑制することができる。

分散オブジェクトストレージでは、オブジェクトの管理にメタデータが用いられる。そのメタデータは、対応するオブジェクトに関連する情報であり、対応するオブジェクトの検索・抽出に用いられる。そのため、オブジェクトを検索・抽出するためのデータであるインデックスは、メタデータを用いて構築される。メタデータは、１つのオブジェクトに対し１つ以上、作成される。

分散オブジェクトストレージにおける検索は、インデックスを管理するサーバによって行われる。分散オブジェクトストレージにおけるインデックスの管理には、以下の方式が用いられている。
（ａ）特定の専用サーバ（例えば１台のサーバ）が全てのインデックスを集中管理する（以降「集中管理方式」と表記）
（ｂ）インデックス毎に、異なるサーバが管理する（以降「個別管理方式」と表記）
（ｃ）自身が保存するオブジェクトのインデックスも併せて管理する（以降「並行管理方式」と表記）

上記各管理方式には、それぞれ以下のような問題点がある。
集中管理方式では、検索、更にはインデックスの更新が専用サーバに集中する。インデックスを管理する専用サーバの台数は、通常、オブジェクトを管理するサーバの台数と比較して、非常に小さい。そのため、専用サーバの負荷が重くなり易い。重い負荷は検索性能を低下させる。

分散オブジェクトストレージは、通常、複数のメタデータを指定したアンド（ＡＮＤ）検索をサポートする。個別管理方式では、アンド検索の場合、指定されたメタデータ毎に、そのメタデータに対応するインデックスを管理するサーバに問い合わせを送信しなければならない。また、フロントエンド等において、各問い合わせによって特定された対象オブジェクトを各サーバから取得し、取得した対象オブジェクトのなかからアンド検索で指定の検索条件を満たす対象オブジェクトを抽出するといった処理を行わなければならない。このようなことから、個別管理方式では、データの転送量が大きくなり易く、高い検索性能は得られ難い。

並行管理方式でも、個別管理方式と同様に、アンド検索の場合、指定されたメタデータ毎に、そのメタデータに対応するインデックスを管理するサーバに問い合わせを送信しなければならない。そのため、高い検索性能は得られ難い。

上記のように、何れの管理方式も、アンド検索時には検索性能が低下し易いという問題点がある。オブジェクトを必要とするユーザにとっての利便性を考慮するならば、アンド検索時における検索性能の低下を抑えることが重要と思われる。

特開２０１２−１６８７８１号公報 特開昭６２−１２１５７６号公報 特開２００２−７６４１号公報 特開２０１２−４８５９２号公報

一側面では、本発明は、分散オブジェクトストレージのような複数台の情報処理装置（サーバ）を用いて構築された情報処理システムにおけるアンド検索時の検索性能の低下を抑制するための技術を提供することを目的とする。

本発明を適用した１システムは、ネットワークを介して第１の情報処理装置と接続された複数台の第２の情報処理装置、及び管理装置を備え、複数台の第２の情報処理装置は、データ、及びデータのメタデータを用いて検索用に構築されたインデックスを分散して管理し、管理装置は、第１の情報処理装置から送信された検索リクエストを監視する監視部と、同一の第２の情報処理装置にインデックスを管理させるべきメタデータの種類の組み合わせを、検索リクエストに含まれる検索条件におけるメタデータの種類の組み合わせについての共起率に基づいて特定すると共に、特定した組み合わせのメタデータの種類に基づいて同一の第２の情報処理装置を特定し、該特定した同一の第２の情報処理装置に、該特定した組み合わせのメタデータの種類のインデックスを管理させるインデックス管理部と、を有する。

本発明を適用した場合には、分散オブジェクトストレージのような複数台の情報処理装置（サーバ）を用いて構築された情報処理システムにおけるアンド検索時の検索性能の低下を抑制することができる。

本実施形態による管理装置を用いて構築された情報処理システムの構成例を説明する図である。 統計情報の構成例を説明する図である。 統計情報の更新例を説明する図である。 インデックスを管理させるストレージサーバ兼インデックス管理サーバの変更例を説明する図である。 統計情報更新処理のフローチャートである。 第１の計数処理のフローチャートである。 第２の計数処理のフローチャートである。 第２の計数処理の変形例のフローチャートである。 インデックス管理サーバ決定処理のフローチャートである。 サーバ決定処理のフローチャートである。 サーバ一連表の構成例を説明する図である。 本実施形態によるストレージサーバ兼インデックス管理サーバとして使用可能な情報処理装置の構成例を表す図である。

以下、本発明の実施形態について、図面を参照しながら詳細に説明する。
図１は、本実施形態による管理装置を用いて構築された情報処理システムの構成例を説明する図である。

図１に表すように、情報処理システムは、ネットワーク１に、複数台のアプリケーションサーバ（図１中「アプリサーバ」と表記。以降この表記を用いる）２、及び複数台のストレージサーバ兼インデックス管理サーバ（以降「ストレージ・インデックス管理サーバ」と表記）３を接続させた構成となっている。

各ストレージ・インデックス管理サーバ３には、管理対象とするデータ、及びそのデータの検索用のデータであるインデックスを保存可能なディスク装置４が接続されている。このディスク装置４を管理する全てのストレージ・インデックス管理サーバ３をネットワーク１と接続することにより、分散オブジェクトストレージが構築されている。

ディスク装置４は、通常、複数台、各ストレージ・インデックス管理サーバ３に接続されるか、或いは１台のストレージである。ここでは、説明上、便宜的に、各ストレージ・インデックス管理サーバ３に接続されているディスク装置４は１台と想定する。

各アプリサーバ２は、不図示の別のネットワークと接続された端末装置を使用するユーザに対してサービスを提供するサーバである。各アプリサーバ２は、分散オブジェクトストレージが管理するデータ（オブジェクト）のなかで端末装置のユーザが要求するデータを提供するフロントエンドとして機能する。また、各アプリサーバ２は、分散オブジェクトストレージの保守、オブジェクトの追加、削除、メタデータの登録、削除、等にも用いることができる。

各ストレージ・インデックス管理サーバ３は、図１に表すように、機能構成として、ネットワーク入出力部３１、データ読み書き部３２、メタデータ読み書き部３３、ディスク入出力部３４、検索部３５、統計情報取得部３６、記憶部３７、及びインデックス管理サーバ決定部３８を備えている。

ネットワーク入出力部３１は、ネットワーク１を介した通信を実現させる。他のストレージ・インデックス管理サーバ３、及び各アプリサーバ２との通信は、ネットワーク入出力部３１を用いて行われる。

データ読み書き部３２は、ディスク装置４からのオブジェクトの読み出し、ディスク装置４へのオブジェクトの書き込み、及びディスク装置４に格納されたオブジェクトの削除、等の操作のための機能である。実際の操作は、ディスク入出力部３４によって行われる。

メタデータ読み書き部３３は、ディスク装置４からのメタデータの読み出し、ディスク装置４へのメタデータの書き込み、及びディスク装置４に格納されたメタデータの削除、等の操作のための機能である。ディスク装置４には、メタデータはインデックスを構成する一部のデータとして格納されている。そのため、実際の操作は、ディスク入出力部３４を用いたインデックスの更新のための操作として行われる。

このインデックスは、メタデータの種類毎に、そのメタデータを用いて構築される検索用のデータである。このインデックスは、メタデータの値（内容）毎に、その値をメタデータとして割り当てられたオブジェクトの保存先を表す保存先情報を備えている。そのインデックスでは、保存先情報からオブジェクトに割り当てられたメタデータの値を特定可能になっている。

各アプリサーバ２は、端末装置のユーザからの要求により、そのユーザがメタデータの値を入力して指定した検索条件に従って、その検索条件を満たすオブジェクトの保存先を確認するための検索リクエストを送信する。ネットワーク入出力部３１は、自ストレージ・インデックス管理サーバ３宛に送信された検索リクエストを受信し、受信した検索リクエストを検索部３５に渡す。検索部３５は、渡された検索リクエスト中に格納されたメタデータの値を抽出し、インデックスに対する検索を行い、その検索結果をネットワーク入出力部３１から送信させる。

記憶部３７は、統計情報３７ａの保存に用いられる。その統計情報３７ａは、メタデータの種類（以降「メタデータ名」と表記）の組み合わせ毎に、その組み合わせで各値が指定された検索条件での検索を行った回数を表す情報である。

図２は、統計情報の構成例を説明する図である。図２中に表記の「メタデータ１」「メタデータ２」は、異なるメタデータ名を表している。「メタデータ」に付した「１」「２」の数値は、辞書に登録された順序、或いは識別用に割り当てられた番号を表している。ここでは、数値は辞書に登録された順序を表していると想定する。

図２では、統計情報の構成例をテーブル形式で表している。それにより、各欄は、回数を計数する１種類のメタデータ名、或いは２種類のメタデータ名の組み合わせを表している。

例えば行、列ともに「メタデータ１」の欄には、メタデータ名としてメタデータ１のみ値が指定された検索条件で検索を行った回数が格納される。例えば行が「メタデータ２」、列が「メタデータ１」の欄に表記されている「未使用」は、回数が格納されないことを表している。これは、２種類のメタデータ名の組み合わせで各値が指定された検索条件での検索では、辞書に登録された順序で２種類のメタデータ名の組み合わせを特定し、特定した組み合わせのみで回数を計数するからである。

図３（ａ）〜図３（ｃ）は、統計情報の更新例を説明する図である。図３（ａ）〜図３（ｃ）に表す例は、メタデータ１として「名前」、メタデータ２として「年齢」をそれぞれ想定した場合の例である。図３（ｂ）は、図３（ａ）の状態の統計情報３７ａから１回の検索を行った後の状態、図３（ｃ）は、図３（ｂ）の状態の統計情報３７ａから１回の検索を行った後の状態、をそれぞれ表している。

図３（ａ）に表す状態は、統計情報３７ａがクリアされた状態で、例えば「名前＝田中 ＡＮＤ 年齢＝２０」のような２種類のメタデータ名の値が指定された検索条件による検索を行った後の状態である。その検索条件では、１種類のメタデータ名として「名前」及び「年齢」が指定され、２種類のメタデータ名の組み合わせが「名前」及び「年齢」である。そのため、行、及び列が共に「名前」の欄、行、及び列が共に「年齢」の欄、並びに行が「名前」で列が「年齢」の欄の各回数は、それぞれ０から１に更新されている。

図３（ｂ）に表す状態は、統計情報３７ａが図３（ａ）に表す状態時に、例えば「名前＝山田」のような１種類のメタデータ名の値が指定された検索条件による検索を行った後の状態である。その検索条件では、行、及び列が共に「名前」の欄の回数が１から２に更新されている。

図３（ｃ）に表す状態は、統計情報３７ａが図３（ｂ）に表す状態時に、例えば「名前＝上田 ＡＮＤ 年齢＜３０」のような２種類のメタデータ名の値が指定された検索条件による検索を行った後の状態である。その検索条件により、行、及び列が共に「名前」の欄では回数が２から３に更新されている。行、及び列が共に「年齢」の欄では回数が１から２に更新されている。行が「名前」で列が「年齢」の欄では、回数が１から２に更新されている。

本実施形態では、上記のように、１種類のメタデータ名の値（メタデータ）のみが検索条件に指定された検索、及び２種類のメタデータ名の組み合わせで各値が検索条件に指定された検索の両方で回数を計数し、各計数結果を統計情報３７ａとして保存している。３種類以上のメタデータ名の組み合わせは、２種類のメタデータ名の組み合わせに分解し、分解した組み合わせ毎に回数を計数するようにしている。この統計情報３７ａは、各ストレージ・インデックス管理サーバ３に管理させるべきメタデータ名のインデックスの決定に用いられる。

検索条件（ＡＮＤ検索）で値が指定された２種類のメタデータ名のインデックスを同じストレージ・インデックス管理サーバ３が管理している場合、そのストレージ・インデックス管理サーバ３は、その検索条件を満たすオブジェクトの保存先情報を全て抽出することができる。そのため、アンド検索の検索条件を格納した検索リクエストが送信されたアプリサーバ２は、その検索リクエストを送信したストレージ・インデックス管理サーバ３からのレスポンスにより、その検索条件を満たすオブジェクトを全て取得することができる。

１台のストレージ・インデックス管理サーバ３からのレスポンスにより、検索条件を満たすオブジェクトを全て取得できることは、ネットワーク１を介して送受信するオブジェクトの数を抑えられることを意味する。１台のストレージ・インデックス管理サーバ３は、他のストレージ・インデックス管理サーバ３との通信を行うことなく、送信すべきレスポンスを作成することができる。このようなことから、アンド検索時、検索条件で値が指定された複数のメタデータ名のインデックスを同じストレージ・インデックス管理サーバ３が管理している場合、データ送受信による遅延を最小限に抑えることが可能になる。

また、レスポンスは、ストレージ・インデックス管理サーバ３内の処理により作成されることから、ストレージ・インデックス管理サーバ３の計算リソースがより有効に活用することができる。これは、フロントエンドであるアプリサーバ２の負荷をより抑制できることを意味する。負荷の抑制により、アプリサーバ２はより迅速に検索結果としてのオブジェクトを端末装置のユーザに提示することができる。このようなことから、検索条件で値が指定された複数のメタデータ名のインデックスが同じストレージ・インデックス管理サーバ３に管理させている場合、単位時間当たりに実行可能な検索の件数はより多くなり、検索性能は事実上、向上する。

このように、アンド検索時の検索条件で値が指定される複数のメタデータ名のインデックスを同じストレージ・インデックス管理サーバ３に管理させることは、検索性能を向上させるうえで有効である。そのため、統計情報３７ａは、同じストレージ・インデックス管理サーバ３にインデックスを管理させるべきメタデータ名の組み合わせの特定に用いられる。

本実施形態では、図２に表すように、組み合わせるメタデータ名の数は２つとしている。これは、組み合わせるメタデータ名の数が多くなるほど、同じメタデータ名のインデックスを管理させるストレージ・インデックス管理サーバ３の台数も多くなり、各ストレージ・インデックス管理サーバ３に管理させるインデックスの数も多くなるからである。言い換えれば、ネットワーク１を介したデータの転送量の増大、及びストレージ・インデックス管理サーバ３における計算リソースの浪費の増大、等の影響が大きくなり易くなるためである。このことから、本実施形態では、２種類のメタデータ名の組み合わせのみに着目している。

上記検索部３５は、ネットワーク入出力部３１から渡された検索リクエストを統計情報取得部３６に渡す。統計情報取得部３６は、渡された検索リクエストから検索条件を抽出し、抽出した検索条件に該当する回数をインクリメントすることにより、統計情報３７ａを更新、つまり新しい統計情報３７ａを生成する。

インデックス管理サーバ決定部３８は、統計情報３７ａを参照し、２種類のメタデータ名の組み合わせ毎に、その２種類のメタデータ名のインデックスを管理させるべきストレージ・インデックス管理サーバ３を決定する。インデックス管理サーバ決定部３８は、その決定結果に従って、インデックスを管理させるストレージ・インデックス管理サーバ３を変更させる制御を行う。

本実施形態による管理装置は、各ストレージ・インデックス管理サーバ３に管理させるインデックスを動的に変更する制御を行う装置である。その管理装置は、インデックス管理サーバ決定部３８によって実現されている。つまり、本実施形態による管理装置は、各ストレージ・インデックス管理サーバ３に搭載させる形で実現されている。

なお、管理装置は、各アプリサーバ２に搭載させても良い。また、ネットワーク１に接続させた別の情報処理装置（コンピュータ）を管理装置として用いても良い。その別の情報処理装置は、１台であっても良く、２台以上であっても良い。

図４は、インデックスを管理させるストレージサーバ兼インデックス管理サーバの変更例を説明する図である。

図４では、便宜的に、３台のストレージ・インデックス管理サーバ３（３−１〜３−３）のみがネットワーク１と接続されているシステム構成を想定している。図４の上方に表すシステム構成は、インデックスを管理させるストレージ・インデックス管理サーバ３を変更する前の状態である。図４の下方に表すシステム構成は、インデックスを管理させるストレージ・インデックス管理サーバ３を変更した後の状態である。各システム構成において、保存されているオブジェクトとしてオブジェクトＡ〜Ｃのみを表し、インデックスとしては、メタデータ名が「名前」「年齢」の２つのみを表している。

図４の上方に表すシステム構成では、３つのオブジェクトＡ〜Ｃはそれぞれストレージ・インデックス管理サーバ３−１〜３−３に保存されている。メタデータ名が「名前」のインデックスはストレージ・インデックス管理サーバ３−１で管理され、メタデータ名が「年齢」のインデックスはストレージ・インデックス管理サーバ３−３で管理されている。各インデックスは、共に、オブジェクトＡ〜Ｃの保存先の検索に用いられる。メタデータ名が「名前」のインデックスで内容例として表記の「田中：オブジェクトＡ」等、メタデータ名が「年齢」のインデックスで内容例として表記の「２０：オブジェクトＡ」等は、そのことを表している。

図４の下方に表すシステム構成では、メタデータ名が「名前」及び「年齢」の２つのインデックスは、ストレージ・インデックス管理サーバ３−２に管理されている。それにより、ストレージ・インデックス管理サーバ３−１及び３−３は共に、管理するインデックスが存在しない状態となっている。

「名前」及び「年齢」は、検索条件でその値が同時に指定されたメタデータ名である。本実施形態では、設定された変更条件を満たす場合に、検索条件で値が同時に指定された２種類のメタデータ名のインデックスを同じストレージ・インデックス管理サーバ３に管理させるようにしている。その変更条件を設けることにより、本実施形態では、インデックスを管理させるストレージ・インデックス管理サーバ３の変更を制限している。

本実施形態では、この変更条件は、２種類のメタデータ名の値が検索条件で同時に指定される頻度に着目して設定している。より具体的には、変更条件は、閾値αを超える共起率ｒが得られることとしている。

共起率ｒは、２種類のメタデータ名の値が検索条件で同時に指定される割合のことである。２種類のメタデータ名の値のうちの一方、及び他方がそれぞれ検索条件で指定された回数をｃ_Ａ、及びｃ_Ｂ、２種類のメタデータ名の値が検索条件で同時に指定された回数をｃ_ＡＢと表す場合、共起率ｒは例えば以下の式を用いて計算される。
ｒ ＝ ｃ_ＡＢ／（ｃ_Ａ＋ｃ_Ｂ−ｃ_ＡＢ） ・・・ （１）

この共起率ｒは、以下の式を用いて計算しても良い。
ｒ ＝ ｃ_ＡＢ／Ｃ ・・・ （２）
ここで、Ｃは検索が行われた総回数である。

共起率ｒが低いことは、２種類のメタデータ名のインデックスを同じストレージ・インデックス管理サーバ３に管理させても、その２つのインデックスを対象にした検索を同時に行う頻度が小さいことを意味する。その２つのインデックスへの検索を同時に行わないのであれば、各インデックスをそれぞれ異なるストレージ・インデックス管理サーバ３に管理させることにより、２台のストレージ・インデックス管理サーバ３の計算リソースをより有効に利用することができる。このようなことから、本実施形態では、閾値αを設け、変更条件（ｒ＞αの関係）が満たされた２種類のメタデータ名のインデックスを同じストレージ・インデックス管理サーバ３に管理させるようにしている。閾値αとしては、例えば０．５の付近の値を設定することが考えられる。

インデックス管理サーバ決定部３８は、統計情報３７ａを参照して、２種類のメタデータ名の組み合わせ毎に共起率ｒを算出する。インデックス管理サーバ決定部３８は、２種類のメタデータ名の組み合わせ毎に、算出した共起率ｒからその２種類のメタデータ名のインデックスを同じストレージ・インデックス管理サーバ３に管理させるべきか否かを判定する。それにより、インデックス管理サーバ決定部３８は、算出した共起率ｒが閾値αを超えている２種類のメタデータ名のインデックスを同じストレージ・インデックス管理サーバ３に管理させる。

インデックス管理サーバ決定部３８が共起率ｒを算出する２種類のメタデータ名の組み合わせは、統計情報３７ａによってサポートされる、管理単位となる組み合わせである。統計情報３７ａを用いて回数が計数可能なメタデータ名は、自ストレージ・インデックス管理サーバ３に送信される検索リクエスト中の検索条件で値が指定されるメタデータ名に限定される。

本実施形態では、何れかのストレージ・インデックス管理サーバ３のインデックス管理サーバ決定部３８の決定結果に従い、対象となるインデックスを管理させるストレージ・インデックス管理サーバ３を直ちに変更させるようにしている。インデックスを管理させるストレージ・インデックス管理サーバ３を変更させる場合、その変更が終了するまで、検索リクエストへの適切なレスポンスが行えない可能性がある。そのため、本実施形態では、インデックス管理サーバ決定部３８は、外部からの指示により起動させ、インデックス管理サーバ決定部３８を動作させている間、検索サービスを停止させるようにしている。

インデックス管理サーバ決定部３８によって同じストレージ・インデックス管理サーバ３にインデックスを管理させるべきと判定された２種類のメタデータ名の組み合わせ結果（以降「インデックス管理情報」と表記）は、各ストレージ・インデックス管理サーバ３で共有される。そのため、インデックスを管理させるストレージ・インデックス管理サーバ３の変更は、インデックス管理情報に登録されていない組み合わせのみを対象に行われる。

図１２は、本実施形態によるストレージサーバ兼インデックス管理サーバとして使用可能な情報処理装置の構成例を表す図である。ここで、図１２を参照し、本実施形態によるストレージ・インデックス管理サーバ３として使用可能な情報処理装置例について具体的に説明する。

この情報処理装置は、図１２に表すように、ＣＰＵ（Central Processing Unit）５１、ＦＷＨ（Firm-Ware Hub）５２、メモリ（メモリモジュール）５３、ＮＩＣ（Network Interface Card）５４、ハードディスク装置（ＨＤ）５５、ファン５６、コントローラ５７、及びＢＭＣ（Baseboard Management Controller）５８を備えている。この構成は、１例であり、ストレージ・インデックス管理サーバ３として使用可能な情報処理装置の構成は、図１２に表すようなものに限定されない。

ＦＷＨ５２は、ファームウェアを格納したメモリである。このファームウェアは、ＣＰＵ５１によってメモリ５３に読み出され実行される。ハードディスク装置５５には、ＯＳ（Operating System）、及び各種アプリケーション・プログラム（以降「アプリケーション」と略記）が格納されている。アプリケーションとしては、分散オブジェクトストレージを構成するノード（ストレージ・インデックス管理サーバ３）として機能させるためのもの（以降「分散オブジェクトストレージシステム」と表記）が含まれる。ＣＰＵ５１は、ファームウェアの起動が完了した後、コントローラ５７を介してハードディスク装置５５からＯＳ、及び分散オブジェクトストレージシステムを読み出して実行することができる。ＮＩＣ５４を介した通信は、ＯＳの起動によって可能となる。

この分散オブジェクトストレージシステムは、ハードディスク装置５５以外のストレージ、或いは記録媒体に格納しても良い。ストレージ、或いは記録媒体は、ＮＩＣ５４がネットワークを介して通信可能な外部装置がアクセス可能なものであっても良い。このことから、分散オブジェクトストレージシステムは、外部装置から受信しても良い。

ＢＭＣ５８は、情報処理装置を管理するための専用の管理装置である。ＢＭＣ５８は、ＣＰＵ５１のオン／オフ、各構成要素に発生するエラーの監視、等を行う。コントローラ５６は、図１に表すディスク装置４が接続可能なインターフェースである。

上記のような構成の情報処理装置では、ネットワーク入出力部３１はＮＩＣ５４である。ディスク入出力部３４は、コントローラ５７である。記憶部３７は、例えばメモリ５３、ハードディスク装置５５、及びコントローラ５７によって実現される。データ読み書き部３２、メタデータ読み書き部３３、検索部３５、統計情報取得部３６、及びインデックス管理サーバ決定部３８は、共に、ＣＰＵ５１がＯＳ上で分散オブジェクトシステムを実行することで実現される機能である。このことから、データ読み書き部３２、メタデータ読み書き部３３、検索部３５、統計情報取得部３６、及びインデックス管理サーバ決定部３８は、共に、ＣＰＵ５１、ＦＷＨ５２、メモリ５３、ハードディスク装置５５、及びコントローラ５７によって実現される。

上記分散オブジェクトストレージシステムは、ＣＰＵ５１に各種処理を実行させる。以降、図５〜図１０に表す各種フローチャートを参照し、分散オブジェクトストレージシステムを実行することによるＣＰＵ５１の動作について詳細に説明する。

図５は、統計情報更新処理のフローチャートである。この統計情報更新処理は、何れかのアプリサーバ２から検索を要求する検索リクエストをＮＩＣ５４が受信することを契機に実行される処理であり、統計情報取得部３６の機能の一部を実現させる。更新情報３７ａは、この統計情報更新処理の実行により、受信された検索リクエスト中の検索条件で値が指定されたメタデータ名に応じて更新される。始めに図５を参照し、統計情報更新処理について詳細に説明する。

先ず、ＣＰＵ５１は、検索リクエスト中の検索条件で値が指定されたメタデータ名毎に、その回数を更新するための第１の計数処理を実行する（Ｓ１）。その第１の計数処理の実行後、ＣＰＵ５１は、検索条件（図５中「検索式」と表記）に２種類以上のメタデータ名の値（メタデータ）が含まれているか否か判定する（Ｓ２）。検索条件で値が指定されたメタデータ名が２種類以上であった場合、Ｓ２の判定はｙｅｓとなってＳ５に移行する。検索条件で値が指定されたメタデータ名が１種類であった場合、Ｓ２の判定はｎｏとなり、ここで統計情報更新処理が終了する。

Ｓ５は処理ループであり、この処理ループＳ５内では、ＣＰＵ５１は、検索リクエスト中の検索条件で値が指定された２種類のメタデータ名の組み合わせ毎に、その回数を更新するための第２の計数処理を実行する（Ｓ６）。２種類のメタデータ名の組み合わせの全てで回数を更新した場合、処理ループＳ５が終了し、統計情報更新処理も終了する。

図６は、上記第１の計数処理のフローチャートであり、図７は、上記第２の計数処理のフローチャートである。ここで、図６、及び図７を参照し、上記統計情報更新処理内でＳ１、及びＳ６として実行される各サブルーチン処理について詳細に説明する。

Ｓ１として実行される第１の計数処理では、図６に表すように、検索リクエスト中の検索条件で値が指定されたメタデータ名毎に、その回数を更新するための処理ループＳ１０が実行される。その処理ループＳ１０では、先ず、ＣＰＵ５１は、検索条件で値が指定されたメタデータ名を取得する（Ｓ１１）。次に、ＣＰＵ５１は、取得したメタデータ名に対応する回数を統計情報３７ａから抽出する（Ｓ１２）。図６では、統計情報３７ａを「表」、回数を「行列」とそれぞれ表記している。

回数を抽出した後、ＣＰＵ５１は、その回数をインクリメントする（Ｓ１３）。その回数のインクリメントにより、１メタデータ名に対する一連の処理が終了する。検索条件で値が指定された全てのメタデータ名を対象にしていた場合、一連の処理の終了後、処理ループＳ１０が終了し、更に第１の計数処理が終了する。

Ｓ６として実行される第２の計数処理では、図７に表すように、先ず、ＣＰＵ５１は、検索条件で値が指定された２種類のメタデータ名を取得する（Ｓ２１）。次に、ＣＰＵ５１は、取得した２種類のメタデータ名を辞書順に比較し、辞書順で小さい方、つまり前の方を第１のメタデータ名、残りを第２のメタデータ名とする（Ｓ２２）。

続いてＣＰＵ５１は、第１及び第２のメタデータ名の組み合わせに対応する回数を統計情報３７ａ中から抽出する（Ｓ２３）。その回数とは、図２において、第１のメタデータ名を行、第２のメタデータ名を列とする欄に格納されている回数である。回数を抽出した後、ＣＰＵ５１は、その回数をインクリメントする（Ｓ２４）。その回数のインクリメントを行った後、第２の計数処理が終了する。

上記第１及び第２の計数処理が統計情報更新処理内で実行されることにより、検索リクエストが受信される度に、図３に例を表すように統計情報３７ａが更新される。

なお、本実施形態では、統計情報３７ａ中からの２種類のメタデータ名の組み合わせに対応する回数の抽出を、メタデータ名が辞書に出現する順序の組で特定するようにしているが、回数の抽出は別の方法で行えるようにしても良い。具体的には、例えば統計情報３７ａは、ハッシュ値と回数を含む組の集合体としても良い。統計情報３７ａがハッシュ値と回数を含む組の集合体であった場合、第２の計数処理は、図８にフローチャートを表すような内容としても良い。

図８にフローチャートを表す第２の計数処理では、先ず、ＣＰＵ５１は、検索条件で値が指定された２種類のメタデータ名を取得する（Ｓ３１）。次に、ＣＰＵ５１は、取得した２種類のメタデータ名を辞書順に比較し、辞書順で小さい方を第１のメタデータ名、残りを第２のメタデータ名とし、第１のメタデータ名、第２のメタデータ名の順に並べて結合したものを最終的なメタデータ名とする（Ｓ３２）。

続いてＣＰＵ５１は、最終的なメタデータ名を用いてハッシュ値を計算し、計算したハッシュ値を用いた統計情報３７ａの検索により、対応する回数を抽出する（Ｓ３３）。回数を抽出した後、ＣＰＵ５１は、その回数をインクリメントする（Ｓ３４）。その回数のインクリメントを行った後、変形例の第２の計数処理が終了する。

図９は、インデックス管理サーバ決定処理のフローチャートである。このインデックス管理サーバ決定処理では、同じストレージ・インデックス管理サーバ３にインデックスを管理させるべき２種類のメタデータ名の特定が行われる。また、このインデックス管理鯖決定処理では、特定した２種類のメタデータ名のインデックスを管理させるべきストレージ・インデックス管理サーバ３に保存させるための処理が行われる。インデックス管理サーバ決定部３８は、このインデックス管理サーバ決定処理をＣＰＵ５１が実行することで実現される。このインデックス管理サーバ決定処理は、外部、例えば何れかのアプリサーバ２からインデックスの管理を要求するリクエストの受信によって実行される。そのリクエストは、例えば情報処理システムを管理する管理者の指示、或いは設定によって送信される。

このインデックス管理サーバ決定処理では、２つの処理ループＳ４０、及びＳ５０がその順序で実行される。処理ループＳ４０は、２種類のメタデータ名の組み合わせ毎に、その２つのインデックスを管理させるべきストレージ・インデックス管理サーバ３に管理させるための処理ループである。処理ループＳ５０は、１種類のメタデータ名毎に、そのインデックスを管理させるべきストレージ・インデックス管理サーバ３に管理させるための処理ループである。

各ストレージ・インデックス管理サーバ３で回数の計数が可能なのは、そのストレージ・インデックス管理サーバ３が受信する検索リクエスト中の検索条件で値が指定されている１種類のメタデータ名、及び２種類のメタデータ名の組み合わせである。各アプリサーバ２は、通常、端末装置のユーザが値を指定したメタデータ名から、検索リクエストを送信すべきストレージ・インデックス管理サーバ３を特定し、特定したストレージ・インデックス管理サーバ３宛に検索リクエストを送信する。このことから、本実施形態では、各ストレージ・インデックス管理サーバ３で対象にさせるメタデータ名、及び２種類のメタデータ名の組み合わせは、検索条件で指定されたことのあるもの、つまり回数が１以上のものとしている。

処理ループＳ４０では、先ず、ＣＰＵ５１は、統計情報３７ａを参照して、回数が１以上の２種類のメタデータ名の組み合わせの１つを抽出し、抽出した組み合わせの共起率ｒを計算して、計算した共起率ｒが閾値αより大きいか否か判定する（Ｓ４１）。その組み合わせが同時に指定された検索が頻繁に要求されているような場合、Ｓ４１の判定はｙｅｓとなってＳ４２に移行する。その組み合わせが同時に指定された検索が頻繁に要求されていない場合、Ｓ４１の判定はｎｏとなり、処理ループＳ４０内の一連の処理が終了する。その結果、処理ループＳ４０では、回数が１以上の２種類のメタデータ名の組み合わせのなかで抽出していないものが有るか否かの判定が行われる。抽出対象となる組み合わせが存在しない場合、処理ループＳ４０が終了し、抽出対象となる組み合わせが残っている場合、Ｓ４１が再度、実行されることとなる。

Ｓ４１の判定処理には、実際には、上記インデックス管理情報が用いられる。そのインデックス管理情報には、例えばＳ４１の判定が初めてｙｅｓとなった２種類のメタデータ名の組み合わせが登録される。それにより、インデックス管理情報に既に登録されている組み合わせは、共起率ｒの値に係わらず、Ｓ４１でｎｏと判定される。

Ｓ４２では、ＣＰＵ５１は、抽出した２種類のメタデータ名を辞書順に比較し、辞書順で小さい方を第１のメタデータ名、残りを第２のメタデータ名とし、第１のメタデータ名、第２のメタデータ名の順に並べて結合する。次にＣＰＵ５１は、２種類のメタデータ名のインデックスを管理させるストレージ・インデックス管理サーバ３を決定し、決定したストレージ・インデックス管理サーバ３にその２つのインデックスを移動させるサーバ決定処理を実行する（Ｓ４３）。そのサーバ決定処理を実行した後、処理ループＳ４０内の一連の処理が終了する。Ｓ４２で結合したメタデータ名は、２つのインデックスを管理させるストレージ・インデックス管理サーバ３の決定に用いられる。

図１０は、サーバ決定処理のフローチャートである。ここで図１０を参照し、上記Ｓ４３、及び後述するＳ５１で実行されるサーバ決定処理について詳細に説明する。インデックス管理サーバ決定処理は、このサーバ決定処理に対し、メタデータ名を引数として渡す。インデックスを管理させるストレージ・インデックス管理サーバ３の決定には、図１１に表すようなサーバ一覧表が用いられる。

このサーバ一覧表は、例えば各アプリサーバ２、及び各ストレージ・インデックス管理サーバ３が保持する共有情報である。図１１に表すように、サーバ一覧表には、ストレージ・インデックス管理サーバ３毎に、そのストレージ・インデックス管理サーバ３に割り当てられたハッシュ値の範囲が定義されている。それにより、インデックス管理サーバ決定処理から渡されるメタデータ名は、ハッシュ値の計算に用いられる。

先ず、ＣＰＵ５１は、インデックス管理サーバ決定処理から渡されたメタデータ名を用いてハッシュ値を計算する（Ｓ６１）。次に、ＣＰＵ５１は、計算したハッシュ値を用いて、インデックスを管理させるストレージ・インデックス管理サーバ３を決定し、決定したストレージ・インデックス管理サーバ３にインデックスを移動させるための処理ループＳ７０を実行する。

この処理ループＳ７０では、先ず、ＣＰＵ５１は、サーバ一覧表中で対象とする１台のストレージ・インデックス管理サーバ３を選択し、計算したハッシュ値が、選択したストレージ・インデックス管理サーバ３に割り当てられたハッシュ値の範囲内か否か判定する（Ｓ７１）。計算したハッシュ値がその範囲内であった場合、Ｓ７１の判定はｙｅｓとなってＳ７２に移行する。計算したハッシュ値がその範囲外であった場合、Ｓ７１の判定はｎｏとなり、ここで処理ループＳ７０内の一連の処理が終了する。このとき、選択の対象となるストレージ・インデックス管理サーバ３が存在しない場合、処理ループＳ７０が終了し、その後にサーバ決定処理が終了する。

Ｓ７２では、ＣＰＵ５１は、渡されたメタデータ名から特定されるインデックスを、現在、選択しているストレージ・インデックス管理サーバ３に移動させる処理を行う。その処理の実行後、処理ループＳ７０内の一連の処理が終了する。

インデックス管理サーバ決定処理から渡されたメタデータ名は、１種類のメタデータ名か、或いは２種類のメタデータ名の結合体である。そのため、移動の対象となるインデックスは渡されたメタデータ名から特定することができる。

移動対象となるインデックスを管理しているストレージ・インデックス管理サーバ３は、サーバ一覧表から特定される。そのストレージ・インデックス管理サーバ３は、移動対象となるインデックスのメタデータ名を用いて計算されるハッシュ値が、割り当てられたハッシュ値の範囲内となっているストレージ・インデックス管理サーバ３である。それにより、ＣＰＵ５１は、移動対象となるインデックスを管理しているストレージ・インデックス管理サーバ３（以降「移動元サーバ３」と表記）が、計算したハッシュ値を範囲内とするストレージ・インデックス管理サーバ３（以降「移動先サーバ３」と表記）と異なる場合、インデックスを移動させなければならない。そのため、ＣＰＵ５１は、例えば移動元サーバ３に対し、移動先サーバ３、及び移動対象とするインデックスのメタデータ名等を送信して、移動対象とするインデックスの移動先サーバ３への送信を指示する。そのようにして、移動先サーバ３に、移動元サーバ３から送信されるインデックスを保存させる。

移動先サーバ３では、インデックスが増えたことにより、それまで送信されなかった検索リクエストがアプリサーバ３から送信される可能性が生じる。そのため、移動先サーバ３では、統計情報３７ａをクリアしている。

図９のインデックス管理サーバ決定処理の説明に戻る。
処理ループＳ４０の終了により、処理ループＳ５０が実行される。処理ループＳ４０の実行により、同じストレージ・インデックス管理サーバ３に管理させるべき２種類のメタデータ名のインデックスは、管理させるべきストレージ・インデックス管理サーバ３に管理される。そのため、処理ループＳ５０でインデックスを移動させる可能性のあるメタデータ名は、インデックス管理情報に登録されていないメタデータ名のみとなる。

その処理ループＳ５０では、先ず、ＣＰＵ５１は、統計情報３７ａを参照して、回数が１以上の１種類のメタデータ名を抽出し、抽出したメタデータ名がインデックス管理情報に登録されていないか否か判定する（Ｓ５１）。抽出したメタデータ名がインデックス管理情報に登録されていない場合、Ｓ５１の判定はｙｅｓとなってＳ５２のサーバ決定処理に移行する。このとき、抽出したメタデータ名は引数としてサーバ決定処理に渡される。抽出したメタデータ名がインデックス管理情報に登録されている場合、Ｓ５１の判定はｎｏとなり、ここで処理ループＳ５０内の一連の処理が終了する。

この一連の処理の終了時、抽出の対象となるメタデータ名が存在しない場合、処理ループＳ５０が終了し、その後にインデックス管理サーバ決定処理が終了する。

１種類のメタデータ名のインデックスは、何れかのストレージ・インデックス管理サーバ３に保存させた後には、サーバ一覧表が更新されたといった特別の理由がない限り、移動させる必要はない。そのため、処理ループＳ５０は、通常、実行されない。しかし、ここでは、１種類のメタデータ名のインデックスが最初に保存されるストレージ・インデックス管理サーバ３を明確にするために、処理ループＳ５０を処理ループＳ４０と共にフローチャートに表している。各アプリサーバ２は、図１１に表すようなサーバ一連表、及びインデックス管理情報を参照することにより、検索リクエストを送信すべきストレージ・インデックス管理サーバ３を特定することができる。

なお、本実施形態では、２種類のメタデータ名のインデックスを同じストレージ・インデックス管理サーバ３に管理させるか否かの判定に共起率ｒを用いている。その判定には別の指標を用いても良い。或いは別の指標と組み合わせて用いても良い。例えばストレージ・インデックス管理サーバ３全体の負荷の重さと、検索時に同時に指定される２種類以上のメタデータ名との間にパターンが観測される場合、そのパターンをインデックスの管理に反映させても良い。共起率ｒの代わりの指標としては、例えば単位時間当たりの検索件数、が考えられる。共起率ｒの代わりの指標、或いは／及び、組み合わせが可能な別の指標としては、オブジェクト、或いはインデックスのデータ量、１件の検索に要する平均処理時間、１件の検索の平均的な負荷の重さ、等が考えられる。

共起率ｒは、サンプル数が少ない状況では、大きく変化し易い。サンプル数が少ない状況時に、共起率ｒが閾値αより大きくなって、実際には不要な２つのインデックスを同じストレージ・インデックス管理サーバ３に管理させることが有り得る。このことから、共起率ｒを計算する対象を制限するための条件を設けても良い。或いはインデックス管理情報に登録された２種類のメタデータ名の組み合わせのなかで、別のストレージ・インデックス管理サーバ３に管理させるべき組み合わせを特定し、インデックスの移動を行うようにしても良い。インデックスの移動の対象とする組み合わせは、閾値αより小さい別の閾値βを設定し、ｒ＜βの関係を満たすことを条件に、特定させることが考えられる。

また、本実施形態では、各ストレージ・インデックス管理サーバ３は、統計情報３７ａの生成・更新、及びインデックスを管理させるストレージ・インデックス管理サーバ３の決定を行えるようになっている。統計情報３７ａの生成・更新、及びインデックスを管理させるストレージ・インデックス管理サーバ３の決定は、それぞれ別の装置に行わせても良い。このことから、管理装置は、複数台の情報処理装置（コンピュータ）を用いて実現させても良い。

インデックスを移動させるストレージ・インデックス管理サーバ３は、各ストレージ・インデックス管理サーバ３の負荷の重さに着目して決定しても良い。また、インデックスの移動対象とさせるストレージ・インデックス管理サーバ３の優先順位を設定し、設定された優先順位に従って、インデックスを移動させるストレージ・インデックス管理サーバ３を決定するようにしても良い。
上記以外にも、様々な変形を行うことができる。

以上の変形例を含む実施形態に関し、更に以下の付記を開示する。
（付記１）
ネットワークを介して第１の情報処理装置と接続された複数台の第２の情報処理装置、及び管理装置を備え、
前記複数台の第２の情報処理装置は、
データ、及び前記データのメタデータを用いて検索用に構築されたインデックスを分散して管理し、
前記管理装置は、
前記第１の情報処理装置から送信された検索リクエストを監視する監視部と、
前記監視部による監視結果を基に、同一の第２の情報処理装置に前記インデックスを管理させるべき前記メタデータの種類の組み合わせ、及び前記同一の第２の情報処理装置を特定し、該特定した前記同一の第２の情報処理装置に、該特定した前記組み合わせのメタデータの種類のインデックスを管理させるインデックス管理部と、を有する、
ことを特徴とする情報処理システム。
（付記２）
前記監視部が監視した前記検索リクエストで指定されているメタデータの種類の組み合わせ毎に、前記組み合わせでメタデータが同時に指定された結果を表す統計情報を生成する情報生成部、を有し、
前記インデックス管理部は、前記統計情報を基に、前記同一の第２の情報処理装置に前記インデックスを管理させるべき前記メタデータの種類の組み合わせを特定する、
ことを特徴とする付記１記載の情報処理システム。
（付記３）
前記情報生成部は、２種類のメタデータの組み合わせ毎に、前記２種類のメタデータが同時に指定された回数を計数して、前記統計情報を生成・更新し、
前記インデックス管理部は、前記２種類のメタデータのインデックスを管理単位として、前記同一の第２の情報処理装置に前記インデックスを管理させるべきか否かの判定を行う、
ことを特徴とする付記２記載の情報処理システム。
（付記４）
ネットワークを介して第１の情報処理装置と接続され、データ、及び前記データのメタデータを用いて検索用に構築されたインデックスを分散して管理する複数台の第２の情報処理装置に対し、前記第１の情報処理装置から送信された検索リクエストを監視する監視部と、
前記監視部による監視結果を基に、同一の第２の情報処理装置に前記インデックスを管理させるべき前記メタデータの種類の組み合わせ、及び前記同一の第２の情報処理装置を特定し、該特定した前記同一の第２の情報処理装置に、該特定した前記組み合わせのメタデータの種類のインデックスを管理させるインデックス管理部と、
を有することを特徴とする管理装置。
（付記５）
ネットワークと接続されたコンピュータに、
データ、及び前記データのメタデータを用いて検索用に構築されたインデックスを分散して管理する複数台の第２の情報処理装置に対し、前記ネットワークを介して第１の情報処理装置から送信された検索リクエストの監視を行い、
前記監視の結果を基に、同一の第２の情報処理装置に前記インデックスを管理させるべき前記メタデータの種類の組み合わせ、及び前記同一の第２の情報処理装置を特定し、該特定した前記同一の第２の情報処理装置に、該特定した前記組み合わせのメタデータの種類のインデックスを管理させる、
処理を実行させる管理プログラム。
（付記６）
ネットワークと接続されたコンピュータを用いて、
データ、及び前記データのメタデータを用いて検索用に構築されたインデックスを分散して管理する複数台の第２の情報処理装置に対し、前記ネットワークを介して第１の情報処理装置から送信された検索リクエストの監視を行い、
前記監視の結果を基に、同一の第２の情報処理装置に前記インデックスを管理させるべき前記メタデータの種類の組み合わせ、及び前記同一の第２の情報処理装置を特定し、該特定した前記同一の第２の情報処理装置に、該特定した前記組み合わせのメタデータの種類のインデックスを管理させる、
ことを特徴とするインデックス管理方法。

１ ネットワーク
２ アプリケーションサーバ（アプリサーバ）
３ ストレージサーバ兼インデックス管理サーバ（ストレージ・インデックス管理サーバ）
４ ディスク装置
３１ ネットワーク入出力部
３２ データ読み書き部
３３ メタデータ読み書き部
３４ ディスク入出力部
３５ 検索部
３６ 統計情報取得部
３７ 記憶部
３７ａ 統計情報
３８ インデックス管理サーバ決定部

Claims (5)

1. ネットワークを介して第１の情報処理装置と接続された複数台の第２の情報処理装置、及び管理装置を備え、
   前記複数台の第２の情報処理装置は、
   データ、及び前記データのメタデータを用いて検索用に構築されたインデックスを分散して管理し、
   前記管理装置は、
   前記第１の情報処理装置から送信された検索リクエストを監視する監視部と、
   同一の第２の情報処理装置に前記インデックスを管理させるべき前記メタデータの種類の組み合わせを、前記検索リクエストに含まれる検索条件における前記メタデータの種類の組み合わせについての共起率に基づいて特定すると共に、該特定した前記組み合わせのメタデータの種類に基づいて前記同一の第２の情報処理装置を特定し、該特定した前記同一の第２の情報処理装置に、該特定した前記組み合わせのメタデータの種類のインデックスを管理させるインデックス管理部と、を有する、
   ことを特徴とする情報処理システム。
2. 前記監視部が監視した前記検索リクエストで指定されているメタデータの種類の組み合わせ毎に、前記組み合わせでメタデータが同時に指定された結果を表す統計情報を生成する情報生成部、を有し、
   前記インデックス管理部は、前記統計情報を基に、前記同一の第２の情報処理装置に前記インデックスを管理させるべき前記メタデータの種類の組み合わせを特定する、
   ことを特徴とする請求項１記載の情報処理システム。
3. 前記情報生成部は、２種類のメタデータの組み合わせ毎に、前記２種類のメタデータが同時に指定された回数を計数して、前記統計情報を生成・更新し、
   前記インデックス管理部は、前記２種類のメタデータのインデックスを管理単位として、前記同一の第２の情報処理装置に前記インデックスを管理させるべきか否かの判定を行う、
   ことを特徴とする請求項２記載の情報処理システム。
4. ネットワークと接続されたコンピュータに、
   データ、及び前記データのメタデータを用いて検索用に構築されたインデックスを分散して管理する複数台の第２の情報処理装置に対し、前記ネットワークを介して第１の情報処理装置から送信された検索リクエストの監視を行い、
   同一の第２の情報処理装置に前記インデックスを管理させるべき前記メタデータの種類の組み合わせを、前記検索リクエストに含まれる検索条件における前記メタデータの種類の組み合わせについての共起率に基づいて特定すると共に、該特定した前記組み合わせのメタデータの種類に基づいて前記同一の第２の情報処理装置を特定し、該特定した前記同一の第２の情報処理装置に、該特定した前記組み合わせのメタデータの種類のインデックスを管理させる、
   処理を実行させる管理プログラム。
5. ネットワークと接続されたコンピュータが、
   データ、及び前記データのメタデータを用いて検索用に構築されたインデックスを分散して管理する複数台の第２の情報処理装置に対し、前記ネットワークを介して第１の情報処理装置から送信された検索リクエストの監視を行い、
   同一の第２の情報処理装置に前記インデックスを管理させるべき前記メタデータの種類の組み合わせを、前記検索リクエストに含まれる検索条件における前記メタデータの種類の組み合わせについての共起率に基づいて特定すると共に、該特定した前記組み合わせのメタデータの種類に基づいて前記同一の第２の情報処理装置を特定し、該特定した前記同一の第２の情報処理装置に、該特定した前記組み合わせのメタデータの種類のインデックスを管理させる、
   ことを特徴とするインデックス管理方法。

Images