以下に添付図面を参照して、この発明にかかる分散データベースから情報を検索するシステム、装置、および方法の最良な実施の形態を詳細に説明する。
本実施の形態にかかる検索システムは、分散データベースの検索過程で得られたシーケンスが物理DBの1つに局所的に格納されているか、および検索結果として出力されるかを判定し、いずれかを満たす場合に、論理シーケンスを構成する処理を不要とするように検索プランを最適化するものである。
まず、分散データベースの検索処理で扱われるシーケンスの表現形式について図1から図4を用いて説明する。図1は、本実施の形態の検索システムの構成の一例を示す説明図である。図1に示すように、検索システムは、クライアント300と、マスタノード100と、複数のスレーブノードとを含んでいる。
クライアント300は、スレーブノードに格納された情報の検索要求をマスタノード100に送信するものであり、通常のPC(Personal Computer)などにより構成される。
マスタノード100は、クライアント300の検索要求を受け付けて、スレーブノードから情報を検索する検索装置である。マスタノード100の詳細については後述する。
スレーブノードは、データを水平分割して記憶するデータベースを分散して管理し、マスタノード100からの要求に応じてデータ検索を行い、検索結果をマスタノード100に返信する情報管理装置である。図1では、5つのスレーブノードの各物理DBによって、1つの論理DB41が構成された例が示されているが、論理DBの構成はこれに限られるものではない。また、複数の論理DBを備えるように検索システムを構成してもよい。
なお、マスタノード100と、スレーブノードと、クライアント300とを接続するネットワークは、インターネットやVPNなどのあらゆるネットワーク形態により構成することができる。
図2は、入力される検索式の一例を示す説明図である。図2の検索式は、XQueryの形式で記載された検索要求を表している。なお、同図の検索式は、図1の論理DB41はユーザ情報を格納したデータベース「people」であること、および、論理DB41の他に、図1に図示していないオークションに関する情報を格納した論理DB「auctions」が存在することを前提としている。
図3は、図2のような検索式により検索処理を行ったときに得られるシーケンスの表現形式の一例を示す説明図である。図3では、物理DB−1、物理DB−2、物理DB−3には、それぞれa1n、a2n、a3n(nは整数)で識別されるユーザのデータ(person)が格納されていることが示されている。
このような構成では、論理DBに対しては1つのシーケンスで表される中間結果が、複数の物理DBに散在する部分シーケンスそれぞれに対応する場合が発生しうる。例えば、同図では、シーケンスID=s1に対応するシーケンスである「a11、a15、a21、a32」は、物理DB−1のシーケンス「a11、a15」(シーケンスID=s11)、物理DB−2のシーケンス「a21」(シーケンスID=s21)、および物理DB−3のシーケンス「a32」(シーケンスID=s31)を統合したものであることが示されている。
このような場合、通常は、散在するシーケンスを1つの論理シーケンスとして扱うための管理情報(以下、論理シーケンス管理情報という。)を生成する必要がある。図4は、論理シーケンスを扱うための論理シーケンス管理情報の一例を示す説明図である。図4では、各物理DBでのシーケンスIDと論理シーケンスIDとを対応づけた論理シーケンス管理情報の例が示されている。このような論理シーケンス管理情報により、例えば、シーケンスID=s11、s21、s31に対応するシーケンスは独立して扱わずに、シーケンスID=s1で識別される1つのシーケンスとして扱うことを指定できる。
このように、分散データベースに対して、検索結果からリスト状のデータ構造(シーケンス)を構成するような検索条件を処理させる場合、一般的には、分散データベースを構成する各スレーブノード上に断片的な結果が散在して得られる。このような場合、散在する結果のリスト状データのうち、論理的には一体となるリスト状データ同士からなる組合せ情報を管理し、論理的なリスト状データを構成して処理する必要がある。
しかし、このような取り扱いを回避可能な状況も存在する。そこで、本実施の形態では、与えられた検索条件とスキーマ情報とDB分割情報とから上記のような取り扱いの要否を判定し、検索プランの最適化を行う。これにより分散データベース環境で、検索結果データがリスト状のデータ構造をもつ場合の処理オーバヘッドを回避することが可能となる。
次に、マスタノード100とスレーブノードの詳細な構成について図5〜図14を用いて説明する。図5は、本実施の形態の検索システムの別の構成例を示す説明図である。図5以降では、それぞれ2つの物理DBから構成される2つの論理DB「auctions」および「people」を含む検索システムを例として説明する。なお、DBの構成はこれに限られず、3つ以上の物理DBを含むように論理DBを構成してもよい。また、3つ以上の論理DBを含むように検索システムを構成してもよい。
図5に示すように、本実施の形態の検索システムは、クライアント300と、マスタノード100と、複数のスレーブノード200a、200b、200c、200dとを含んでいる。マスタノード100、およびクライアント300の構成は図1と同様であるので同一の符号を付し、説明は省略する。なお、スレーブノード200a、200b、200c、200dは、物理DB内に記憶する情報が異なる以外は同一の構成を有するため、以下では単にスレーブノード200という場合がある。
図6および図7は、それぞれ論理DB「people」および「auctions」に格納される情報のデータ形式の一例を示す説明図である。図6および図7に示すように、以下ではXML形式で情報が格納されていることを前提とする。
XML形式の情報(XMLデータ)はタグや属性をノードとする木構造として表現できる。図8および図9は、木構造で表したXMLデータの一例を示す説明図である。図8は、「people」データベースに格納される「person」データを表している。また、図9は、「auctions」データベースに格納される「deal」データを表している。
データベース中では各データの木構造の各ノードにはそれぞれノードIDが割り当てて管理される。木のルートである「person」タグを示すノードにはノードIDとして900が割り当てられている。このノードIDは「people」データベース中でユニークであり、複数の「person」データが格納されている場合でも、このノードIDを指定することにより、「person」データを一意に特定することができる。
また、図8に示すように、「/person/watch/@category」属性(「person」タグの直下の子ノードである「watch」タグの直下に存在する「category」属性)は、同図の「person」データ中に2つ存在する。このような場合にも、各ノードに割り当てられているノードIDにより、それぞれを特定することができる。XMLデータの検索は、このように格納されているデータに関して、条件に合致するタグや属性といったノードのノードIDを取得する処理を行う一連のオペレータ列の処理を実行することで実現する。なお、オペレータとは、検索結果を求める過程で実行される処理の単位をいう。
図10は、本実施の形態のマスタノード100およびスレーブノード200の詳細な構成を示すブロック図である。図10に示すように、マスタノード100は、記憶部120と、検索要求受付部101と、プラン生成部102と、判定部103と、更新部104と、実行要求部105と、転送要求部106と、構成管理部107と、中間結果管理部108と、結果取得部109と、を備えている。
記憶部120は、検索処理で参照する各種テーブルを格納するものである。具体的には、記憶部120は、スキーマテーブル121と、分割情報テーブル122と、局所性判定表123と、作成判定表124とを格納している。
スキーマテーブル121は、スレーブノード200の物理DB220(後述)に格納する情報のデータ構造を定めたスキーマ情報を格納するものである。図11および図12は、スキーマテーブル121に格納されるスキーマ情報のデータ構造の一例を示す説明図である。図11および図12に示すように、スキーマテーブル121は、物理DB220に格納する情報に含まれる項目と、データ型と、一意性情報とを対応づけて格納している。
データ型には、例えば、ID型、文字列型、非負整数型、正整数型などのように、項目が取りうる値の形式を定める情報が設定される。一意性情報には、項目が論理データベース内で一意の値を取るか否かを表す情報が設定される。具体的には、一意の値を取る場合に「ユニーク型」が、それ以外の場合に「非ユニーク型」が設定される。
なお、図11および図12は、それぞれ「people」データベースおよび「auctions」データベースに格納される情報のスキーマ情報を表している。
図10に戻り、分割情報テーブル122は、格納する物理DB220を判定するための分割基準を規定する分割情報を格納するものである。図13および図14は、分割情報のデータ構造の一例を示す説明図である。図13および図14は、それぞれ「people」データベースおよび「auctions」データベースについての分割情報を表している。
例えば、図13では、「people」データベースには、ユニーク型の項目「/person/@id」の値が所定の閾値より大きいか否かによって格納する物理DB220を判定する分割基準が定められている。同様に、図14では、「auctions」データベースには、ユニーク型の項目「/deal/@id」の値が所定の閾値より大きいか否かによって格納する物理DB220を判定する分割基準が定められている。
なお、スレーブノードIDとは、情報の格納先となるスレーブノード200を識別する情報である。以下では、スレーブノード200a、200b、200c、200dのスレーブノードIDは、それぞれ1、2、3、4であるものとする。
局所性判定表123は、検索処理の過程で得られたシーケンスが、複数の物理DB220に分散して格納されているか否かを表す局所性情報を判定する規則を格納するものである。また、作成判定表124は、論理シーケンス管理情報を作成するか否かを判定する規則を格納するものである。
局所性判定表123および作成判定表124は、後述する判定部103が論理シーケンス管理情報を作成するか否かを判定するときに参照するものであるため、各表の詳細は判定部103の機能と合わせて説明する。
なお、記憶部120は、HDD(Hard Disk Drive)、光ディスク、メモリカード、RAM(Random Access Memory)などの一般的に利用されているあらゆる記憶媒体により構成することができる。
図10に戻り、検索要求受付部101は、クライアント300から送信された検索要求を受付けるものである。本実施の形態では、検索要求受付部101は、XQueryによる検索式を検索要求として受付ける。
図15は、XQueryによる検索式の一例を示す説明図である。図15の検索式は、商品カテゴリ番号が「12345」である商品(item)に関するオークションデータ(deal)を取り出し、そのオークション商品の関連商品カテゴリ(related/@category)に興味のあるユーザのID(@id)を、その関連商品カテゴリごとにひとまとめにして取り出し、さらに、そのユーザが商品を購入したオークションデータ(deal)を出力することを表している。
プラン生成部102は、検索要求受付部101が受付けた検索式、および分割情報テーブル122を参照して、検索処理の実行計画である検索プランを生成するものである。具体的には、プラン生成部102は、オペレータ、各オペレータ間のデータの受け渡し依存関係、およびオペレータを実行するスレーブノード200の割り当てを示す検索プランを生成する。
図16は、プラン生成部102が生成する検索プランの一例を示した説明図である。図16は、図15に示すような検索式に対応して生成される検索プランの例を表している。この時点では、論理シーケンス管理情報の作成が不要であるか否かを判定していないため、論理シーケンス管理情報を登録する「registSequence」オペレータが2つ含まれている。
なお、「createTable」などは各オペレータの名称を表している。また、例えばオペレータ名の後の「Slave1」は、スレーブノードID=1のスレーブノード200で実行されるオペレータであることを表している。また、「BT0」などは中間結果を識別する中間結果IDを表している。そして、記号「->」は、オペレータの実行結果が記号の右側の中間結果IDで識別される中間結果として出力されることを表している。
判定部103は、局所性判定表123および作成判定表124を参照し、論理シーケンス管理情報を作成するか否かを判定するものである。判定部103による判定処理では、局所性情報および用途情報が利用される。
局所性情報とは、上述のように、シーケンスが、複数の物理DB220に分散して格納されているかを表す情報である。言い換えると、局所性情報は、あるスレーブノード200で得られたシーケンスが他のスレーブノード200上で得られたシーケンスとともに論理シーケンスとして結合されるか否か示す情報である。用途情報とは、検索処理中に得られたシーケンスを一体の論理シーケンスとして参照する必要があるか否かを示す情報である。
まず、局所性情報の求め方について説明する。判定部103は、局所性判定表123を参照することにより局所性情報を判定する。まず、判定部103は、得られたシーケンスのデータ属性と条件値タイプを取得する。
データ属性とは、シーケンスとして得られた項目の属性を表すものである。データ属性には、項目の一意性情報(ユニーク型か、非ユニーク型か)、および項目が物理DB220に分散して格納するときの判断基準として参照されるか否かを表す情報(レンジ分割対象か、非レンジ分割対象か)が含まれる。一意性情報は、図11および図12のスキーマテーブル121から取得できる。レンジ分割対象か非レンジ分割対象かは、図13および図14の分割情報テーブル122の分割基準を参照することにより判断できる。
条件値タイプとは、検索条件の中でシーケンスが満たすべき条件の種類を表すものである。条件値タイプとしては、条件値が定数か変数か、および条件値が単独値かシーケンス値かによって、「定数単独値」、「変数単独値」、「定数シーケンス値」、および「変数シーケンス値」の4つの種類が存在する。
条件値が定数か変数かは、検索式を解析することにより判断する。例えば、図15のような検索式では、1行目の条件値である「12345」は定数であると判断できる。また、2行目の条件値である「$x」は、1行目で定義された変数であると判断できる。
さらに、判定部103は、条件値が単独値かシーケンス値かを検査する。具体的には、判定部103は、条件値が定数である場合は、その定数が単独値かシーケンス値かを検索式を解析することにより判断する。また、判定部103は、条件値が変数である場合は、検索式中でその条件値が作成される箇所を辿り、シーケンス値を示す変数であるかを判断する。
次に、判定部103は、求めたデータ属性と条件値タイプとに対応する局所性情報を、図17のような局所性判定表123から取得することにより、局所性情報を判定する。図17は、局所性判定表123のデータ構造の一例を示す説明図である。判定部103は、データ属性および条件値タイプの組合せによって局所性情報を以下のように判定する。
(1)局所性情報「あり」と判定する場合:
(a)データ属性が「ユニーク型」または「レンジ分割対象」であり、かつ、条件値タイプが「単独値」である場合。
(b)データ属性が「レンジ分割対象」であり、かつ、条件値タイプが「定数シーケンス値」であり、そのシーケンスに含まれる値がDB分割情報に照らして1つのスレーブに含まれる場合。
(2)局所性情報「不明」と判定する場合:なお、この場合は、検索処理時に条件値を個別に判断して局所性情報が判断される。
(a)データ属性が「レンジ分割対象」であり、かつ、条件値タイプが「変数シーケンス値」である場合。
(3)局所性情報「なし」と判定する場合:なお、局所性情報「なし」とは、条件値を参照しても220に分散して格納されているか否かを判別できないことを表す。
(a)データ属性が「非ユニーク型」かつ「非レンジ分割対象」である場合。
(b)データ属性が「ユニーク型」であり、かつ、条件値タイプが「シーケンス値」である場合。
(c)データ属性が「レンジ分割対象」であり、かつ、条件値タイプが「定数シーケンス値」であり、そのシーケンスに含まれる値がDB分割情報に照らして複数のスレーブノード200にまたがる場合。
次に、用途情報の求め方について説明する。XQueryの検索式中の中間結果の依存関係は、変数を用いた値の受け渡してとして表現される。例えば、図15の検索式では、中間結果として「$x」および「$a」が存在し、「$x」と「$a」との依存関係は、2行目の式によって表される。
判定部103は、このような受け渡し関係を辿ることにより、検索式中で作成される個別のシーケンスが、(1)検索式の最終出力結果の一部となる場合、用途情報=出力シーケンスと判断する。また、判定部103は、個別のシーケンスが、(2)検索式の最終出力結果の一部とならない場合、用途情報=参照シーケンスと判断する。
図15の例では、作成されるシーケンスの1つである「$b」は、最終行の式「return $b」で示されるように、検索式の最終出力結果であると判断できるため、判定部103は、用途情報=出力シーケンスであると判定する。一方、「$a」は、「return」式で出力されるシーケンスではないため、判定部103は、用途情報=参照シーケンスであると判定する。
このようにして、判定部103は、局所性情報と用途情報とを求める。そして、判定部103は、求めた局所性情報と用途情報とを、図18のような作成判定表124と照合することにより、論理シーケンス管理情報を作成するか否かを判定する。図18は、作成判定表124のデータ構造の一例を示す説明図である。判定部103は、論理シーケンス管理情報の作成有無を、用途情報および局所性情報の組合せによって以下のように判定する。
(1)論理シーケンス管理情報を常に作成しないと判定する場合:
(a)用途情報が「参照シーケンス」である場合。
(b)用途情報が「出力シーケンス」であり、かつ、局所性情報が「あり」である場合。
(2)論理シーケンス管理情報を作成するか否かを検索処理実行時に条件値を個別に参照して判断すると判定する場合:
(a)用途情報が「出力シーケンス」であり、かつ、検索条件に局所性情報が「不明」である場合。
(3)論理シーケンス管理情報を作成すると判定する場合:
(a)用途情報が「出力シーケンス」であり、かつ、局所性情報が「なし」の場合。
図10に戻り、更新部104は、判定部103によって論理シーケンス管理情報を作成しないと判定されたシーケンスについて、論理シーケンス管理情報を登録するオペレータ(「registSequence」オペレータ)を省略した検索プランを生成し、生成済みの検索プランを更新するものである。
図19は、更新部104により更新された後の検索プランの一例を示す説明図である。図19は、判定部103の結果にしたがい、図15のような検索式で最初に得られるシーケンスである「$a」に対する「registSequence」オペレータを削除した検索プランの例を表している。
このように、更新部104によって、論理シーケンス管理情報を作成する必要がない場合は作成処理を行わないように検索プランの最適化を行うことができるため、検索処理のオーバヘッドを削減することが可能となる。
実行要求部105は、スレーブノード200に対して検索プランを送信することによって検索プランの実行を要求するものである。
転送要求部106は、あるスレーブノード200から中間結果の転送要求を受信したとき、実行可能な転送要求を決定して、転送元のスレーブノード200に対して転送要求を通知するものである。具体的には、転送要求部106は、スレーブノード200の転送要求通知部207(後述)から、中間結果の転送要求を受信して記憶部120などに記録する。また、転送要求部106は、スレーブノード200の中間結果作成通知を受けて記録する処理も行う。
図20は、中間結果の転送要求のデータ構造の一例を示す説明図である。図20に示すように、中間結果の転送要求には、転送元のスレーブノード200を識別する転送元スレーブノード情報と、転送先のスレーブノード200を識別する転送先スレーブノード情報と、転送する中間結果を識別する中間結果IDとが含まれる。
構成管理部107は、スレーブノード200の構成通知部208(後述)から各スレーブノード200のシーケンスIDを含む論理シーケンス管理情報を受信して管理するものである。図21は、論理シーケンス管理情報のデータ構造の一例を示す説明図である。
図21に示すように、論理シーケンス管理情報には、論理シーケンスを一意に識別する論理シーケンスIDと、部分シーケンスIDと、シーケンスIDを生成したスレーブノード200のスレーブノードIDと、中間結果IDと、キーIDとが含まれる。なお、中間結果IDとは、シーケンスを構成する要素の値が格納されている中間結果を識別する識別情報をいう。
部分シーケンスIDとは、スレーブノード200ごとに生成される物理的なシーケンスIDをいう。図22は、部分シーケンスIDのデータ構造の一例を示す説明図である。図22に示すように、部分シーケンスIDは、シーケンスを生成するスレーブノード200のスレーブノードIDと、中間結果IDと、中間結果中のカラムを識別するカラム番号と、中間結果中のレコードを識別するレコード番号と、局所シーケンスフラグとを対応づけたデータ構造となっている。
局所シーケンスフラグとは、シーケンスが分散して格納されているかを表すフラグであり、判定部103が判定した局所性情報が「あり」のとき「1」、「なし」のとき「0」が設定される。
キーIDとは、論理シーケンスを構成するために物理的なシーケンスをグループ化するときのキーとなる情報である。図23は、キーIDのデータ構造の一例を示す説明図である。図23に示すように、キーIDは、中間結果の入力元のスレーブノード200のスレーブノードIDと、入力元の中間結果IDと、入力元の中間結果内の中間結果レコード番号とを対応づけたデータ構造となっている。
中間結果管理部108は、各スレーブノード200の中間結果転送部206によって転送された中間結果を受信し、図示しないRAMなどの記憶媒体に保存することにより管理するものである。
結果取得部109は、最終的に出力された中間結果を元に各スレーブノード200からシーケンスの実体データを検索結果として取得して、クライアント300に送信するものである。
次に、スレーブノード200について説明する。図10に示すように、スレーブノード200は、物理DB220と、実行要求受付部201と、実行部202と、DB管理部203と、割当部204と、中間結果管理部205と、中間結果転送部206と、転送要求通知部207と、構成通知部208と、を備えている。
物理DB220は、水平分割された文書を記録する記憶媒体である。本実施の形態では、図6〜図9で説明したように、物理DB220はXML形式の文書を格納する。なお、物理DB220は、HDD、光ディスク、メモリカード、RAMなどの一般的に利用されているあらゆる記憶媒体により構成することができる。
実行要求受付部201は、マスタノード100から送信された検索プランの実行要求を受付けるものである。なお、実行要求には実行すべき検索プランが含まれる。
実行部202は、実行要求受付部201が受付けた実行要求に従い、実行が要求された検索プランを実行するものである。実行部202は、まず、検索プランから、実行可能状態テーブルを作成する。実行可能状態テーブルとは、検索プランに記述されたオペレータの入出力依存関係に従い、オペレータを実行するために必要な中間結果の状態に関する条件を定めたテーブルである。
図24および図25は、実行可能状態テーブルのデータ構造の一例を示す説明図である。図24は、図19に示すような検索プランに対して、スレーブノードID=1および2のスレーブノード200で作成される実行可能状態テーブルの一例を示している。また、図25は、図19に示すような検索プランに対して、スレーブノードID=3および4のスレーブノード200で作成される実行可能状態テーブルの一例を示している。
具体的には、実行可能状態テーブルは、入力されるべき中間結果を表す入力中間結果と、入力中間結果が入力されたときに実行可能なオペレータを表す実行オペレータと、オペレータが実行可能か否かを表す実行可能情報とを対応づけて格納している。すなわち、実行可能状態テーブルは、実行するオペレータごとに実行に必要な前提条件である中間結果を表したものである。なお、入力中間結果が「---」となっているオペレータは、実行に必要な中間結果が存在しないオペレータを表す。
実行可能情報には、必要な中間結果が不要な場合、または必要な中間結果が作成済みのため実行可能な場合に「1」が設定される。また、必要な中間結果が作成されていないため実行不可能な場合に「0」が設定される。また、オペレータが実行済みの場合に「2」が設定される。なお、実行可能情報の設定方法はこれに限られるものではなく、次に実行可能なオペレータを判断可能な方法であればあらゆる方法を適用できる。
実行部202は、このような実行可能状態テーブルを参照し、実行可能情報が「1」であるオペレータから次に実行すべきオペレータを選択して実行する。なお、次に実行すべきオペレータが尽きた場合に検索処理は終了する。そして、このときに各スレーブノード200上に残った中間結果が最終的な検索結果として得られる。
なお、実行部202は、検索要求に応じた検索プランに含まれうる様々なオペレータに関する処理を実行するものであるが、主に以下のような処理を実行する。
まず、実行部202は、オペレータ実行に際し、データベースを管理するDB管理部203(後述)に対してデータ取得に関する処理を実行させる。そして、実行部202は、オペレータの実行結果情報を、中間結果管理部205(後述)が管理する中間結果データに記録する。
また、実行部202は、各オペレータを実行し終わると、その結果得られた中間結果が作成済みであることを中間結果作成状態テーブルに記録する。図26は、中間結果作成状態テーブルのデータ構造の一例を示す説明図である。図26に示すように、中間結果作成状態テーブルには、作成済みの中間結果の中間結果IDが格納される。
その後、実行部202は中間結果作成状態テーブル上で更新された情報をもとに、実行可能状態テーブルの実行可能情報を更新する。すなわち、中間結果作成状態テーブルに追加された中間結果IDに対応する実行可能情報を、実行済みを表す「2」に更新する。
オペレータ実行時、実行部202は、スレーブノード200上の物理DB220および中間結果管理部205が管理している中間結果を対象として処理を行う。ただし、中間結果の転送要求を行うオペレータの場合は、実行部202は、転送要求通知部207に対して処理を行う。
図10に戻り、DB管理部203は、物理DB220に対するインデックススキャン、データベーススキャンなどの各種データ取得操作を実行するものである。
割当部204は、実行部202の指示によって、中間結果として生成されたシーケンスを識別するシーケンスIDを割り当てるものである。
中間結果管理部205は、生成された中間結果を管理するものである。具体的には、中間結果管理部205は、検索プランの実行に伴って生成された中間結果を、図示しないRAMなどの記憶媒体に保存することにより管理する。また、中間結果が転送されたときには、中間結果管理部205は、転送された中間結果の複製を作成して記憶媒体に保存する。
中間結果転送部206は、他のスレーブノード200からの中間結果の転送要求を、マスタノード100の転送要求部106を介して受信し、転送要求にしたがって他のスレーブノード200に対して中間結果を転送するものである。
具体的には、中間結果転送部206は、まず転送先スレーブノード情報と中間結果IDとを転送要求から取得する。そして、中間結果転送部206は、中間結果IDを参照して転送すべき中間結果を、中間結果管理部205を介して記憶媒体から取得する。次に、中間結果転送部206は、取得した中間結果を指定された転送先スレーブノード情報で識別されるスレーブノード200に転送する。
転送要求通知部207は、オペレータが中間結果の転送要求を送信するものである場合に、マスタノード100の転送要求部106に指定された中間結果の転送要求を通知するものである。
構成通知部208は、割当部204によって割り当てられたシーケンスIDを含む論理シーケンス管理情報を、マスタノード100の構成管理部107に通知するものである。
次に、このように構成された本実施の形態にかかる検索システムによる検索処理について図27を用いて説明する。図27は、本実施の形態における検索処理の全体の流れを示すフローチャートである。
まず、検索要求受付部101は、クライアント300からXQueryの検索式を検索要求として受付ける(ステップS2701)。次に、プラン生成部102は、受付けた検索式を解析して、検索プランを生成する(ステップS2702)。
次に、生成された検索プランから、不要な論理シーケンス管理情報を生成するオペレータを削除して検索プランを最適化する検索プラン最適化処理が実行される(ステップS2703)。検索プラン最適化処理の詳細については後述する。
次に、実行要求部105は、各スレーブノード200に対して、実行すべき検索プランの実行要求を通知する(ステップS2704)。
スレーブノード200の実行要求受付部201は、通知された実行要求を受付ける(ステップS2705)。次に、実行部202が、受付けた実行要求に含まれる検索プランを参照して図25または図26に示すような実行可能状態テーブルを作成する(ステップS2706)。
次に、実行部202は、実行可能状態テーブルを参照してオペレータごとの実行可能性を判断し、実行できるオペレータを選択する(ステップS2707)。
次に、実行部202は、論理シーケンスを生成するために論理シーケンス管理情報を通知するオペレータ(「registSequence」オペレータ)であるか否かを判断する(ステップS2708)。論理シーケンス管理情報を通知するオペレータである場合は(ステップS2708:YES)、構成通知部208は、論理シーケンス管理情報をマスタノード100に通知する(ステップS2709)。なお、構成通知部208は、それ以前に実行されたオペレータに関連する処理で割当部204によって生成されたシーケンスIDを含む論理シーケンス管理情報をマスタノード100に通知する。
マスタノード100の構成管理部107は、通知された論理シーケンス管理情報を受信してマスタノード100上の論理シーケンス管理情報に追加登録する(ステップS2710)。
ステップS2708で論理シーケンス管理情報を通知するオペレータでないと判断された場合は(ステップS2708:NO)、実行部202は、選択したオペレータを実行する(ステップS2711)。なお、上述のように、このステップでは中間結果の転送を含むさまざまなオペレータが実行されうるが、説明の便宜上、同図では省略している。
次に、実行部202は、オペレータの実行結果を中間結果作成状態テーブルに追加するとともに、実行可能状態テーブルの実行可能情報を更新する(ステップS2712)。
次に、実行部202は、実行可能状態テーブルを参照してすべてのオペレータが実行されたか否かを判断する(ステップS2713)。すべてのオペレータが実行されていない場合は(ステップS2713:NO)、次に実行可能なオペレータを選択して処理を繰り返す(ステップS2707)。
すべてのオペレータが実行された場合は(ステップS2713:YES)、実行部202は、処理結果をマスタノード100に送信する(ステップS2714)。
マスタノード100の結果取得部109は、各スレーブノード200からの処理結果を統合した検索結果を生成する(ステップS2715)。そして、結果取得部109は、生成した検索結果をクライアント300に送信して(ステップS2716)検索処理を終了する。
次に、ステップS2703の検索プラン最適化処理の詳細について図28を用いて説明する。図28は、本実施の形態における検索プラン最適化処理の全体の流れを示すフローチャートである。
まず、判定部103は、検索式を解析し、オペレータの処理結果として得られるシーケンスを取得する(ステップS2801)。例えば、図15に示すような検索式の場合、「$a」および「$b」が、シーケンスの処理結果として得られることが解析される。
次に、判定部103は、取得したシーケンスの用途情報が参照シーケンスか否かを判断する(ステップS2802)。上述のように、判定部103は、検索式内の値の受け渡し関係を解析することによりシーケンスの用途情報を判定する。図15の例では、「$a」および「$b」の用途情報はそれぞれ「参照シーケンス」および「出力シーケンス」と判定される。
用途情報が参照シーケンスでない場合、すなわち出力シーケンスの場合は(ステップS2802:NO)、判定部103は、ステップS2803からステップS2808で、上述のような判定表を用いた論理シーケンス管理情報の作成有無の判定処理を行う。
まず、判定部103は、スキーマテーブル121を参照し、シーケンスの一意性情報を取得する(ステップS2803)。次に、判定部103は、分割情報テーブル122を参照し、シーケンスがレンジ分割対象か、非レンジ分割対象かを決定する(ステップS2804)。
次に、判定部103は、検索式を解析し、シーケンスと比較する条件値が定数か変数かを決定する(ステップS2805)。続いて、判定部103は、条件値が単独値かシーケンス値かを決定する(ステップS2806)。
次に、判定部103は、決定したデータ属性(一意性情報、およびレンジ分割対象か非レンジ分割対象かを表す情報)、および決定した条件値タイプ(定数か変数か、および単独値かシーケンス値か)に従い、局所性判定表123を参照して局所性情報を判定する(ステップS2807)。
次に、判定部103は、判定された局所性情報と作成判定表124とを参照し、論理シーケンス管理情報の作成有無を判定する(ステップS2808)。例えば、図18のような作成判定表124によれば、局所性情報ありと判定された場合であれば、用途情報が出力シーケンスであっても、論理シーケンス管理情報の作成は不要と判定される。
ステップS2802で、用途情報が参照シーケンスであると判断された場合は(ステップS2802:YES)、判定部103は、論理シーケンス管理情報を作成しないと判定する(ステップS2809)。参照シーケンスの場合は、出力用に論理シーケンスを構成する必要がないため、常に論理シーケンス管理情報の作成は不要と判定することができるためである。
次に、更新部104は、論理シーケンス管理情報の作成が不要である判定されたか否かを判断する(ステップS2810)。不要と判定された場合は(ステップS2810:YES)、更新部104は、不要と判定されたシーケンスに対応して論理シーケンス管理情報を通知するオペレータを検索プランから削除することにより、検索プランを更新する(ステップS2811)。
検索プランの更新後、または、ステップS2810で、論理シーケンス管理情報の作成が不要でないと判定された場合は(ステップS2810:NO)、判定部103は、検索式内のすべてのシーケンスを処理したか否かを判断する(ステップS2812)。
すべてのシーケンスを処理していない場合は(ステップS2812:NO)、次のシーケンスを取得して処理を繰り返す(ステップS2801)。すべてのシーケンスを処理した場合は(ステップS2812:YES)、検索プラン最適化処理を終了する。
このように、検索プラン最適化処理によって、論理シーケンス管理情報の作成が不要な場合には論理シーケンス管理情報を通知するオペレータが検索プランから削除される。これにより、従来はすべてのシーケンスに対して図27のステップS2709のように論理シーケンス管理情報を通知するオペレータが実行されていたのに対し、本実施の形態では不要なオペレータの実行を回避して検索処理の処理負担を軽減することが可能となる。
次に、本実施の形態による検索処理の具体例について説明する。なお、以下では、「registSequence」オペレータを削除することにより、論理シーケンス管理情報を作成しない検索プランに最適化された場合であっても、検索式を満たす検索結果が正しく得られる例について説明する。
また、以下では、図5の構成を前提とし、マスタノード100の記憶部120には、図11〜図14のようなテーブルと、図17および図18のような判定表とが記憶され、図15に示すような検索式が入力された場合を例として説明する。
なお、図29〜図52、図54〜図60、および図62〜図64は、この例で出力される中間結果の一例を示す説明図である。また、図53および図61は、この例で出力される論理シーケンス管理情報の一例を示す説明図である。
この場合、上述のように、プラン生成部102は、図19に示すような最適化された検索プランを生成する。そして、生成された検索プランに従い、以下の手順で検索処理が実行される。
まず、スレーブノード1の実行要求受付部201は、マスタノード100の実行要求部105からスレーブノード1で実行する検索プランを受け取る。
なお、スレーブノード1とは、それぞれスレーブノードID=1であるスレーブノード200を表す。以下、同様に、スレーブノードID=2、3および4であるスレーブノード200を、それぞれスレーブノード2、3およびスレーブノード4という。
スレーブノード1の実行部202は、実行要求受付部201から検索プランを受け取る。実行部202は、受け取った検索プランに記述されたオペレータに関して、入力の中間結果を条件として実行可能条件を表現する図22のような実行可能状態テーブルを作成する。また、同時に中間結果作成状態テーブルを作成する。なお、初期状態では、中間結果作成状態テーブルにはいずれの中間結果も設定されない。スレーブノード2、スレーブノード3およびスレーブノード4でも、同様に実行部202による処理が行われる。
次に、スレーブノード1の実行部202は、実行するオペレータを選択する。この時点では、入力すべき中間結果が存在しないため無条件で実行可能である「createTable」オペレータと「request」オペレータが実行可能である。ここでは、実行部202は、まず「request」オペレータを選択するものとする。
実行部202は、中間結果BT3の転送要求を行う「request」オペレータを実行する。「request」オペレータの実行により、スレーブノード1の転送要求通知部207に対して、転送要求通知処理の実行が要求される。転送要求通知部207は、マスタノード100の転送要求部106へ転送要求を通知する。マスタノード100上の転送要求部106は、通知された転送要求を受け取り、管理用のテーブルなどに記録することにより転送要求を管理する。スレーブノード2でも同様に中間結果BT3の転送要求を行うオペレータが実行される。また、スレーブノード3およびスレーブノード4でも、同様の手順によって中間結果BT2の転送要求を行う「request」オペレータが実行される。
さらに、スレーブノード1の実行部202はオペレータ選択を行い、「createTable」オペレータを選択する。実行部202は、検索式で与えられた定数値を記録する中間結果を作成する「createTable」オペレータを実行し、得られた中間結果BT1を中間結果管理部205によって記録する。
この「createTable」オペレータでは、実行部202は、指定された定数値をもつ中間結果を作成する処理を行う。この例では、図15の検索式のように、定数値として「12345」が指定されている。このため、オペレータ実行の結果、図29に示す中間結果が作成される。作成された中間結果は1カラムかつ1レコードであり、そのカラム値は「12345」である。
また、実行部202は、作成済み中間結果として、BT1を中間結果作成状態テーブルに記録する。さらに、実行部202は、中間結果作成状態テーブル上で更新された情報をもとに、実行可能状態テーブルの実行可能情報を実行済み(2)に更新する。
更新された実行可能状態テーブルを参照し、スレーブノード1の実行部202は、実行可能なオペレータとして「select」オペレータを選択し、「select」オペレータを実行する。ここでの「select」オペレータは、図29の中間結果BT1のカラム「col1」の値を入力とし、「auctions」データベースに格納されている「deal」データ中の「/deal/item/@category」ノードのうち、入力値「12345」と合致する値をもつノードを検索し、そのノードIDを取得する処理を示している。
実行部202は、新たに中間結果BT100を作成し、「select」オペレータにより取得された値を中間結果BT100のカラム「category」に記録する。さらに作成したBT100を中間結果管理部205によって記録する。「select」オペレータの実行の結果、図30に示す中間結果が作成される。図30に示すように、「category」カラム値として、「001」と「002」の2つのノードIDが得られている。実行部202は、作成済み中間結果として、中間結果BT100を中間結果作成状態テーブルに記録する。実行部202は中間結果作成状態テーブル上で更新された情報をもとに、実行可能状態テーブルの実行可能情報を更新する。
更新された実行可能状態テーブルを参照し、スレーブノード1の実行部202は実行可能なオペレータとして「scanAncestor」オペレータを選択し、「scanAncestor」オペレータを実行する。ここでの「scanAncestor」オペレータは、図30に示す中間結果BT100の「category」カラムの値を入力として取り、「auctions」データベースに格納されている「deal」データ中の「/deal」ノードのうち、入力値が示すノード「/deal/item/@category」の祖先ノードとなるノードIDを取得する処理を示している。
実行部202は、新たに中間結果BT101を作成し、「scanAncestor」オペレータにより取得された値を中間結果BT101のカラム「deal」に記録する。実行部202は、さらに作成した中間結果BT101を中間結果管理部205によって記録する。この場合、図31に示すように、「@category」カラムの値「001」および「002」が示すノードの祖先ノードとして、「deal」カラムの値「003」および「004」がそれぞれ得られる。
実行部202は、作成済み中間結果として、中間結果BT101を中間結果作成状態テーブルに記録する。実行部202は中間結果作成状態テーブル上で更新された情報をもとに、実行可能状態テーブルの実行可能情報を更新する。
更新された実行可能状態テーブルを参照し、スレーブノード1の実行部202は実行可能なオペレータとして「scanDescendant」オペレータを選択し、「scanDescendant」オペレータを実行する。ここでの「scanDescendant」オペレータは、図31に示す中間結果BT101の「deal」カラムの値を入力とし、「auctions」データベースに格納されている「deal」データ中の「/deal/related/@category」ノードのうち、入力値が示すノード「/deal」の子孫ノードとなるノードのノードIDを取得する処理を示している。
実行部202は、新たに中間結果BT2を作成し、「scanDescendant」オペレータにより取得された値を中間結果BT2のカラム「category2」に記録する。さらに作成したBT2を中間結果管理部205によって記録する。この場合、図32に示すように、「deal」カラムの値「003」の子孫ノードとして「category2」カラムの値「005」および「006」の2値、「004」の子孫ノードとして「category2」カラムの値「007」および「008」の2値が得られる。
実行部202は、作成済み中間結果として、中間結果BT2を中間結果作成状態テーブルに記録する。実行部202は中間結果作成状態テーブル上で更新された情報をもとに、実行可能状態テーブルの実行可能情報を更新する。
更新された実行可能状態テーブルを参照し、スレーブノード1の実行部202は実行可能なオペレータとして「notify」オペレータを選択し、「notify」オペレータを実行する。ここでの「notify」オペレータは、中間結果BT2が作成済み状態であることを示す中間結果作成通知をマスタノード100の転送要求部106に通知する。
同様にして、スレーブノード2でも、実行部202が、スレーブノード1におけるここまでの一連の処理と同様の流れでオペレータを実行する。「createTable」オペレータの実行により図33に示すBT1が生成される。次に「select」オペレータの実行により図34に示すBT100が生成される。次に「scanAncestor」オペレータの実行により図35に示すBT101が生成される。次に「scanDescendant」オペレータの実行により図36に示すBT2が生成される。その後、「notify」オペレータの実行により、スレーブノード2の実行部202は、中間結果BT2が作成済み状態であることを示す中間結果作成通知をマスタノード100の転送要求部106に通知する。
次に、マスタノード100上の転送要求部106は、これまでに受け取った中間結果作成通知および転送要求通知をマッチングし、実行が可能な転送要求を決定する。この場合、スレーブノード1およびスレーブノード2で中間結果BT2が作成済みであるので、スレーブノード3とスレーブノード4に対して、それぞれの中間結果BT2の転送が可能である決定できる。
マスタノード100の転送要求部106は、転送する中間結果BT2を格納している転送元スレーブノード200の中間結果転送部206に対して転送要求を通知して、中間結果の転送を要求する。この例では、マスタノード100の転送要求部106は、転送すべき中間結果BT2を格納している転送元スレーブノード200であるスレーブノード1およびスレーブノード2の中間結果転送部206に対して、中間結果BT2を、転送先スレーブノード200であるスレーブノード3およびスレーブノード4へ転送する転送要求を通知する。
転送要求を受けたスレーブノード1とスレーブノード2の中間結果転送部206は、マスタノード100上の転送要求部106からの転送要求を受け取る。その後、転送要求が示す転送先スレーブノード200であるスレーブノード3およびスレーブノード4に対する中間結果BT2の転送を実行する。
転送を受ける転送先スレーブノード200であるスレーブノード3の中間結果転送部206は、新たに中間結果BT2を作成する。その後、転送元スレーブノード200であるスレーブノード1とスレーブノード2から転送される中間結果を受け取り、受け取った中間結果を作成した中間結果BT2に順次記録する。このとき、各レコードに関してキーIDを作成し、中間結果BT2のキーIDカラムに格納する。転送の結果、図37に示すBT2が作成される。
図37に示すように、スレーブノード1の中間結果BT2(図32)とスレーブノード2の中間結果BT2(図36)の値がマージされた中間結果がスレーブノード3の中間結果BT2として作成される。実行部202は、最終的に作成された中間結果BT2を中間結果管理部205によって記録する。さらに、転送先スレーブノード200の実行部202に対して中間結果BT2の転送完了通知を行う。実行部202は、作成済み中間結果として、中間結果BT2を中間結果作成状態テーブルに記録する。実行部202は中間結果作成状態テーブル上で更新された情報をもとに、実行可能状態テーブルの実行可能情報を更新する。
転送を受ける転送先スレーブノード200であるスレーブノード4でも同様の処理が行われ、図37と同様の中間結果BT2が作成される。
更新された実行可能状態テーブルを参照し、スレーブノード3の実行部202は実行可能なオペレータとして「Join」オペレータを選択し、「Join」オペレータを実行する。ここでの「Join」オペレータは、図37に示す中間結果BT2の「category2」カラムの値を入力とし、「auctions」データベースに格納されている「deal」データ中で入力値が示す「/deal/related/@category」ノードのノード値と、「people」データベースに格納されている「person」データ中の「/person/profile/interest/@category」ノードのノード値とを比較し、入力値が示す「/deal/related/@category」ノードのノード値と一致する値を持つ「/person/profile/interest/@category」ノードのノードIDを取得する処理を示している。
実行部202は、新たに中間結果BT200を作成し、「Join」オペレータにより取得された値を中間結果BT200のカラム「category3」に記録する。実行部202は、さらに作成した中間結果BT200を中間結果管理部205によって記録する。この場合、図38に示すように、「category2」カラムの値「005」に対しては、「category3」カラムの値として「201」が求められる。同様に、「category2」カラムの値「007」に対しては、「category3」カラムの値として「202」および「203」の2値が求められる。さらに、「category2」カラムの値「106」に対しては、「category3」カラムの値として「204」および「205」の2値が求められる。「category2」カラムのその他の値「006」、「008」、「105」、「107」および「108」に対しては、求められる値がデータベースpeople中に存在しない。
実行部202は、作成済み中間結果として、中間結果BT200を中間結果作成状態テーブルに記録する。実行部202は中間結果作成状態テーブル上で更新された情報をもとに、実行可能状態テーブルの実行可能情報を更新する。
更新された実行可能状態テーブルを参照し、スレーブノード3の実行部202は実行可能なオペレータとして「scanAncestor」オペレータを選択し、「scanAncestor」オペレータを実行する。ここでの「scanAncestor」オペレータは、図38に示す中間結果BT200の「category3」カラムの値を入力とし、「people」データベースに格納されている「person」データ中の「/person」ノードのうち、入力値が示すノード「/person/profile/interest/@category」の祖先ノードのノードIDを取得する処理を示している。
実行部202は、新たに中間結果BT201を作成し、「scanAncestor」オペレータにより取得された値を中間結果BT201のカラム「person」に記録する。この場合、図39に示す中間結果が求められる。同図では、例えば「category3」カラムの値「201」が示す「/person/profile/interest/@category」ノードの祖先ノードのノードIDとして「206」が求められることが示されている。さらに実行部202は、作成済み中間結果として、BT201を中間結果作成状態テーブルに記録する。実行部202は中間結果作成状態テーブル上で更新された情報をもとに、実行可能状態テーブルの実行可能情報を更新する。
更新された実行可能状態テーブルを参照し、スレーブノード3の実行部202は実行可能なオペレータとして「scanDescendant」オペレータを選択し、「scanDescendant」オペレータを実行する。ここでの「scanDescendant」オペレータは、図39に示す中間結果BT201の「person」カラムの値を入力とし、「people」データベースに格納されている「person」データ中の「/person/@id」ノードのうち、入力値が示すノード「/person」の子孫ノードとなるノードIDを取得する処理を示している。
実行部202は、新たに中間結果BT202を作成し、「scanDescendant」オペレータにより取得された値を中間結果BT202のカラム「id」に記録する。実行部202は、さらに作成した中間結果BT202を中間結果管理部205によって記録する。この場合、図40に示す中間結果が求められる。同図では、例えば、「person」カラムの値「206」が示す「/person」ノードの子孫ノードのノードIDとして「211」が求められることが示されている。
さらに、実行部202は、作成済み中間結果として、BT202を中間結果作成状態テーブルに記録する。実行部202は中間結果作成状態テーブル上で更新された情報をもとに、実行可能状態テーブルの実行可能情報を更新する。
更新された実行可能状態テーブルを参照し、スレーブノード3の実行部202は実行可能なオペレータとして「sequence」オペレータを選択し、「sequence」オペレータを実行する。ここでの「sequence」オペレータは、図40に示す中間結果BT202を入力とし、入力された中間結果の各レコードに関して、同一の「キーID」カラム値を持つレコードをグループ化し、「id」カラム値からなるシーケンス、およびそのシーケンスのシーケンスIDを求める処理を行う。
すなわち、実行部202は、新たに中間結果BT3と中間結果BT1002とを作成し、中間結果BT3のカラム「S(id)」に生成されたシーケンスIDを記録するとともに、中間結果BT1002のカラム「S(id)」とカラム「id」に、生成されたシーケンスIDとその要素となる「id」カラム値を対にして記録する。実行部202は、さらに作成した中間結果BT3および中間結果BT1002を中間結果管理部205によって記録する。この場合、図41および図42に示す中間結果BT3およびBT1002がそれぞれ求められる。例えば、図41では、生成された3つのシーケンスのシーケンスIDが「S(id)」カラムの値「33411」、「33421」および「33431」として求められている。また、図42では、このシーケンスID「33421」が示すシーケンスの実体として、「id」カラムの値「212」および「213」が求められている。すなわち、シーケンスID「33421」が示すシーケンスは、この2値から構成される。
なお、このときのシーケンスIDは以下の手順で求められる。まず、実行部202は、「sequence」オペレータの実行の際に、自身のスレーブノードID、結果格納先となる中間結果の中間結果ID、中間結果中のカラム番号、中間結果中のレコード番号、およびプラン生成時に求めた局所性判定結果である局所性情報に対応する局所シーケンスフラグを、割当部204に対して一組の入力として与える。割当部204は、図22のフォーマットに従ってシーケンスIDを生成し、実行部202に返却する。なお、最適化が実行されているため、「registSequence」オペレータは実行されない。
実行部202は、作成済み中間結果として、中間結果BT3を中間結果作成状態テーブルに記録する。実行部202は中間結果作成状態テーブル上で更新された情報をもとに、実行可能状態テーブルの実行可能情報を更新する。
更新された実行可能状態テーブルを参照し、スレーブノード3の実行部202は実行可能なオペレータとして「notify」オペレータを選択し、「notify」オペレータを実行する。ここでの「notify」オペレータは、中間結果BT3が作成済み状態であることを示す中間結果作成通知をマスタノード100の転送要求部106に通知する。
同様にして、スレーブノード4でも、実行部202が、スレーブノード3におけるここまでの一連の処理と同様の流れでオペレータを実行する。転送実行により図37と同様のBT2がスレーブノード4上に生成される。次に「Join」オペレータの実行により図43に示すBT200が生成される。次に「scanAncestor」オペレータの実行により図44に示すBT201が生成される。次に「scanDescendant」オペレータの実行により図45に示すBT202が生成される。次に「sequence」オペレータの実行により図46に示すBT3および図47に示すBT1002が生成される。その後、「notify」オペレータ実行により、中間結果BT3が作成済み状態であることを示す中間結果作成通知をマスタノード100の転送要求部106に通知する。
次に、マスタノード100上の転送要求部106は、これまでに受け取った中間結果作成通知および転送要求通知をマッチングし、実行が可能な転送要求を決定する。この場合、スレーブノード3およびスレーブノード4で中間結果BT3が作成済みであるので、スレーブノード1とスレーブノード2に対して、それぞれの中間結果BT3の転送が可能である決定できる。
マスタノード100の転送要求部106は、転送する中間結果BT3を格納している転送元スレーブノード200の中間結果転送部206に対して転送要求を通知し、中間結果の転送を要求する。この場合、マスタノード100の転送要求部106は、転送すべき中間結果BT3を格納している転送元スレーブノード200であるスレーブノード3およびスレーブノード4の中間結果転送部206に対して、中間結果BT3を転送先スレーブノード200であるスレーブ1およびスレーブ2へ転送する転送要求を通知する。
転送要求を受けたスレーブノード3とスレーブノード4の中間結果転送部206は、マスタノード100上の転送要求部106からの転送要求を受け取る。その後、転送要求が示す転送先スレーブノード200であるスレーブノード1とスレーブノード2に対する中間結果BT3の転送を実行する。
転送を受ける転送先スレーブノード200であるスレーブノード1の中間結果転送部206は、新たに中間結果BT3を作成する。その後、転送元スレーブノード200であるスレーブノード3とスレーブノード4から転送される中間結果を受け取り、受け取った中間結果を作成した中間結果BT3に順次記録する。転送の結果、図48に示すBT3が作成される。
同図に示すように、スレーブノード3の中間結果BT3(図41)とスレーブノード4の中間結果BT3(図46)の値がマージされた中間結果がスレーブノード1の中間結果BT3として作成される。実行部202は、最終的に作成された中間結果BT3を中間結果管理部205によって記録する。スレーブノード1の実行部202は、さらに、転送先スレーブノード200の実行部202に対して中間結果BT3の転送完了通知を行う。実行部202は、作成済み中間結果として、中間結果BT3を中間結果作成状態テーブルに記録する。実行部202は、中間結果作成状態テーブル上で更新された情報をもとに、実行可能状態テーブルの実行可能情報を更新する。
転送を受ける転送先スレーブノード200であるスレーブノード2でも同様の処理が行われ、図48と同様の中間結果BT3が作成される。
更新された実行可能状態テーブルを参照し、スレーブノード1の実行部202は実行可能なオペレータとして「Join」オペレータを選択し、「Join」オペレータを実行する。ここでの「Join」オペレータは、図48に示す中間結果BT3の「S(id)」カラムの値を入力とし、「people」データベースに格納されている「person」データ中で、入力値が示す「/person/@id」ノードのノード値と、「auctions」データベースに格納されている「deal」データ中の「/deal/@buyer」ノードのノード値とを比較し、入力値が示す「/person/@id」ノードのノード値と一致する値を持つ「/deal/@buyer」ノードのノードIDを取得する処理を示している。
実行部202は、新たに中間結果BT300を作成し、「Join」オペレータにより取得された値を中間結果BT300のカラム「person」に記録する。実行部202は、さらに作成した中間結果BT300を中間結果管理部205によって記録する。この場合、図49に示す中間結果が得られる。同図では、例えば、「S(id)」カラムの値「33411」に対する「person」カラムの値として「401」および「402」が求められることが示されている。
実行部202は、作成済み中間結果として、中間結果BT300を中間結果作成状態テーブルに記録する。実行部202は中間結果作成状態テーブル上で更新された情報をもとに、実行可能状態テーブルの実行可能情報を更新する。
更新された実行可能状態テーブルを参照し、スレーブノード1の実行部202は実行可能なオペレータとして「scanAncestor」オペレータを選択し、「scanAncestor」オペレータを実行する。ここでの「scanAncestor」オペレータは、図49に示す中間結果BT300の「person」カラムの値を入力とし、「auctions」データベースに格納されている「deal」データ中の「/deal」ノードのうち、入力値が示すノード「/deal/@buyer」の祖先ノードのノードIDを取得する処理を示している。
実行部202は、新たに中間結果BT301を作成し、「scanAncestor」オペレータにより取得された値を中間結果BT301のカラム「deal」に記録する。この場合、図50に示す中間結果が求められる。さらに実行部202は、作成済み中間結果として、BT301を中間結果作成状態テーブルに記録する。実行部202は中間結果作成状態テーブル上で更新された情報をもとに、実行可能状態テーブルの実行可能情報を更新する。
更新された実行可能状態テーブルを参照し、スレーブノード1の実行部202は実行可能なオペレータとして「sequence」オペレータを選択し、「sequence」オペレータを実行する。ここでの「sequence」オペレータは、図50に示す中間結果BT301を入力とし、入力された中間結果の各レコードに関して、同一の「キーID」カラム値を持つレコードをグループ化し、「deal」カラム値からなるシーケンス、およびそのシーケンスのシーケンスIDを求める処理を行う。
実行部202は、新たに中間結果BT0と中間結果BT1004を作成し、中間結果BT0のカラム「S(deal)」に生成されたシーケンスIDを記録するとともに、中間結果BT1004のカラム「S(deal)」とカラム「deal」に、生成されたシーケンスIDとその要素となる「deal」カラム値を対にして記録する。
実行部202は、さらに作成した中間結果BT0および中間結果BT1004を中間結果管理部205によって記録する。この場合、図51および図52に示す中間結果が求められる。例えば、図51では、生成された3つのシーケンスのシーケンスIDが「S(deal)」カラムの値「10110」、「10120」および「10130」として求められた例が示されている。
また、図52では、このシーケンスID「10110」が示すシーケンスの実体として、「deal」カラムの値「406」および「407」が求められた例が示されている。シーケンスID「10110」が示すシーケンスは、この2値から構成される。実行部202は、作成済み中間結果として、中間結果BT0を中間結果作成状態テーブルに記録する。実行部202は中間結果作成状態テーブル上で更新された情報をもとに、実行可能状態テーブルの実行可能情報を更新する。
更新された実行可能状態テーブルを参照し、スレーブノード1の実行部202は実行可能なオペレータとして「registSequence」オペレータを選択し、「registSequence」オペレータを実行する。「registSequence」オペレータでは、実行部202は、中間結果BT0に記録されているS(deal)属性に関する論理シーケンス管理情報を構成通知部208に渡す。構成通知部208は受け取った論理シーケンス管理情報をマスタノード100の構成管理部107に転送する。マスタノード100上の構成管理部107は、受け取った論理シーケンス管理情報を図53で示される論理シーケンス構成管理テーブルに追加登録する。
例えば、図51のBT0に対しては、1レコード目の「S(deal)」カラム値で示されるシーケンスの論理シーケンス管理情報は、(10110,1,1004,111)となる。これは、図53の1レコード目の論理シーケンス管理情報に対応する。
同様にして、スレーブノード2でも、実行部202が、スレーブノード1におけるここまでの一連の処理と同様の流れでオペレータを実行する。転送実行により図48と同様のBT3がスレーブノード2上に生成される。次に「Join」オペレータの実行により図54に示すBT300が生成される。次に「scanAncestor」オペレータの実行により図55に示すBT301が生成される。次に「sequence」オペレータの実行により図56に示すBT0および図57に示すBT1004が生成される。その後、「registSequence」オペレータ実行により、中間結果BT0に関する論理シーケンス管理情報をマスタノード100の構成管理部107に転送する。マスタノード100上の構成管理部107は、転送された論理シーケンス管理情報を、図53のような論理シーケンス構成管理テーブルに追加する。
以上の、一連の検索プランの実行結果として、データベース検索の検索結果して得られた図58および図59の中間結果BT0は、スレーブノード1およびスレーブノード2の中間結果管理部205にそれぞれ保持されている。また、スレーブノード200をまたがって存在するシーケンスの構成を示す図53の論理シーケンス構成管理テーブルは、マスタノード100の構成管理部107に保持されている。
すべての検索プランの実行後、スレーブノード1およびスレーブノード2は最終的に得られた中間結果BT0をそれぞれの中間結果転送部206に渡し、マスタノード100に転送する。マスタノード100の中間結果管理部108は各スレーブノード200からの中間結果を受信し、それぞれをマージして図60に示すようなマスタノード100上の中間結果BT0を作成して記録する。
最終的に検索結果を返却する際には、以下の手順で検索結果である「$b」に相当する「S(deal)」カラムの値(シーケンス値)を取得する。
まず、検索プランの実行終了後、マスタノード100上の結果取得部109は、図60のような中間結果BT0の「S(deal)」カラムからシーケンスIDを取り出す。結果取得部109は、取り出した値の局所シーケンスフラグの値を参照することにより(末尾の数値が0)、局所性の無い論理シーケンスであることを判断できる。結果取得部109は、論理シーケンスを構成する部分シーケンスの実体を取得するために、取り出したシーケンスIDをキーとして、構成管理部107によって管理される論理シーケンス構成管理テーブルから論理シーケンス管理情報を取得する。
例えば、「S(deal)」カラム値「10110」の場合、論理シーケンス管理情報の部分シーケンスIDを参照することにより、対応する論理シーケンスIDとして「1」を取得することができる。図61は、このようにして得られた論理シーケンス管理情報の一例を示している。結果取得部109は、得られた論理シーケンス管理情報から、論理シーケンスを構成する部分シーケンスが存在するスレーブノードIDと中間結果IDを取得し、転送要求部106に中間結果の転送を要求する。
転送要求部106は、該当するスレーブノード200へ中間結果IDとシーケンスIDを通知し中間結果の転送を要求する。転送要求部106から中間結果の転送要求を受けたスレーブノード200の中間結果転送部206は、要求された中間結果をマスタノード100の中間結果管理部108へ転送する。スレーブノード1から転送される中間結果は、例えば、図62のような中間結果BT1006で表される。また、スレーブノード2から転送される中間結果は、例えば、図63のような中間結果BT1007で表される。
マスタノード100の中間結果管理部108は、受信した中間結果をマージした図64のような中間結果BT1008を作成して記録する。結果取得部109は、図64の中間結果BT1008の「deal」カラムの値として、論理シーケンスID「1」を構成する「/deal」ノードの値を得ることができる。
以上説明したように、「registSequence」オペレータを実行しないように最適化された検索プランであっても正常に検索結果を取得することができる。すなわち、本実施の形態の手法により、論理シーケンス管理情報を作成する必要がない場合は作成処理を行わないように検索プランを最適化し、その結果として検索処理のオーバヘッドを削減することができる。
次に、「registSequence」オペレータを省略できないにも関わらず「registSequence」オペレータをスキップするように検索プランを変形したことにより、検索結果が正しく得られない例について説明する。以下では、図65に示すような検索式が入力された場合を例として説明する。
なお、図66は、本来実行されるべき検索プランの一例を示す説明図である。また、図67は、「registSequence」オペレータをスキップするように変形した検索プランの一例を示す説明図である。また、図68〜図74は、この例で出力される中間結果の一例を示す説明図である。また、図75は、この例で出力される論理シーケンス管理情報の一例を示す説明図である。
図65の検索式の場合、シーケンス「$a」は最終出力結果となる出力シーケンスであるため、シーケンス「$a」に関する検索プランに関して「registSequence」オペレータをスキップするようなプラン変形を行うことはできない。
図67の最後でBT3を出力するオペレータの実行までは、上述の図19の検索プランでBT3を出力するオペレータの実行までの流れと同様に、各スレーブノード200上で一連のオペレータが実行される。スレーブノード3上では図68に示すような中間結果BT3が出力される。また、スレーブノード4上では図69に示すような中間結果BT3が求められる。
以上の一連の検索プランの実行結果として得られた図68および図69の中間結果BT3は、スレーブノード3およびスレーブノード4の中間結果管理部205にそれぞれ保持されている。すべての検索プランの実行後、スレーブノード3およびスレーブノード4は最終的に得られた中間結果BT3をそれぞれの中間結果転送部206に渡し、マスタノード100に転送する。
マスタノード100の中間結果管理部108は各スレーブノード200からの中間結果を受信し、それぞれをマージして図70に示すようなマスタノード100上の中間結果BT3を作成し、中間結果管理部205によって記録する。
最終的に検索結果の返却する際には、以下の手順で検索結果である「$a」に相当する「S(id)」カラムの値(シーケンス値)を取得する。
まず、検索プランの実行終了後、マスタノード100上の結果取得部109は、図70のような中間結果BT3の「S(id)」カラムからシーケンスIDを取り出す。結果取得部109は、取り出した値の局所シーケンスフラグの値を参照することにより(末尾の数値が1)、局所性がある論理シーケンスであることを判断できる。
次に、結果取得部109は、得られたシーケンスIDから、シーケンスを構成する部分シーケンスが存在するスレーブノード200と中間結果IDを取得し、転送要求部106に中間結果の転送を要求する。例えば、「S(id)」カラム値が「33411」の場合、結果取得部109は、図22に示すようなシーケンスIDのフォーマットに従い、スレーブノード3のBT3に存在するシーケンスであることを判断できる。
転送要求部106は、該当するスレーブノード200へ中間結果IDとシーケンスIDを通知し中間結果の転送を要求する。転送要求部106から中間結果の転送要求を受けたスレーブノード200の中間結果転送部206は、要求された中間結果をマスタノード100の中間結果管理部108へ転送する。スレーブノード3から転送される中間結果は、例えば、図71のような中間結果BT1002で表される。また、スレーブノード4から転送される中間結果は、例えば、図72のような中間結果BT1002で表される。
マスタノード100の中間結果管理部108は、中間結果を受信すると、図73に示すような中間結果BT1004を作成して記録する。結果取得部109は、図73の中間結果BT1004の「id」カラムの値として、シーケンスID「33411」を構成する「/person/@id」ノードの値を得ることになる。
しかしながら、ここで得られた検索結果は誤りである。BT3を得るオペレータの前に実行される「scanDescendant」オペレータによって、図40および図45のように各スレーブノード200で求められた中間結果BT202は、論理的には図74のように一つである。そのため、例えば「category2」カラム(=$x)の値が「005」の場合に、その値を元に得られるシーケンス「S(id)」カラムの値は、論理的には図75のように2値の「id」カラムの値からなるシーケンスとなるのが正しい。これに対し、図73では、「211」のみしか「id」カラムの値として得られていない。
すなわち、「registSequence」オペレータを排除する最適化を行える条件を満たさないにもかかわらず「registSequence」オペレータを排除するプラン変形を行った場合、誤った結果が求められることになる。言い換えると、本実施のようにシーケンスの局所性および用途を判定して検索プランの最適化を行うことにより、不要な処理を回避して処理負担を軽減しつつ、正しい検索結果を得ることが可能となる。
以上のように、本実施の形態にかかる検索システムでは、分散データベースの検索過程で得られたシーケンスが物理DB220の1つに局所的に格納されているか、および検索結果として出力されるかを判定し、いずれかを満たす場合に、論理シーケンスを構成する処理を不要とするように検索プランを最適化することができる。このため、分散データベースの検索で発生しうるシーケンスに関する処理負担を軽減することが可能となる。
次に、本実施の形態にかかるマスタノードおよびスレーブノードのハードウェア構成について図76を用いて説明する。図76は、本実施の形態にかかるマスタノードおよびスレーブノードのハードウェア構成を示す説明図である。
本実施の形態にかかるマスタノードおよびスレーブノードは、CPU(Central Processing Unit)51などの制御装置と、ROM(Read Only Memory)52やRAM53などの記憶装置と、ネットワークに接続して通信を行う通信I/F54と、HDD(Hard Disk Drive)、CD(Compact Disc)ドライブ装置などの外部記憶装置と、ディスプレイ装置などの表示装置と、キーボードやマウスなどの入力装置と、各部を接続するバス61を備えており、通常のコンピュータを利用したハードウェア構成となっている。
本実施の形態にかかるマスタノードおよびスレーブノードで実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでCD−ROM(Compact Disk Read Only Memory)、フレキシブルディスク(FD)、CD−R(Compact Disk Recordable)、DVD(Digital Versatile Disk)等のコンピュータで読み取り可能な記録媒体に記録されて提供される。
また、本実施の形態にかかるマスタノードおよびスレーブノードで実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、本実施の形態にかかるマスタノードおよびスレーブノードで実行されるプログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。
また、本実施の形態のプログラムを、ROM等に予め組み込んで提供するように構成してもよい。
本実施の形態にかかるマスタノードおよびスレーブノードで実行されるプログラムは、上述した各部(「検索要求受付部、プラン生成部、判定部、更新部、実行要求部、転送要求部、構成管理部、中間結果管理部、結果取得部」または「実行要求受付部、実行部、DB管理部、割当部、中間結果管理部、中間結果転送部、転送要求通知部、構成通知部」)を含むモジュール構成となっており、実際のハードウェアとしてはCPU51(プロセッサ)が上記記憶媒体からプログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、上述した各部が主記憶装置上に生成されるようになっている。