JP4352079B2 - 分散データベースから情報を検索するシステム、装置、および方法 - Google Patents

分散データベースから情報を検索するシステム、装置、および方法 Download PDF

Info

Publication number
JP4352079B2
JP4352079B2 JP2007085979A JP2007085979A JP4352079B2 JP 4352079 B2 JP4352079 B2 JP 4352079B2 JP 2007085979 A JP2007085979 A JP 2007085979A JP 2007085979 A JP2007085979 A JP 2007085979A JP 4352079 B2 JP4352079 B2 JP 4352079B2
Authority
JP
Japan
Prior art keywords
information
search
sequence
item
intermediate result
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2007085979A
Other languages
English (en)
Other versions
JP2008243078A (ja
Inventor
博 新名
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Original Assignee
Toshiba Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Toshiba Corp filed Critical Toshiba Corp
Priority to JP2007085979A priority Critical patent/JP4352079B2/ja
Priority to US12/046,022 priority patent/US8019778B2/en
Publication of JP2008243078A publication Critical patent/JP2008243078A/ja
Application granted granted Critical
Publication of JP4352079B2 publication Critical patent/JP4352079B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
    • G06F16/2471—Distributed queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2453—Query optimisation
    • G06F16/24534—Query rewriting; Transformation
    • G06F16/24542—Plan optimisation

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Computational Linguistics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Software Systems (AREA)
  • Mathematical Physics (AREA)
  • Fuzzy Systems (AREA)
  • Operations Research (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

この発明は、多数の件数からなるデータを所定件数ごとの複数の塊に分割し、塊ごとにネットワーク接続された複数のデータベースに登録し処理する水平分割された分散データベースで、与えられた検索条件に従い分散検索を行うシステム、装置、および方法に関するものである。
近年、ＸＭＬ（eXtensible Markup Language）などで記述された構造化文書情報を記憶・検索する構造化文書データベースが実現されている。構造化文書データベースに対する問合せは、Ｗ３Ｃ（World Wide Web Consortium）が標準化を進めているＸＱｕｅｒｙ（XML Query）という問合せ言語によって行われることが主流となっている。
テーブル形式によるデータ管理を目的としたＲＤＢ（Relational Database）の標準検索言語であるＳＱＬ（Structured Query Language）とは異なり、ＸＭＬデータを対象としたＸＱｕｅｒｙによる検索処理では、リスト状のデータ構造であるシーケンスデータを中間結果として取り扱う必要がある。
一方、多数の件数からなるデータを、例えば件数が均等となるように複数の塊に分割し、分割した塊ごとにネットワーク接続された複数のデータベースに登録して処理する水平分割型の分散データベースシステムが広く知られている。このような分散データベースシステムでＸＱｕｅｒｙによる検索処理を行った場合、中間結果であるシーケンスデータが、分割された複数のデータベース（物理ＤＢ）に部分結果（部分シーケンス）として散在しうる。そこで、これら部分シーケンスを論理的に統合したシーケンスである論理シーケンスとして扱う手段が必要となる。
オブジェクトデータベースに関しては、このような複数の部分シーケンスからなる論理シーケンスの構造と類似した構造を管理する技術が知られている（例えば、特許文献１）。この技術では、個別に存在する部分集合にＩＤを割り当て、割り当てたＩＤからなる集合を作成し、作成した集合に割当てたＩＤによって階層的な集合を含む集合を表現するような管理情報を作成して上記構造を管理する。
特許第２８２７５６２号公報
しかしながら、特許文献１のような方法により論理シーケンスを管理する場合、シーケンスの作成、参照などのシーケンスに関する一般的な操作を行う際には、必ず管理情報を参照する必要がある。すなわち、単体のデータベースで実行した場合には不要な、部分シーケンスに関する処理のオーバヘッドが発生するという問題があった。
本発明は、上記に鑑みてなされたものであって、分散データベースの検索で発生しうるシーケンスに関する処理負担を軽減することができるシステム、装置、および方法を提供することを目的とする。
上述した課題を解決し、目的を達成するために、本発明は、少なくとも１つの項目からなる複数の情報を分散して格納する複数のデータベースを、前記データベースごとに管理する複数の情報管理装置と、前記情報管理装置から前記情報を検索する検索装置とがネットワークを介して接続された検索システムであって、前記検索装置は、前記項目が満たすべき条件を含む検索要求を受付ける検索要求受付部と、前記項目に関連する前記データベースのデータ構造と、前記条件の種類と、取得すべき前記項目をリスト構造で表したシーケンス情報として得られる前記項目が前記データベースに分散して格納されているか否かを表す局所性情報とを対応づけて記憶する局所性記憶部と、受付けられた検索要求を解析し、前記シーケンス情報の取得要求、および複数の前記データベースから取得された前記シーケンス情報を統合した論理シーケンスの生成要求を含む前記データベースに対する処理要求である検索プランを生成するプラン生成部と、前記シーケンス情報として得られる前記項目のそれぞれについて、項目に関連する前記データベースのデータ構造と、項目が満たすべき前記条件の種類とに対応する前記局所性情報を前記局所性記憶部から取得し、取得した前記局所性情報から、前記シーケンス情報として得られる前記項目が前記データベースに分散して格納されているか否かを判定する判定部と、前記項目が複数の前記データベースに分散して格納されていないと判定された場合に、前記論理シーケンスの前記生成要求を削除して前記検索プランを更新する更新部と、更新された前記検索プランの実行要求を前記情報管理装置に対して通知する実行要求部と、を備え、前記情報管理装置は、前記データベースと、前記実行要求を前記検索装置から受付ける実行要求受付部と、受付けた前記実行要求に基づいて、前記データベースに対して前記検索プランを実行する実行部と、を備えたことを特徴とする。
また、本発明は、上記システムを実行することができる方法である。
また、本発明は、少なくとも１つの項目からなる複数の情報を分散して格納する複数のデータベースを、前記データベースごとに管理する複数の情報管理装置にネットワークを介して接続され、前記情報管理装置から前記情報を検索する検索装置であって、前記項目が満たすべき条件を含む検索要求を受付ける検索要求受付部と、前記項目に関連する前記データベースのデータ構造と、前記条件の種類と、取得すべき前記項目をリスト構造で表したシーケンス情報として得られる前記項目が前記データベースに分散して格納されているか否かを表す局所性情報とを対応づけて記憶する局所性記憶部と、受付けられた検索要求を解析し、前記シーケンス情報の取得要求、および複数の前記データベースから取得された前記シーケンス情報を統合した論理シーケンスの生成要求を含む前記データベースに対する処理要求である検索プランを生成するプラン生成部と、前記シーケンス情報として得られる前記項目のそれぞれについて、項目に関連する前記データベースのデータ構造と、項目が満たすべき前記条件の種類とに対応する前記局所性情報を前記局所性記憶部から取得し、取得した前記局所性情報から、前記シーケンス情報として得られる前記項目が前記データベースに分散して格納されているか否かを判定する判定部と、前記項目が複数の前記データベースに分散して格納されていないと判定された場合に、前記論理シーケンス情報の前記生成要求を削除して前記検索プランを更新する更新部と、更新された前記検索プランの実行要求を前記情報管理装置に対して通知する実行要求部と、を備えたことを特徴とする。
本発明によれば、分散データベースの検索で発生しうるシーケンスに関する処理負担を軽減することができるという効果を奏する。
以下に添付図面を参照して、この発明にかかる分散データベースから情報を検索するシステム、装置、および方法の最良な実施の形態を詳細に説明する。
本実施の形態にかかる検索システムは、分散データベースの検索過程で得られたシーケンスが物理ＤＢの１つに局所的に格納されているか、および検索結果として出力されるかを判定し、いずれかを満たす場合に、論理シーケンスを構成する処理を不要とするように検索プランを最適化するものである。
まず、分散データベースの検索処理で扱われるシーケンスの表現形式について図１から図４を用いて説明する。図１は、本実施の形態の検索システムの構成の一例を示す説明図である。図１に示すように、検索システムは、クライアント３００と、マスタノード１００と、複数のスレーブノードとを含んでいる。
クライアント３００は、スレーブノードに格納された情報の検索要求をマスタノード１００に送信するものであり、通常のＰＣ（Personal Computer）などにより構成される。
マスタノード１００は、クライアント３００の検索要求を受け付けて、スレーブノードから情報を検索する検索装置である。マスタノード１００の詳細については後述する。
スレーブノードは、データを水平分割して記憶するデータベースを分散して管理し、マスタノード１００からの要求に応じてデータ検索を行い、検索結果をマスタノード１００に返信する情報管理装置である。図１では、５つのスレーブノードの各物理ＤＢによって、１つの論理ＤＢ４１が構成された例が示されているが、論理ＤＢの構成はこれに限られるものではない。また、複数の論理ＤＢを備えるように検索システムを構成してもよい。
なお、マスタノード１００と、スレーブノードと、クライアント３００とを接続するネットワークは、インターネットやＶＰＮなどのあらゆるネットワーク形態により構成することができる。
図２は、入力される検索式の一例を示す説明図である。図２の検索式は、ＸＱｕｅｒｙの形式で記載された検索要求を表している。なお、同図の検索式は、図１の論理ＤＢ４１はユーザ情報を格納したデータベース「people」であること、および、論理ＤＢ４１の他に、図１に図示していないオークションに関する情報を格納した論理ＤＢ「auctions」が存在することを前提としている。
図３は、図２のような検索式により検索処理を行ったときに得られるシーケンスの表現形式の一例を示す説明図である。図３では、物理ＤＢ−１、物理ＤＢ−２、物理ＤＢ−３には、それぞれａ１ｎ、ａ２ｎ、ａ３ｎ（ｎは整数）で識別されるユーザのデータ（ｐｅｒｓｏｎ）が格納されていることが示されている。
このような構成では、論理ＤＢに対しては１つのシーケンスで表される中間結果が、複数の物理ＤＢに散在する部分シーケンスそれぞれに対応する場合が発生しうる。例えば、同図では、シーケンスＩＤ＝ｓ１に対応するシーケンスである「ａ１１、ａ１５、ａ２１、ａ３２」は、物理ＤＢ−１のシーケンス「ａ１１、ａ１５」（シーケンスＩＤ＝ｓ１１）、物理ＤＢ−２のシーケンス「ａ２１」（シーケンスＩＤ＝ｓ２１）、および物理ＤＢ−３のシーケンス「ａ３２」（シーケンスＩＤ＝ｓ３１）を統合したものであることが示されている。
このような場合、通常は、散在するシーケンスを１つの論理シーケンスとして扱うための管理情報（以下、論理シーケンス管理情報という。）を生成する必要がある。図４は、論理シーケンスを扱うための論理シーケンス管理情報の一例を示す説明図である。図４では、各物理ＤＢでのシーケンスＩＤと論理シーケンスＩＤとを対応づけた論理シーケンス管理情報の例が示されている。このような論理シーケンス管理情報により、例えば、シーケンスＩＤ＝ｓ１１、ｓ２１、ｓ３１に対応するシーケンスは独立して扱わずに、シーケンスＩＤ＝ｓ１で識別される１つのシーケンスとして扱うことを指定できる。
このように、分散データベースに対して、検索結果からリスト状のデータ構造（シーケンス）を構成するような検索条件を処理させる場合、一般的には、分散データベースを構成する各スレーブノード上に断片的な結果が散在して得られる。このような場合、散在する結果のリスト状データのうち、論理的には一体となるリスト状データ同士からなる組合せ情報を管理し、論理的なリスト状データを構成して処理する必要がある。
しかし、このような取り扱いを回避可能な状況も存在する。そこで、本実施の形態では、与えられた検索条件とスキーマ情報とＤＢ分割情報とから上記のような取り扱いの要否を判定し、検索プランの最適化を行う。これにより分散データベース環境で、検索結果データがリスト状のデータ構造をもつ場合の処理オーバヘッドを回避することが可能となる。
次に、マスタノード１００とスレーブノードの詳細な構成について図５〜図１４を用いて説明する。図５は、本実施の形態の検索システムの別の構成例を示す説明図である。図５以降では、それぞれ２つの物理ＤＢから構成される２つの論理ＤＢ「auctions」および「people」を含む検索システムを例として説明する。なお、ＤＢの構成はこれに限られず、３つ以上の物理ＤＢを含むように論理ＤＢを構成してもよい。また、３つ以上の論理ＤＢを含むように検索システムを構成してもよい。
図５に示すように、本実施の形態の検索システムは、クライアント３００と、マスタノード１００と、複数のスレーブノード２００ａ、２００ｂ、２００ｃ、２００ｄとを含んでいる。マスタノード１００、およびクライアント３００の構成は図１と同様であるので同一の符号を付し、説明は省略する。なお、スレーブノード２００ａ、２００ｂ、２００ｃ、２００ｄは、物理ＤＢ内に記憶する情報が異なる以外は同一の構成を有するため、以下では単にスレーブノード２００という場合がある。
図６および図７は、それぞれ論理ＤＢ「people」および「auctions」に格納される情報のデータ形式の一例を示す説明図である。図６および図７に示すように、以下ではＸＭＬ形式で情報が格納されていることを前提とする。
ＸＭＬ形式の情報（ＸＭＬデータ）はタグや属性をノードとする木構造として表現できる。図８および図９は、木構造で表したＸＭＬデータの一例を示す説明図である。図８は、「people」データベースに格納される「person」データを表している。また、図９は、「auctions」データベースに格納される「deal」データを表している。
データベース中では各データの木構造の各ノードにはそれぞれノードＩＤが割り当てて管理される。木のルートである「person」タグを示すノードにはノードＩＤとして900が割り当てられている。このノードＩＤは「people」データベース中でユニークであり、複数の「person」データが格納されている場合でも、このノードＩＤを指定することにより、「person」データを一意に特定することができる。
また、図８に示すように、「/person/watch/@category」属性（「person」タグの直下の子ノードである「watch」タグの直下に存在する「category」属性）は、同図の「person」データ中に２つ存在する。このような場合にも、各ノードに割り当てられているノードＩＤにより、それぞれを特定することができる。ＸＭＬデータの検索は、このように格納されているデータに関して、条件に合致するタグや属性といったノードのノードＩＤを取得する処理を行う一連のオペレータ列の処理を実行することで実現する。なお、オペレータとは、検索結果を求める過程で実行される処理の単位をいう。
図１０は、本実施の形態のマスタノード１００およびスレーブノード２００の詳細な構成を示すブロック図である。図１０に示すように、マスタノード１００は、記憶部１２０と、検索要求受付部１０１と、プラン生成部１０２と、判定部１０３と、更新部１０４と、実行要求部１０５と、転送要求部１０６と、構成管理部１０７と、中間結果管理部１０８と、結果取得部１０９と、を備えている。
記憶部１２０は、検索処理で参照する各種テーブルを格納するものである。具体的には、記憶部１２０は、スキーマテーブル１２１と、分割情報テーブル１２２と、局所性判定表１２３と、作成判定表１２４とを格納している。
スキーマテーブル１２１は、スレーブノード２００の物理ＤＢ２２０（後述）に格納する情報のデータ構造を定めたスキーマ情報を格納するものである。図１１および図１２は、スキーマテーブル１２１に格納されるスキーマ情報のデータ構造の一例を示す説明図である。図１１および図１２に示すように、スキーマテーブル１２１は、物理ＤＢ２２０に格納する情報に含まれる項目と、データ型と、一意性情報とを対応づけて格納している。
データ型には、例えば、ＩＤ型、文字列型、非負整数型、正整数型などのように、項目が取りうる値の形式を定める情報が設定される。一意性情報には、項目が論理データベース内で一意の値を取るか否かを表す情報が設定される。具体的には、一意の値を取る場合に「ユニーク型」が、それ以外の場合に「非ユニーク型」が設定される。
なお、図１１および図１２は、それぞれ「people」データベースおよび「auctions」データベースに格納される情報のスキーマ情報を表している。
図１０に戻り、分割情報テーブル１２２は、格納する物理ＤＢ２２０を判定するための分割基準を規定する分割情報を格納するものである。図１３および図１４は、分割情報のデータ構造の一例を示す説明図である。図１３および図１４は、それぞれ「people」データベースおよび「auctions」データベースについての分割情報を表している。
例えば、図１３では、「people」データベースには、ユニーク型の項目「/person/@id」の値が所定の閾値より大きいか否かによって格納する物理ＤＢ２２０を判定する分割基準が定められている。同様に、図１４では、「auctions」データベースには、ユニーク型の項目「/deal/@id」の値が所定の閾値より大きいか否かによって格納する物理ＤＢ２２０を判定する分割基準が定められている。
なお、スレーブノードＩＤとは、情報の格納先となるスレーブノード２００を識別する情報である。以下では、スレーブノード２００ａ、２００ｂ、２００ｃ、２００ｄのスレーブノードＩＤは、それぞれ１、２、３、４であるものとする。
局所性判定表１２３は、検索処理の過程で得られたシーケンスが、複数の物理ＤＢ２２０に分散して格納されているか否かを表す局所性情報を判定する規則を格納するものである。また、作成判定表１２４は、論理シーケンス管理情報を作成するか否かを判定する規則を格納するものである。
局所性判定表１２３および作成判定表１２４は、後述する判定部１０３が論理シーケンス管理情報を作成するか否かを判定するときに参照するものであるため、各表の詳細は判定部１０３の機能と合わせて説明する。
なお、記憶部１２０は、ＨＤＤ（Hard Disk Drive）、光ディスク、メモリカード、ＲＡＭ（Random Access Memory）などの一般的に利用されているあらゆる記憶媒体により構成することができる。
図１０に戻り、検索要求受付部１０１は、クライアント３００から送信された検索要求を受付けるものである。本実施の形態では、検索要求受付部１０１は、ＸＱｕｅｒｙによる検索式を検索要求として受付ける。
図１５は、ＸＱｕｅｒｙによる検索式の一例を示す説明図である。図１５の検索式は、商品カテゴリ番号が「１２３４５」である商品（item）に関するオークションデータ（deal）を取り出し、そのオークション商品の関連商品カテゴリ（related/@category）に興味のあるユーザのＩＤ（@id）を、その関連商品カテゴリごとにひとまとめにして取り出し、さらに、そのユーザが商品を購入したオークションデータ（deal）を出力することを表している。
プラン生成部１０２は、検索要求受付部１０１が受付けた検索式、および分割情報テーブル１２２を参照して、検索処理の実行計画である検索プランを生成するものである。具体的には、プラン生成部１０２は、オペレータ、各オペレータ間のデータの受け渡し依存関係、およびオペレータを実行するスレーブノード２００の割り当てを示す検索プランを生成する。
図１６は、プラン生成部１０２が生成する検索プランの一例を示した説明図である。図１６は、図１５に示すような検索式に対応して生成される検索プランの例を表している。この時点では、論理シーケンス管理情報の作成が不要であるか否かを判定していないため、論理シーケンス管理情報を登録する「registSequence」オペレータが２つ含まれている。
なお、「createTable」などは各オペレータの名称を表している。また、例えばオペレータ名の後の「Slave1」は、スレーブノードＩＤ＝１のスレーブノード２００で実行されるオペレータであることを表している。また、「ＢＴ０」などは中間結果を識別する中間結果ＩＤを表している。そして、記号「->」は、オペレータの実行結果が記号の右側の中間結果ＩＤで識別される中間結果として出力されることを表している。
判定部１０３は、局所性判定表１２３および作成判定表１２４を参照し、論理シーケンス管理情報を作成するか否かを判定するものである。判定部１０３による判定処理では、局所性情報および用途情報が利用される。
局所性情報とは、上述のように、シーケンスが、複数の物理ＤＢ２２０に分散して格納されているかを表す情報である。言い換えると、局所性情報は、あるスレーブノード２００で得られたシーケンスが他のスレーブノード２００上で得られたシーケンスとともに論理シーケンスとして結合されるか否か示す情報である。用途情報とは、検索処理中に得られたシーケンスを一体の論理シーケンスとして参照する必要があるか否かを示す情報である。
まず、局所性情報の求め方について説明する。判定部１０３は、局所性判定表１２３を参照することにより局所性情報を判定する。まず、判定部１０３は、得られたシーケンスのデータ属性と条件値タイプを取得する。
データ属性とは、シーケンスとして得られた項目の属性を表すものである。データ属性には、項目の一意性情報（ユニーク型か、非ユニーク型か）、および項目が物理ＤＢ２２０に分散して格納するときの判断基準として参照されるか否かを表す情報（レンジ分割対象か、非レンジ分割対象か）が含まれる。一意性情報は、図１１および図１２のスキーマテーブル１２１から取得できる。レンジ分割対象か非レンジ分割対象かは、図１３および図１４の分割情報テーブル１２２の分割基準を参照することにより判断できる。
条件値タイプとは、検索条件の中でシーケンスが満たすべき条件の種類を表すものである。条件値タイプとしては、条件値が定数か変数か、および条件値が単独値かシーケンス値かによって、「定数単独値」、「変数単独値」、「定数シーケンス値」、および「変数シーケンス値」の４つの種類が存在する。
条件値が定数か変数かは、検索式を解析することにより判断する。例えば、図１５のような検索式では、１行目の条件値である「１２３４５」は定数であると判断できる。また、２行目の条件値である「＄ｘ」は、１行目で定義された変数であると判断できる。
さらに、判定部１０３は、条件値が単独値かシーケンス値かを検査する。具体的には、判定部１０３は、条件値が定数である場合は、その定数が単独値かシーケンス値かを検索式を解析することにより判断する。また、判定部１０３は、条件値が変数である場合は、検索式中でその条件値が作成される箇所を辿り、シーケンス値を示す変数であるかを判断する。
次に、判定部１０３は、求めたデータ属性と条件値タイプとに対応する局所性情報を、図１７のような局所性判定表１２３から取得することにより、局所性情報を判定する。図１７は、局所性判定表１２３のデータ構造の一例を示す説明図である。判定部１０３は、データ属性および条件値タイプの組合せによって局所性情報を以下のように判定する。
（１）局所性情報「あり」と判定する場合：
（ａ）データ属性が「ユニーク型」または「レンジ分割対象」であり、かつ、条件値タイプが「単独値」である場合。
（ｂ）データ属性が「レンジ分割対象」であり、かつ、条件値タイプが「定数シーケンス値」であり、そのシーケンスに含まれる値がＤＢ分割情報に照らして１つのスレーブに含まれる場合。
（２）局所性情報「不明」と判定する場合：なお、この場合は、検索処理時に条件値を個別に判断して局所性情報が判断される。
（ａ）データ属性が「レンジ分割対象」であり、かつ、条件値タイプが「変数シーケンス値」である場合。
（３）局所性情報「なし」と判定する場合：なお、局所性情報「なし」とは、条件値を参照しても２２０に分散して格納されているか否かを判別できないことを表す。
（ａ）データ属性が「非ユニーク型」かつ「非レンジ分割対象」である場合。
（ｂ）データ属性が「ユニーク型」であり、かつ、条件値タイプが「シーケンス値」である場合。
（ｃ）データ属性が「レンジ分割対象」であり、かつ、条件値タイプが「定数シーケンス値」であり、そのシーケンスに含まれる値がＤＢ分割情報に照らして複数のスレーブノード２００にまたがる場合。
次に、用途情報の求め方について説明する。ＸＱｕｅｒｙの検索式中の中間結果の依存関係は、変数を用いた値の受け渡してとして表現される。例えば、図１５の検索式では、中間結果として「＄ｘ」および「＄ａ」が存在し、「＄ｘ」と「＄ａ」との依存関係は、２行目の式によって表される。
判定部１０３は、このような受け渡し関係を辿ることにより、検索式中で作成される個別のシーケンスが、（１）検索式の最終出力結果の一部となる場合、用途情報＝出力シーケンスと判断する。また、判定部１０３は、個別のシーケンスが、（２）検索式の最終出力結果の一部とならない場合、用途情報＝参照シーケンスと判断する。
図１５の例では、作成されるシーケンスの１つである「＄ｂ」は、最終行の式「return $b」で示されるように、検索式の最終出力結果であると判断できるため、判定部１０３は、用途情報＝出力シーケンスであると判定する。一方、「＄ａ」は、「return」式で出力されるシーケンスではないため、判定部１０３は、用途情報＝参照シーケンスであると判定する。
このようにして、判定部１０３は、局所性情報と用途情報とを求める。そして、判定部１０３は、求めた局所性情報と用途情報とを、図１８のような作成判定表１２４と照合することにより、論理シーケンス管理情報を作成するか否かを判定する。図１８は、作成判定表１２４のデータ構造の一例を示す説明図である。判定部１０３は、論理シーケンス管理情報の作成有無を、用途情報および局所性情報の組合せによって以下のように判定する。
（１）論理シーケンス管理情報を常に作成しないと判定する場合：
（ａ）用途情報が「参照シーケンス」である場合。
（ｂ）用途情報が「出力シーケンス」であり、かつ、局所性情報が「あり」である場合。
（２）論理シーケンス管理情報を作成するか否かを検索処理実行時に条件値を個別に参照して判断すると判定する場合：
（ａ）用途情報が「出力シーケンス」であり、かつ、検索条件に局所性情報が「不明」である場合。
（３）論理シーケンス管理情報を作成すると判定する場合：
（ａ）用途情報が「出力シーケンス」であり、かつ、局所性情報が「なし」の場合。
図１０に戻り、更新部１０４は、判定部１０３によって論理シーケンス管理情報を作成しないと判定されたシーケンスについて、論理シーケンス管理情報を登録するオペレータ（「registSequence」オペレータ）を省略した検索プランを生成し、生成済みの検索プランを更新するものである。
図１９は、更新部１０４により更新された後の検索プランの一例を示す説明図である。図１９は、判定部１０３の結果にしたがい、図１５のような検索式で最初に得られるシーケンスである「＄ａ」に対する「registSequence」オペレータを削除した検索プランの例を表している。
このように、更新部１０４によって、論理シーケンス管理情報を作成する必要がない場合は作成処理を行わないように検索プランの最適化を行うことができるため、検索処理のオーバヘッドを削減することが可能となる。
実行要求部１０５は、スレーブノード２００に対して検索プランを送信することによって検索プランの実行を要求するものである。
転送要求部１０６は、あるスレーブノード２００から中間結果の転送要求を受信したとき、実行可能な転送要求を決定して、転送元のスレーブノード２００に対して転送要求を通知するものである。具体的には、転送要求部１０６は、スレーブノード２００の転送要求通知部２０７（後述）から、中間結果の転送要求を受信して記憶部１２０などに記録する。また、転送要求部１０６は、スレーブノード２００の中間結果作成通知を受けて記録する処理も行う。
図２０は、中間結果の転送要求のデータ構造の一例を示す説明図である。図２０に示すように、中間結果の転送要求には、転送元のスレーブノード２００を識別する転送元スレーブノード情報と、転送先のスレーブノード２００を識別する転送先スレーブノード情報と、転送する中間結果を識別する中間結果ＩＤとが含まれる。
構成管理部１０７は、スレーブノード２００の構成通知部２０８（後述）から各スレーブノード２００のシーケンスＩＤを含む論理シーケンス管理情報を受信して管理するものである。図２１は、論理シーケンス管理情報のデータ構造の一例を示す説明図である。
図２１に示すように、論理シーケンス管理情報には、論理シーケンスを一意に識別する論理シーケンスＩＤと、部分シーケンスＩＤと、シーケンスＩＤを生成したスレーブノード２００のスレーブノードＩＤと、中間結果ＩＤと、キーＩＤとが含まれる。なお、中間結果ＩＤとは、シーケンスを構成する要素の値が格納されている中間結果を識別する識別情報をいう。
部分シーケンスＩＤとは、スレーブノード２００ごとに生成される物理的なシーケンスＩＤをいう。図２２は、部分シーケンスＩＤのデータ構造の一例を示す説明図である。図２２に示すように、部分シーケンスＩＤは、シーケンスを生成するスレーブノード２００のスレーブノードＩＤと、中間結果ＩＤと、中間結果中のカラムを識別するカラム番号と、中間結果中のレコードを識別するレコード番号と、局所シーケンスフラグとを対応づけたデータ構造となっている。
局所シーケンスフラグとは、シーケンスが分散して格納されているかを表すフラグであり、判定部１０３が判定した局所性情報が「あり」のとき「１」、「なし」のとき「０」が設定される。
キーＩＤとは、論理シーケンスを構成するために物理的なシーケンスをグループ化するときのキーとなる情報である。図２３は、キーＩＤのデータ構造の一例を示す説明図である。図２３に示すように、キーＩＤは、中間結果の入力元のスレーブノード２００のスレーブノードＩＤと、入力元の中間結果ＩＤと、入力元の中間結果内の中間結果レコード番号とを対応づけたデータ構造となっている。
中間結果管理部１０８は、各スレーブノード２００の中間結果転送部２０６によって転送された中間結果を受信し、図示しないＲＡＭなどの記憶媒体に保存することにより管理するものである。
結果取得部１０９は、最終的に出力された中間結果を元に各スレーブノード２００からシーケンスの実体データを検索結果として取得して、クライアント３００に送信するものである。
次に、スレーブノード２００について説明する。図１０に示すように、スレーブノード２００は、物理ＤＢ２２０と、実行要求受付部２０１と、実行部２０２と、ＤＢ管理部２０３と、割当部２０４と、中間結果管理部２０５と、中間結果転送部２０６と、転送要求通知部２０７と、構成通知部２０８と、を備えている。
物理ＤＢ２２０は、水平分割された文書を記録する記憶媒体である。本実施の形態では、図６〜図９で説明したように、物理ＤＢ２２０はＸＭＬ形式の文書を格納する。なお、物理ＤＢ２２０は、ＨＤＤ、光ディスク、メモリカード、ＲＡＭなどの一般的に利用されているあらゆる記憶媒体により構成することができる。
実行要求受付部２０１は、マスタノード１００から送信された検索プランの実行要求を受付けるものである。なお、実行要求には実行すべき検索プランが含まれる。
実行部２０２は、実行要求受付部２０１が受付けた実行要求に従い、実行が要求された検索プランを実行するものである。実行部２０２は、まず、検索プランから、実行可能状態テーブルを作成する。実行可能状態テーブルとは、検索プランに記述されたオペレータの入出力依存関係に従い、オペレータを実行するために必要な中間結果の状態に関する条件を定めたテーブルである。
図２４および図２５は、実行可能状態テーブルのデータ構造の一例を示す説明図である。図２４は、図１９に示すような検索プランに対して、スレーブノードＩＤ＝１および２のスレーブノード２００で作成される実行可能状態テーブルの一例を示している。また、図２５は、図１９に示すような検索プランに対して、スレーブノードＩＤ＝３および４のスレーブノード２００で作成される実行可能状態テーブルの一例を示している。
具体的には、実行可能状態テーブルは、入力されるべき中間結果を表す入力中間結果と、入力中間結果が入力されたときに実行可能なオペレータを表す実行オペレータと、オペレータが実行可能か否かを表す実行可能情報とを対応づけて格納している。すなわち、実行可能状態テーブルは、実行するオペレータごとに実行に必要な前提条件である中間結果を表したものである。なお、入力中間結果が「---」となっているオペレータは、実行に必要な中間結果が存在しないオペレータを表す。
実行可能情報には、必要な中間結果が不要な場合、または必要な中間結果が作成済みのため実行可能な場合に「１」が設定される。また、必要な中間結果が作成されていないため実行不可能な場合に「０」が設定される。また、オペレータが実行済みの場合に「２」が設定される。なお、実行可能情報の設定方法はこれに限られるものではなく、次に実行可能なオペレータを判断可能な方法であればあらゆる方法を適用できる。
実行部２０２は、このような実行可能状態テーブルを参照し、実行可能情報が「１」であるオペレータから次に実行すべきオペレータを選択して実行する。なお、次に実行すべきオペレータが尽きた場合に検索処理は終了する。そして、このときに各スレーブノード２００上に残った中間結果が最終的な検索結果として得られる。
なお、実行部２０２は、検索要求に応じた検索プランに含まれうる様々なオペレータに関する処理を実行するものであるが、主に以下のような処理を実行する。
まず、実行部２０２は、オペレータ実行に際し、データベースを管理するＤＢ管理部２０３（後述）に対してデータ取得に関する処理を実行させる。そして、実行部２０２は、オペレータの実行結果情報を、中間結果管理部２０５（後述）が管理する中間結果データに記録する。
また、実行部２０２は、各オペレータを実行し終わると、その結果得られた中間結果が作成済みであることを中間結果作成状態テーブルに記録する。図２６は、中間結果作成状態テーブルのデータ構造の一例を示す説明図である。図２６に示すように、中間結果作成状態テーブルには、作成済みの中間結果の中間結果ＩＤが格納される。
その後、実行部２０２は中間結果作成状態テーブル上で更新された情報をもとに、実行可能状態テーブルの実行可能情報を更新する。すなわち、中間結果作成状態テーブルに追加された中間結果ＩＤに対応する実行可能情報を、実行済みを表す「２」に更新する。
オペレータ実行時、実行部２０２は、スレーブノード２００上の物理ＤＢ２２０および中間結果管理部２０５が管理している中間結果を対象として処理を行う。ただし、中間結果の転送要求を行うオペレータの場合は、実行部２０２は、転送要求通知部２０７に対して処理を行う。
図１０に戻り、ＤＢ管理部２０３は、物理ＤＢ２２０に対するインデックススキャン、データベーススキャンなどの各種データ取得操作を実行するものである。
割当部２０４は、実行部２０２の指示によって、中間結果として生成されたシーケンスを識別するシーケンスＩＤを割り当てるものである。
中間結果管理部２０５は、生成された中間結果を管理するものである。具体的には、中間結果管理部２０５は、検索プランの実行に伴って生成された中間結果を、図示しないＲＡＭなどの記憶媒体に保存することにより管理する。また、中間結果が転送されたときには、中間結果管理部２０５は、転送された中間結果の複製を作成して記憶媒体に保存する。
中間結果転送部２０６は、他のスレーブノード２００からの中間結果の転送要求を、マスタノード１００の転送要求部１０６を介して受信し、転送要求にしたがって他のスレーブノード２００に対して中間結果を転送するものである。
具体的には、中間結果転送部２０６は、まず転送先スレーブノード情報と中間結果ＩＤとを転送要求から取得する。そして、中間結果転送部２０６は、中間結果ＩＤを参照して転送すべき中間結果を、中間結果管理部２０５を介して記憶媒体から取得する。次に、中間結果転送部２０６は、取得した中間結果を指定された転送先スレーブノード情報で識別されるスレーブノード２００に転送する。
転送要求通知部２０７は、オペレータが中間結果の転送要求を送信するものである場合に、マスタノード１００の転送要求部１０６に指定された中間結果の転送要求を通知するものである。
構成通知部２０８は、割当部２０４によって割り当てられたシーケンスＩＤを含む論理シーケンス管理情報を、マスタノード１００の構成管理部１０７に通知するものである。
次に、このように構成された本実施の形態にかかる検索システムによる検索処理について図２７を用いて説明する。図２７は、本実施の形態における検索処理の全体の流れを示すフローチャートである。
まず、検索要求受付部１０１は、クライアント３００からＸＱｕｅｒｙの検索式を検索要求として受付ける（ステップＳ２７０１）。次に、プラン生成部１０２は、受付けた検索式を解析して、検索プランを生成する（ステップＳ２７０２）。
次に、生成された検索プランから、不要な論理シーケンス管理情報を生成するオペレータを削除して検索プランを最適化する検索プラン最適化処理が実行される（ステップＳ２７０３）。検索プラン最適化処理の詳細については後述する。
次に、実行要求部１０５は、各スレーブノード２００に対して、実行すべき検索プランの実行要求を通知する（ステップＳ２７０４）。
スレーブノード２００の実行要求受付部２０１は、通知された実行要求を受付ける（ステップＳ２７０５）。次に、実行部２０２が、受付けた実行要求に含まれる検索プランを参照して図２５または図２６に示すような実行可能状態テーブルを作成する（ステップＳ２７０６）。
次に、実行部２０２は、実行可能状態テーブルを参照してオペレータごとの実行可能性を判断し、実行できるオペレータを選択する（ステップＳ２７０７）。
次に、実行部２０２は、論理シーケンスを生成するために論理シーケンス管理情報を通知するオペレータ（「registSequence」オペレータ）であるか否かを判断する（ステップＳ２７０８）。論理シーケンス管理情報を通知するオペレータである場合は（ステップＳ２７０８：ＹＥＳ）、構成通知部２０８は、論理シーケンス管理情報をマスタノード１００に通知する（ステップＳ２７０９）。なお、構成通知部２０８は、それ以前に実行されたオペレータに関連する処理で割当部２０４によって生成されたシーケンスＩＤを含む論理シーケンス管理情報をマスタノード１００に通知する。
マスタノード１００の構成管理部１０７は、通知された論理シーケンス管理情報を受信してマスタノード１００上の論理シーケンス管理情報に追加登録する（ステップＳ２７１０）。
ステップＳ２７０８で論理シーケンス管理情報を通知するオペレータでないと判断された場合は（ステップＳ２７０８：ＮＯ）、実行部２０２は、選択したオペレータを実行する（ステップＳ２７１１）。なお、上述のように、このステップでは中間結果の転送を含むさまざまなオペレータが実行されうるが、説明の便宜上、同図では省略している。
次に、実行部２０２は、オペレータの実行結果を中間結果作成状態テーブルに追加するとともに、実行可能状態テーブルの実行可能情報を更新する（ステップＳ２７１２）。
次に、実行部２０２は、実行可能状態テーブルを参照してすべてのオペレータが実行されたか否かを判断する（ステップＳ２７１３）。すべてのオペレータが実行されていない場合は（ステップＳ２７１３：ＮＯ）、次に実行可能なオペレータを選択して処理を繰り返す（ステップＳ２７０７）。
すべてのオペレータが実行された場合は（ステップＳ２７１３：ＹＥＳ）、実行部２０２は、処理結果をマスタノード１００に送信する（ステップＳ２７１４）。
マスタノード１００の結果取得部１０９は、各スレーブノード２００からの処理結果を統合した検索結果を生成する（ステップＳ２７１５）。そして、結果取得部１０９は、生成した検索結果をクライアント３００に送信して（ステップＳ２７１６）検索処理を終了する。
次に、ステップＳ２７０３の検索プラン最適化処理の詳細について図２８を用いて説明する。図２８は、本実施の形態における検索プラン最適化処理の全体の流れを示すフローチャートである。
まず、判定部１０３は、検索式を解析し、オペレータの処理結果として得られるシーケンスを取得する（ステップＳ２８０１）。例えば、図１５に示すような検索式の場合、「＄ａ」および「＄ｂ」が、シーケンスの処理結果として得られることが解析される。
次に、判定部１０３は、取得したシーケンスの用途情報が参照シーケンスか否かを判断する（ステップＳ２８０２）。上述のように、判定部１０３は、検索式内の値の受け渡し関係を解析することによりシーケンスの用途情報を判定する。図１５の例では、「＄ａ」および「＄ｂ」の用途情報はそれぞれ「参照シーケンス」および「出力シーケンス」と判定される。
用途情報が参照シーケンスでない場合、すなわち出力シーケンスの場合は（ステップＳ２８０２：ＮＯ）、判定部１０３は、ステップＳ２８０３からステップＳ２８０８で、上述のような判定表を用いた論理シーケンス管理情報の作成有無の判定処理を行う。
まず、判定部１０３は、スキーマテーブル１２１を参照し、シーケンスの一意性情報を取得する（ステップＳ２８０３）。次に、判定部１０３は、分割情報テーブル１２２を参照し、シーケンスがレンジ分割対象か、非レンジ分割対象かを決定する（ステップＳ２８０４）。
次に、判定部１０３は、検索式を解析し、シーケンスと比較する条件値が定数か変数かを決定する（ステップＳ２８０５）。続いて、判定部１０３は、条件値が単独値かシーケンス値かを決定する（ステップＳ２８０６）。
次に、判定部１０３は、決定したデータ属性（一意性情報、およびレンジ分割対象か非レンジ分割対象かを表す情報）、および決定した条件値タイプ（定数か変数か、および単独値かシーケンス値か）に従い、局所性判定表１２３を参照して局所性情報を判定する（ステップＳ２８０７）。
次に、判定部１０３は、判定された局所性情報と作成判定表１２４とを参照し、論理シーケンス管理情報の作成有無を判定する（ステップＳ２８０８）。例えば、図１８のような作成判定表１２４によれば、局所性情報ありと判定された場合であれば、用途情報が出力シーケンスであっても、論理シーケンス管理情報の作成は不要と判定される。
ステップＳ２８０２で、用途情報が参照シーケンスであると判断された場合は（ステップＳ２８０２：ＹＥＳ）、判定部１０３は、論理シーケンス管理情報を作成しないと判定する（ステップＳ２８０９）。参照シーケンスの場合は、出力用に論理シーケンスを構成する必要がないため、常に論理シーケンス管理情報の作成は不要と判定することができるためである。
次に、更新部１０４は、論理シーケンス管理情報の作成が不要である判定されたか否かを判断する（ステップＳ２８１０）。不要と判定された場合は（ステップＳ２８１０：ＹＥＳ）、更新部１０４は、不要と判定されたシーケンスに対応して論理シーケンス管理情報を通知するオペレータを検索プランから削除することにより、検索プランを更新する（ステップＳ２８１１）。
検索プランの更新後、または、ステップＳ２８１０で、論理シーケンス管理情報の作成が不要でないと判定された場合は（ステップＳ２８１０：ＮＯ）、判定部１０３は、検索式内のすべてのシーケンスを処理したか否かを判断する（ステップＳ２８１２）。
すべてのシーケンスを処理していない場合は（ステップＳ２８１２：ＮＯ）、次のシーケンスを取得して処理を繰り返す（ステップＳ２８０１）。すべてのシーケンスを処理した場合は（ステップＳ２８１２：ＹＥＳ）、検索プラン最適化処理を終了する。
このように、検索プラン最適化処理によって、論理シーケンス管理情報の作成が不要な場合には論理シーケンス管理情報を通知するオペレータが検索プランから削除される。これにより、従来はすべてのシーケンスに対して図２７のステップＳ２７０９のように論理シーケンス管理情報を通知するオペレータが実行されていたのに対し、本実施の形態では不要なオペレータの実行を回避して検索処理の処理負担を軽減することが可能となる。
次に、本実施の形態による検索処理の具体例について説明する。なお、以下では、「registSequence」オペレータを削除することにより、論理シーケンス管理情報を作成しない検索プランに最適化された場合であっても、検索式を満たす検索結果が正しく得られる例について説明する。
また、以下では、図５の構成を前提とし、マスタノード１００の記憶部１２０には、図１１〜図１４のようなテーブルと、図１７および図１８のような判定表とが記憶され、図１５に示すような検索式が入力された場合を例として説明する。
なお、図２９〜図５２、図５４〜図６０、および図６２〜図６４は、この例で出力される中間結果の一例を示す説明図である。また、図５３および図６１は、この例で出力される論理シーケンス管理情報の一例を示す説明図である。
この場合、上述のように、プラン生成部１０２は、図１９に示すような最適化された検索プランを生成する。そして、生成された検索プランに従い、以下の手順で検索処理が実行される。
まず、スレーブノード１の実行要求受付部２０１は、マスタノード１００の実行要求部１０５からスレーブノード１で実行する検索プランを受け取る。
なお、スレーブノード１とは、それぞれスレーブノードＩＤ＝１であるスレーブノード２００を表す。以下、同様に、スレーブノードＩＤ＝２、３および４であるスレーブノード２００を、それぞれスレーブノード２、３およびスレーブノード４という。
スレーブノード１の実行部２０２は、実行要求受付部２０１から検索プランを受け取る。実行部２０２は、受け取った検索プランに記述されたオペレータに関して、入力の中間結果を条件として実行可能条件を表現する図２２のような実行可能状態テーブルを作成する。また、同時に中間結果作成状態テーブルを作成する。なお、初期状態では、中間結果作成状態テーブルにはいずれの中間結果も設定されない。スレーブノード２、スレーブノード３およびスレーブノード４でも、同様に実行部２０２による処理が行われる。
次に、スレーブノード１の実行部２０２は、実行するオペレータを選択する。この時点では、入力すべき中間結果が存在しないため無条件で実行可能である「createTable」オペレータと「request」オペレータが実行可能である。ここでは、実行部２０２は、まず「request」オペレータを選択するものとする。
実行部２０２は、中間結果ＢＴ３の転送要求を行う「request」オペレータを実行する。「request」オペレータの実行により、スレーブノード１の転送要求通知部２０７に対して、転送要求通知処理の実行が要求される。転送要求通知部２０７は、マスタノード１００の転送要求部１０６へ転送要求を通知する。マスタノード１００上の転送要求部１０６は、通知された転送要求を受け取り、管理用のテーブルなどに記録することにより転送要求を管理する。スレーブノード２でも同様に中間結果ＢＴ３の転送要求を行うオペレータが実行される。また、スレーブノード３およびスレーブノード４でも、同様の手順によって中間結果ＢＴ２の転送要求を行う「request」オペレータが実行される。
さらに、スレーブノード１の実行部２０２はオペレータ選択を行い、「createTable」オペレータを選択する。実行部２０２は、検索式で与えられた定数値を記録する中間結果を作成する「createTable」オペレータを実行し、得られた中間結果ＢＴ１を中間結果管理部２０５によって記録する。
この「createTable」オペレータでは、実行部２０２は、指定された定数値をもつ中間結果を作成する処理を行う。この例では、図１５の検索式のように、定数値として「１２３４５」が指定されている。このため、オペレータ実行の結果、図２９に示す中間結果が作成される。作成された中間結果は１カラムかつ１レコードであり、そのカラム値は「１２３４５」である。
また、実行部２０２は、作成済み中間結果として、ＢＴ１を中間結果作成状態テーブルに記録する。さらに、実行部２０２は、中間結果作成状態テーブル上で更新された情報をもとに、実行可能状態テーブルの実行可能情報を実行済み（２）に更新する。
更新された実行可能状態テーブルを参照し、スレーブノード１の実行部２０２は、実行可能なオペレータとして「select」オペレータを選択し、「select」オペレータを実行する。ここでの「select」オペレータは、図２９の中間結果ＢＴ１のカラム「col1」の値を入力とし、「auctions」データベースに格納されている「deal」データ中の「/deal/item/@category」ノードのうち、入力値「１２３４５」と合致する値をもつノードを検索し、そのノードＩＤを取得する処理を示している。
実行部２０２は、新たに中間結果ＢＴ１００を作成し、「select」オペレータにより取得された値を中間結果ＢＴ１００のカラム「category」に記録する。さらに作成したＢＴ１００を中間結果管理部２０５によって記録する。「select」オペレータの実行の結果、図３０に示す中間結果が作成される。図３０に示すように、「category」カラム値として、「001」と「002」の２つのノードＩＤが得られている。実行部２０２は、作成済み中間結果として、中間結果ＢＴ１００を中間結果作成状態テーブルに記録する。実行部２０２は中間結果作成状態テーブル上で更新された情報をもとに、実行可能状態テーブルの実行可能情報を更新する。
更新された実行可能状態テーブルを参照し、スレーブノード１の実行部２０２は実行可能なオペレータとして「scanAncestor」オペレータを選択し、「scanAncestor」オペレータを実行する。ここでの「scanAncestor」オペレータは、図３０に示す中間結果ＢＴ１００の「category」カラムの値を入力として取り、「auctions」データベースに格納されている「deal」データ中の「/deal」ノードのうち、入力値が示すノード「/deal/item/@category」の祖先ノードとなるノードＩＤを取得する処理を示している。
実行部２０２は、新たに中間結果ＢＴ１０１を作成し、「scanAncestor」オペレータにより取得された値を中間結果ＢＴ１０１のカラム「deal」に記録する。実行部２０２は、さらに作成した中間結果ＢＴ１０１を中間結果管理部２０５によって記録する。この場合、図３１に示すように、「@category」カラムの値「001」および「002」が示すノードの祖先ノードとして、「deal」カラムの値「003」および「004」がそれぞれ得られる。
実行部２０２は、作成済み中間結果として、中間結果ＢＴ１０１を中間結果作成状態テーブルに記録する。実行部２０２は中間結果作成状態テーブル上で更新された情報をもとに、実行可能状態テーブルの実行可能情報を更新する。
更新された実行可能状態テーブルを参照し、スレーブノード１の実行部２０２は実行可能なオペレータとして「scanDescendant」オペレータを選択し、「scanDescendant」オペレータを実行する。ここでの「scanDescendant」オペレータは、図３１に示す中間結果ＢＴ１０１の「deal」カラムの値を入力とし、「auctions」データベースに格納されている「deal」データ中の「/deal/related/@category」ノードのうち、入力値が示すノード「/deal」の子孫ノードとなるノードのノードＩＤを取得する処理を示している。
実行部２０２は、新たに中間結果ＢＴ２を作成し、「scanDescendant」オペレータにより取得された値を中間結果ＢＴ２のカラム「category2」に記録する。さらに作成したＢＴ２を中間結果管理部２０５によって記録する。この場合、図３２に示すように、「deal」カラムの値「003」の子孫ノードとして「category2」カラムの値「005」および「006」の２値、「004」の子孫ノードとして「category2」カラムの値「007」および「008」の２値が得られる。
実行部２０２は、作成済み中間結果として、中間結果ＢＴ２を中間結果作成状態テーブルに記録する。実行部２０２は中間結果作成状態テーブル上で更新された情報をもとに、実行可能状態テーブルの実行可能情報を更新する。
更新された実行可能状態テーブルを参照し、スレーブノード１の実行部２０２は実行可能なオペレータとして「notify」オペレータを選択し、「notify」オペレータを実行する。ここでの「notify」オペレータは、中間結果ＢＴ２が作成済み状態であることを示す中間結果作成通知をマスタノード１００の転送要求部１０６に通知する。
同様にして、スレーブノード２でも、実行部２０２が、スレーブノード１におけるここまでの一連の処理と同様の流れでオペレータを実行する。「createTable」オペレータの実行により図３３に示すＢＴ１が生成される。次に「select」オペレータの実行により図３４に示すＢＴ１００が生成される。次に「scanAncestor」オペレータの実行により図３５に示すＢＴ１０１が生成される。次に「scanDescendant」オペレータの実行により図３６に示すＢＴ２が生成される。その後、「notify」オペレータの実行により、スレーブノード２の実行部２０２は、中間結果ＢＴ２が作成済み状態であることを示す中間結果作成通知をマスタノード１００の転送要求部１０６に通知する。
次に、マスタノード１００上の転送要求部１０６は、これまでに受け取った中間結果作成通知および転送要求通知をマッチングし、実行が可能な転送要求を決定する。この場合、スレーブノード１およびスレーブノード２で中間結果ＢＴ２が作成済みであるので、スレーブノード３とスレーブノード４に対して、それぞれの中間結果ＢＴ２の転送が可能である決定できる。
マスタノード１００の転送要求部１０６は、転送する中間結果ＢＴ２を格納している転送元スレーブノード２００の中間結果転送部２０６に対して転送要求を通知して、中間結果の転送を要求する。この例では、マスタノード１００の転送要求部１０６は、転送すべき中間結果ＢＴ２を格納している転送元スレーブノード２００であるスレーブノード１およびスレーブノード２の中間結果転送部２０６に対して、中間結果ＢＴ２を、転送先スレーブノード２００であるスレーブノード３およびスレーブノード４へ転送する転送要求を通知する。
転送要求を受けたスレーブノード１とスレーブノード２の中間結果転送部２０６は、マスタノード１００上の転送要求部１０６からの転送要求を受け取る。その後、転送要求が示す転送先スレーブノード２００であるスレーブノード３およびスレーブノード４に対する中間結果ＢＴ２の転送を実行する。
転送を受ける転送先スレーブノード２００であるスレーブノード３の中間結果転送部２０６は、新たに中間結果ＢＴ２を作成する。その後、転送元スレーブノード２００であるスレーブノード１とスレーブノード２から転送される中間結果を受け取り、受け取った中間結果を作成した中間結果ＢＴ２に順次記録する。このとき、各レコードに関してキーＩＤを作成し、中間結果ＢＴ２のキーＩＤカラムに格納する。転送の結果、図３７に示すＢＴ２が作成される。
図３７に示すように、スレーブノード１の中間結果ＢＴ２（図３２）とスレーブノード２の中間結果ＢＴ２（図３６）の値がマージされた中間結果がスレーブノード３の中間結果ＢＴ２として作成される。実行部２０２は、最終的に作成された中間結果ＢＴ２を中間結果管理部２０５によって記録する。さらに、転送先スレーブノード２００の実行部２０２に対して中間結果ＢＴ２の転送完了通知を行う。実行部２０２は、作成済み中間結果として、中間結果ＢＴ２を中間結果作成状態テーブルに記録する。実行部２０２は中間結果作成状態テーブル上で更新された情報をもとに、実行可能状態テーブルの実行可能情報を更新する。
転送を受ける転送先スレーブノード２００であるスレーブノード４でも同様の処理が行われ、図３７と同様の中間結果ＢＴ２が作成される。
更新された実行可能状態テーブルを参照し、スレーブノード３の実行部２０２は実行可能なオペレータとして「Join」オペレータを選択し、「Join」オペレータを実行する。ここでの「Join」オペレータは、図３７に示す中間結果ＢＴ２の「category2」カラムの値を入力とし、「auctions」データベースに格納されている「deal」データ中で入力値が示す「/deal/related/@category」ノードのノード値と、「people」データベースに格納されている「person」データ中の「/person/profile/interest/@category」ノードのノード値とを比較し、入力値が示す「/deal/related/@category」ノードのノード値と一致する値を持つ「/person/profile/interest/@category」ノードのノードＩＤを取得する処理を示している。
実行部２０２は、新たに中間結果ＢＴ２００を作成し、「Join」オペレータにより取得された値を中間結果ＢＴ２００のカラム「category3」に記録する。実行部２０２は、さらに作成した中間結果ＢＴ２００を中間結果管理部２０５によって記録する。この場合、図３８に示すように、「category2」カラムの値「005」に対しては、「category3」カラムの値として「201」が求められる。同様に、「category2」カラムの値「007」に対しては、「category3」カラムの値として「202」および「203」の２値が求められる。さらに、「category2」カラムの値「106」に対しては、「category3」カラムの値として「204」および「205」の２値が求められる。「category2」カラムのその他の値「006」、「008」、「105」、「107」および「108」に対しては、求められる値がデータベースpeople中に存在しない。
実行部２０２は、作成済み中間結果として、中間結果ＢＴ２００を中間結果作成状態テーブルに記録する。実行部２０２は中間結果作成状態テーブル上で更新された情報をもとに、実行可能状態テーブルの実行可能情報を更新する。
更新された実行可能状態テーブルを参照し、スレーブノード３の実行部２０２は実行可能なオペレータとして「scanAncestor」オペレータを選択し、「scanAncestor」オペレータを実行する。ここでの「scanAncestor」オペレータは、図３８に示す中間結果ＢＴ２００の「category3」カラムの値を入力とし、「people」データベースに格納されている「person」データ中の「/person」ノードのうち、入力値が示すノード「/person/profile/interest/@category」の祖先ノードのノードＩＤを取得する処理を示している。
実行部２０２は、新たに中間結果ＢＴ２０１を作成し、「scanAncestor」オペレータにより取得された値を中間結果ＢＴ２０１のカラム「person」に記録する。この場合、図３９に示す中間結果が求められる。同図では、例えば「category3」カラムの値「201」が示す「/person/profile/interest/@category」ノードの祖先ノードのノードＩＤとして「206」が求められることが示されている。さらに実行部２０２は、作成済み中間結果として、ＢＴ２０１を中間結果作成状態テーブルに記録する。実行部２０２は中間結果作成状態テーブル上で更新された情報をもとに、実行可能状態テーブルの実行可能情報を更新する。
更新された実行可能状態テーブルを参照し、スレーブノード３の実行部２０２は実行可能なオペレータとして「scanDescendant」オペレータを選択し、「scanDescendant」オペレータを実行する。ここでの「scanDescendant」オペレータは、図３９に示す中間結果ＢＴ２０１の「person」カラムの値を入力とし、「people」データベースに格納されている「person」データ中の「/person/@id」ノードのうち、入力値が示すノード「/person」の子孫ノードとなるノードＩＤを取得する処理を示している。
実行部２０２は、新たに中間結果ＢＴ２０２を作成し、「scanDescendant」オペレータにより取得された値を中間結果ＢＴ２０２のカラム「id」に記録する。実行部２０２は、さらに作成した中間結果ＢＴ２０２を中間結果管理部２０５によって記録する。この場合、図４０に示す中間結果が求められる。同図では、例えば、「person」カラムの値「206」が示す「/person」ノードの子孫ノードのノードＩＤとして「211」が求められることが示されている。
さらに、実行部２０２は、作成済み中間結果として、ＢＴ２０２を中間結果作成状態テーブルに記録する。実行部２０２は中間結果作成状態テーブル上で更新された情報をもとに、実行可能状態テーブルの実行可能情報を更新する。
更新された実行可能状態テーブルを参照し、スレーブノード３の実行部２０２は実行可能なオペレータとして「sequence」オペレータを選択し、「sequence」オペレータを実行する。ここでの「sequence」オペレータは、図４０に示す中間結果ＢＴ２０２を入力とし、入力された中間結果の各レコードに関して、同一の「キーＩＤ」カラム値を持つレコードをグループ化し、「id」カラム値からなるシーケンス、およびそのシーケンスのシーケンスＩＤを求める処理を行う。
すなわち、実行部２０２は、新たに中間結果ＢＴ３と中間結果ＢＴ１００２とを作成し、中間結果ＢＴ３のカラム「S（id）」に生成されたシーケンスＩＤを記録するとともに、中間結果ＢＴ１００２のカラム「S（id）」とカラム「id」に、生成されたシーケンスＩＤとその要素となる「id」カラム値を対にして記録する。実行部２０２は、さらに作成した中間結果ＢＴ３および中間結果ＢＴ１００２を中間結果管理部２０５によって記録する。この場合、図４１および図４２に示す中間結果ＢＴ３およびＢＴ１００２がそれぞれ求められる。例えば、図４１では、生成された３つのシーケンスのシーケンスＩＤが「S（id）」カラムの値「33411」、「33421」および「33431」として求められている。また、図４２では、このシーケンスＩＤ「33421」が示すシーケンスの実体として、「id」カラムの値「212」および「213」が求められている。すなわち、シーケンスＩＤ「33421」が示すシーケンスは、この２値から構成される。
なお、このときのシーケンスＩＤは以下の手順で求められる。まず、実行部２０２は、「sequence」オペレータの実行の際に、自身のスレーブノードＩＤ、結果格納先となる中間結果の中間結果ＩＤ、中間結果中のカラム番号、中間結果中のレコード番号、およびプラン生成時に求めた局所性判定結果である局所性情報に対応する局所シーケンスフラグを、割当部２０４に対して一組の入力として与える。割当部２０４は、図２２のフォーマットに従ってシーケンスＩＤを生成し、実行部２０２に返却する。なお、最適化が実行されているため、「registSequence」オペレータは実行されない。
実行部２０２は、作成済み中間結果として、中間結果ＢＴ３を中間結果作成状態テーブルに記録する。実行部２０２は中間結果作成状態テーブル上で更新された情報をもとに、実行可能状態テーブルの実行可能情報を更新する。
更新された実行可能状態テーブルを参照し、スレーブノード３の実行部２０２は実行可能なオペレータとして「notify」オペレータを選択し、「notify」オペレータを実行する。ここでの「notify」オペレータは、中間結果ＢＴ３が作成済み状態であることを示す中間結果作成通知をマスタノード１００の転送要求部１０６に通知する。
同様にして、スレーブノード４でも、実行部２０２が、スレーブノード３におけるここまでの一連の処理と同様の流れでオペレータを実行する。転送実行により図３７と同様のＢＴ２がスレーブノード４上に生成される。次に「Join」オペレータの実行により図４３に示すＢＴ２００が生成される。次に「scanAncestor」オペレータの実行により図４４に示すＢＴ２０１が生成される。次に「scanDescendant」オペレータの実行により図４５に示すＢＴ２０２が生成される。次に「sequence」オペレータの実行により図４６に示すＢＴ３および図４７に示すＢＴ１００２が生成される。その後、「notify」オペレータ実行により、中間結果ＢＴ３が作成済み状態であることを示す中間結果作成通知をマスタノード１００の転送要求部１０６に通知する。
次に、マスタノード１００上の転送要求部１０６は、これまでに受け取った中間結果作成通知および転送要求通知をマッチングし、実行が可能な転送要求を決定する。この場合、スレーブノード３およびスレーブノード４で中間結果ＢＴ３が作成済みであるので、スレーブノード１とスレーブノード２に対して、それぞれの中間結果ＢＴ３の転送が可能である決定できる。
マスタノード１００の転送要求部１０６は、転送する中間結果ＢＴ３を格納している転送元スレーブノード２００の中間結果転送部２０６に対して転送要求を通知し、中間結果の転送を要求する。この場合、マスタノード１００の転送要求部１０６は、転送すべき中間結果ＢＴ３を格納している転送元スレーブノード２００であるスレーブノード３およびスレーブノード４の中間結果転送部２０６に対して、中間結果ＢＴ３を転送先スレーブノード２００であるスレーブ１およびスレーブ２へ転送する転送要求を通知する。
転送要求を受けたスレーブノード３とスレーブノード４の中間結果転送部２０６は、マスタノード１００上の転送要求部１０６からの転送要求を受け取る。その後、転送要求が示す転送先スレーブノード２００であるスレーブノード１とスレーブノード２に対する中間結果ＢＴ３の転送を実行する。
転送を受ける転送先スレーブノード２００であるスレーブノード１の中間結果転送部２０６は、新たに中間結果ＢＴ３を作成する。その後、転送元スレーブノード２００であるスレーブノード３とスレーブノード４から転送される中間結果を受け取り、受け取った中間結果を作成した中間結果ＢＴ３に順次記録する。転送の結果、図４８に示すＢＴ３が作成される。
同図に示すように、スレーブノード３の中間結果ＢＴ３（図４１）とスレーブノード４の中間結果ＢＴ３（図４６）の値がマージされた中間結果がスレーブノード１の中間結果ＢＴ３として作成される。実行部２０２は、最終的に作成された中間結果ＢＴ３を中間結果管理部２０５によって記録する。スレーブノード１の実行部２０２は、さらに、転送先スレーブノード２００の実行部２０２に対して中間結果ＢＴ３の転送完了通知を行う。実行部２０２は、作成済み中間結果として、中間結果ＢＴ３を中間結果作成状態テーブルに記録する。実行部２０２は、中間結果作成状態テーブル上で更新された情報をもとに、実行可能状態テーブルの実行可能情報を更新する。
転送を受ける転送先スレーブノード２００であるスレーブノード２でも同様の処理が行われ、図４８と同様の中間結果ＢＴ３が作成される。
更新された実行可能状態テーブルを参照し、スレーブノード１の実行部２０２は実行可能なオペレータとして「Join」オペレータを選択し、「Join」オペレータを実行する。ここでの「Join」オペレータは、図４８に示す中間結果ＢＴ３の「S（id）」カラムの値を入力とし、「people」データベースに格納されている「person」データ中で、入力値が示す「/person/@id」ノードのノード値と、「auctions」データベースに格納されている「deal」データ中の「/deal/@buyer」ノードのノード値とを比較し、入力値が示す「/person/@id」ノードのノード値と一致する値を持つ「/deal/@buyer」ノードのノードＩＤを取得する処理を示している。
実行部２０２は、新たに中間結果ＢＴ３００を作成し、「Join」オペレータにより取得された値を中間結果ＢＴ３００のカラム「person」に記録する。実行部２０２は、さらに作成した中間結果ＢＴ３００を中間結果管理部２０５によって記録する。この場合、図４９に示す中間結果が得られる。同図では、例えば、「S（id）」カラムの値「33411」に対する「person」カラムの値として「401」および「402」が求められることが示されている。
実行部２０２は、作成済み中間結果として、中間結果ＢＴ３００を中間結果作成状態テーブルに記録する。実行部２０２は中間結果作成状態テーブル上で更新された情報をもとに、実行可能状態テーブルの実行可能情報を更新する。
更新された実行可能状態テーブルを参照し、スレーブノード１の実行部２０２は実行可能なオペレータとして「scanAncestor」オペレータを選択し、「scanAncestor」オペレータを実行する。ここでの「scanAncestor」オペレータは、図４９に示す中間結果ＢＴ３００の「person」カラムの値を入力とし、「auctions」データベースに格納されている「deal」データ中の「/deal」ノードのうち、入力値が示すノード「/deal/@buyer」の祖先ノードのノードＩＤを取得する処理を示している。
実行部２０２は、新たに中間結果ＢＴ３０１を作成し、「scanAncestor」オペレータにより取得された値を中間結果ＢＴ３０１のカラム「deal」に記録する。この場合、図５０に示す中間結果が求められる。さらに実行部２０２は、作成済み中間結果として、ＢＴ３０１を中間結果作成状態テーブルに記録する。実行部２０２は中間結果作成状態テーブル上で更新された情報をもとに、実行可能状態テーブルの実行可能情報を更新する。
更新された実行可能状態テーブルを参照し、スレーブノード１の実行部２０２は実行可能なオペレータとして「sequence」オペレータを選択し、「sequence」オペレータを実行する。ここでの「sequence」オペレータは、図５０に示す中間結果ＢＴ３０１を入力とし、入力された中間結果の各レコードに関して、同一の「キーＩＤ」カラム値を持つレコードをグループ化し、「deal」カラム値からなるシーケンス、およびそのシーケンスのシーケンスＩＤを求める処理を行う。
実行部２０２は、新たに中間結果ＢＴ０と中間結果ＢＴ１００４を作成し、中間結果ＢＴ０のカラム「S（deal）」に生成されたシーケンスＩＤを記録するとともに、中間結果ＢＴ１００４のカラム「S（deal）」とカラム「deal」に、生成されたシーケンスＩＤとその要素となる「deal」カラム値を対にして記録する。
実行部２０２は、さらに作成した中間結果ＢＴ０および中間結果ＢＴ１００４を中間結果管理部２０５によって記録する。この場合、図５１および図５２に示す中間結果が求められる。例えば、図５１では、生成された３つのシーケンスのシーケンスＩＤが「S（deal）」カラムの値「10110」、「10120」および「10130」として求められた例が示されている。
また、図５２では、このシーケンスＩＤ「10110」が示すシーケンスの実体として、「deal」カラムの値「406」および「407」が求められた例が示されている。シーケンスＩＤ「10110」が示すシーケンスは、この２値から構成される。実行部２０２は、作成済み中間結果として、中間結果ＢＴ０を中間結果作成状態テーブルに記録する。実行部２０２は中間結果作成状態テーブル上で更新された情報をもとに、実行可能状態テーブルの実行可能情報を更新する。
更新された実行可能状態テーブルを参照し、スレーブノード１の実行部２０２は実行可能なオペレータとして「registSequence」オペレータを選択し、「registSequence」オペレータを実行する。「registSequence」オペレータでは、実行部２０２は、中間結果ＢＴ０に記録されているS（deal）属性に関する論理シーケンス管理情報を構成通知部２０８に渡す。構成通知部２０８は受け取った論理シーケンス管理情報をマスタノード１００の構成管理部１０７に転送する。マスタノード１００上の構成管理部１０７は、受け取った論理シーケンス管理情報を図５３で示される論理シーケンス構成管理テーブルに追加登録する。
例えば、図５１のＢＴ０に対しては、１レコード目の「S（deal）」カラム値で示されるシーケンスの論理シーケンス管理情報は、（10110,1,1004,111）となる。これは、図５３の１レコード目の論理シーケンス管理情報に対応する。
同様にして、スレーブノード２でも、実行部２０２が、スレーブノード１におけるここまでの一連の処理と同様の流れでオペレータを実行する。転送実行により図４８と同様のＢＴ３がスレーブノード２上に生成される。次に「Join」オペレータの実行により図５４に示すＢＴ３００が生成される。次に「scanAncestor」オペレータの実行により図５５に示すＢＴ３０１が生成される。次に「sequence」オペレータの実行により図５６に示すＢＴ０および図５７に示すＢＴ１００４が生成される。その後、「registSequence」オペレータ実行により、中間結果ＢＴ０に関する論理シーケンス管理情報をマスタノード１００の構成管理部１０７に転送する。マスタノード１００上の構成管理部１０７は、転送された論理シーケンス管理情報を、図５３のような論理シーケンス構成管理テーブルに追加する。
以上の、一連の検索プランの実行結果として、データベース検索の検索結果して得られた図５８および図５９の中間結果ＢＴ０は、スレーブノード１およびスレーブノード２の中間結果管理部２０５にそれぞれ保持されている。また、スレーブノード２００をまたがって存在するシーケンスの構成を示す図５３の論理シーケンス構成管理テーブルは、マスタノード１００の構成管理部１０７に保持されている。
すべての検索プランの実行後、スレーブノード１およびスレーブノード２は最終的に得られた中間結果ＢＴ０をそれぞれの中間結果転送部２０６に渡し、マスタノード１００に転送する。マスタノード１００の中間結果管理部１０８は各スレーブノード２００からの中間結果を受信し、それぞれをマージして図６０に示すようなマスタノード１００上の中間結果ＢＴ０を作成して記録する。
最終的に検索結果を返却する際には、以下の手順で検索結果である「$b」に相当する「S（deal）」カラムの値（シーケンス値）を取得する。
まず、検索プランの実行終了後、マスタノード１００上の結果取得部１０９は、図６０のような中間結果ＢＴ０の「S（deal）」カラムからシーケンスＩＤを取り出す。結果取得部１０９は、取り出した値の局所シーケンスフラグの値を参照することにより（末尾の数値が０）、局所性の無い論理シーケンスであることを判断できる。結果取得部１０９は、論理シーケンスを構成する部分シーケンスの実体を取得するために、取り出したシーケンスＩＤをキーとして、構成管理部１０７によって管理される論理シーケンス構成管理テーブルから論理シーケンス管理情報を取得する。
例えば、「S（deal）」カラム値「10110」の場合、論理シーケンス管理情報の部分シーケンスＩＤを参照することにより、対応する論理シーケンスＩＤとして「１」を取得することができる。図６１は、このようにして得られた論理シーケンス管理情報の一例を示している。結果取得部１０９は、得られた論理シーケンス管理情報から、論理シーケンスを構成する部分シーケンスが存在するスレーブノードＩＤと中間結果ＩＤを取得し、転送要求部１０６に中間結果の転送を要求する。
転送要求部１０６は、該当するスレーブノード２００へ中間結果ＩＤとシーケンスＩＤを通知し中間結果の転送を要求する。転送要求部１０６から中間結果の転送要求を受けたスレーブノード２００の中間結果転送部２０６は、要求された中間結果をマスタノード１００の中間結果管理部１０８へ転送する。スレーブノード１から転送される中間結果は、例えば、図６２のような中間結果ＢＴ１００６で表される。また、スレーブノード２から転送される中間結果は、例えば、図６３のような中間結果ＢＴ１００７で表される。
マスタノード１００の中間結果管理部１０８は、受信した中間結果をマージした図６４のような中間結果ＢＴ１００８を作成して記録する。結果取得部１０９は、図６４の中間結果ＢＴ１００８の「deal」カラムの値として、論理シーケンスＩＤ「１」を構成する「/deal」ノードの値を得ることができる。
以上説明したように、「registSequence」オペレータを実行しないように最適化された検索プランであっても正常に検索結果を取得することができる。すなわち、本実施の形態の手法により、論理シーケンス管理情報を作成する必要がない場合は作成処理を行わないように検索プランを最適化し、その結果として検索処理のオーバヘッドを削減することができる。
次に、「registSequence」オペレータを省略できないにも関わらず「registSequence」オペレータをスキップするように検索プランを変形したことにより、検索結果が正しく得られない例について説明する。以下では、図６５に示すような検索式が入力された場合を例として説明する。
なお、図６６は、本来実行されるべき検索プランの一例を示す説明図である。また、図６７は、「registSequence」オペレータをスキップするように変形した検索プランの一例を示す説明図である。また、図６８〜図７４は、この例で出力される中間結果の一例を示す説明図である。また、図７５は、この例で出力される論理シーケンス管理情報の一例を示す説明図である。
図６５の検索式の場合、シーケンス「$a」は最終出力結果となる出力シーケンスであるため、シーケンス「$a」に関する検索プランに関して「registSequence」オペレータをスキップするようなプラン変形を行うことはできない。
図６７の最後でＢＴ３を出力するオペレータの実行までは、上述の図１９の検索プランでＢＴ３を出力するオペレータの実行までの流れと同様に、各スレーブノード２００上で一連のオペレータが実行される。スレーブノード３上では図６８に示すような中間結果ＢＴ３が出力される。また、スレーブノード４上では図６９に示すような中間結果ＢＴ３が求められる。
以上の一連の検索プランの実行結果として得られた図６８および図６９の中間結果ＢＴ３は、スレーブノード３およびスレーブノード４の中間結果管理部２０５にそれぞれ保持されている。すべての検索プランの実行後、スレーブノード３およびスレーブノード４は最終的に得られた中間結果ＢＴ３をそれぞれの中間結果転送部２０６に渡し、マスタノード１００に転送する。
マスタノード１００の中間結果管理部１０８は各スレーブノード２００からの中間結果を受信し、それぞれをマージして図７０に示すようなマスタノード１００上の中間結果ＢＴ３を作成し、中間結果管理部２０５によって記録する。
最終的に検索結果の返却する際には、以下の手順で検索結果である「$a」に相当する「S（id）」カラムの値（シーケンス値）を取得する。
まず、検索プランの実行終了後、マスタノード１００上の結果取得部１０９は、図７０のような中間結果ＢＴ３の「S（id）」カラムからシーケンスＩＤを取り出す。結果取得部１０９は、取り出した値の局所シーケンスフラグの値を参照することにより（末尾の数値が１）、局所性がある論理シーケンスであることを判断できる。
次に、結果取得部１０９は、得られたシーケンスＩＤから、シーケンスを構成する部分シーケンスが存在するスレーブノード２００と中間結果ＩＤを取得し、転送要求部１０６に中間結果の転送を要求する。例えば、「S（id）」カラム値が「33411」の場合、結果取得部１０９は、図２２に示すようなシーケンスＩＤのフォーマットに従い、スレーブノード３のＢＴ３に存在するシーケンスであることを判断できる。
転送要求部１０６は、該当するスレーブノード２００へ中間結果ＩＤとシーケンスＩＤを通知し中間結果の転送を要求する。転送要求部１０６から中間結果の転送要求を受けたスレーブノード２００の中間結果転送部２０６は、要求された中間結果をマスタノード１００の中間結果管理部１０８へ転送する。スレーブノード３から転送される中間結果は、例えば、図７１のような中間結果ＢＴ１００２で表される。また、スレーブノード４から転送される中間結果は、例えば、図７２のような中間結果ＢＴ１００２で表される。
マスタノード１００の中間結果管理部１０８は、中間結果を受信すると、図７３に示すような中間結果ＢＴ１００４を作成して記録する。結果取得部１０９は、図７３の中間結果ＢＴ１００４の「id」カラムの値として、シーケンスＩＤ「33411」を構成する「/person/@id」ノードの値を得ることになる。
しかしながら、ここで得られた検索結果は誤りである。ＢＴ３を得るオペレータの前に実行される「scanDescendant」オペレータによって、図４０および図４５のように各スレーブノード２００で求められた中間結果ＢＴ２０２は、論理的には図７４のように一つである。そのため、例えば「category2」カラム（=$x）の値が「005」の場合に、その値を元に得られるシーケンス「S（id）」カラムの値は、論理的には図７５のように２値の「id」カラムの値からなるシーケンスとなるのが正しい。これに対し、図７３では、「211」のみしか「id」カラムの値として得られていない。
すなわち、「registSequence」オペレータを排除する最適化を行える条件を満たさないにもかかわらず「registSequence」オペレータを排除するプラン変形を行った場合、誤った結果が求められることになる。言い換えると、本実施のようにシーケンスの局所性および用途を判定して検索プランの最適化を行うことにより、不要な処理を回避して処理負担を軽減しつつ、正しい検索結果を得ることが可能となる。
以上のように、本実施の形態にかかる検索システムでは、分散データベースの検索過程で得られたシーケンスが物理ＤＢ２２０の１つに局所的に格納されているか、および検索結果として出力されるかを判定し、いずれかを満たす場合に、論理シーケンスを構成する処理を不要とするように検索プランを最適化することができる。このため、分散データベースの検索で発生しうるシーケンスに関する処理負担を軽減することが可能となる。
次に、本実施の形態にかかるマスタノードおよびスレーブノードのハードウェア構成について図７６を用いて説明する。図７６は、本実施の形態にかかるマスタノードおよびスレーブノードのハードウェア構成を示す説明図である。
本実施の形態にかかるマスタノードおよびスレーブノードは、ＣＰＵ（Central Processing Unit）５１などの制御装置と、ＲＯＭ（Read Only Memory）５２やＲＡＭ５３などの記憶装置と、ネットワークに接続して通信を行う通信Ｉ／Ｆ５４と、ＨＤＤ（Hard Disk Drive）、ＣＤ（Compact Disc）ドライブ装置などの外部記憶装置と、ディスプレイ装置などの表示装置と、キーボードやマウスなどの入力装置と、各部を接続するバス６１を備えており、通常のコンピュータを利用したハードウェア構成となっている。
本実施の形態にかかるマスタノードおよびスレーブノードで実行されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ（Compact Disk Read Only Memory）、フレキシブルディスク（ＦＤ）、ＣＤ−Ｒ（Compact Disk Recordable）、ＤＶＤ（Digital Versatile Disk）等のコンピュータで読み取り可能な記録媒体に記録されて提供される。
また、本実施の形態にかかるマスタノードおよびスレーブノードで実行されるプログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。また、本実施の形態にかかるマスタノードおよびスレーブノードで実行されるプログラムをインターネット等のネットワーク経由で提供または配布するように構成してもよい。
また、本実施の形態のプログラムを、ＲＯＭ等に予め組み込んで提供するように構成してもよい。
本実施の形態にかかるマスタノードおよびスレーブノードで実行されるプログラムは、上述した各部（「検索要求受付部、プラン生成部、判定部、更新部、実行要求部、転送要求部、構成管理部、中間結果管理部、結果取得部」または「実行要求受付部、実行部、ＤＢ管理部、割当部、中間結果管理部、中間結果転送部、転送要求通知部、構成通知部」）を含むモジュール構成となっており、実際のハードウェアとしてはＣＰＵ５１（プロセッサ）が上記記憶媒体からプログラムを読み出して実行することにより上記各部が主記憶装置上にロードされ、上述した各部が主記憶装置上に生成されるようになっている。
以上のように、本発明にかかる分散データベースから情報を検索するシステム、装置、および方法は、ＸＭＬなどの構造化文書を複数の装置に水平分散配置して管理するシステム、装置および方法に適している。
本実施の形態の検索システムの構成の一例を示す説明図である。 入力される検索式の一例を示す説明図である。 シーケンスの表現形式の一例を示す説明図である。 論理シーケンス管理情報の一例を示す説明図である。 本実施の形態の検索システムの別の構成例を示す説明図である。 論理ＤＢに格納される情報のデータ形式の一例を示す説明図である。 論理ＤＢに格納される情報のデータ形式の一例を示す説明図である。 木構造で表したＸＭＬデータの一例を示す説明図である。 木構造で表したＸＭＬデータの一例を示す説明図である。 本実施の形態のマスタノードおよびスレーブノードの詳細な構成を示すブロック図である。 スキーマテーブルに格納されるスキーマ情報のデータ構造の一例を示す説明図である。 スキーマテーブルに格納されるスキーマ情報のデータ構造の一例を示す説明図である。 分割情報のデータ構造の一例を示す説明図である。 分割情報のデータ構造の一例を示す説明図である。 検索式の一例を示す説明図である。 検索プランの一例を示した説明図である。 局所性判定表のデータ構造の一例を示す説明図である。 作成判定表のデータ構造の一例を示す説明図である。 更新された後の検索プランの一例を示す説明図である。 中間結果の転送要求のデータ構造の一例を示す説明図である。 論理シーケンス管理情報のデータ構造の一例を示す説明図である。 シーケンスＩＤのデータ構造の一例を示す説明図である。 キーＩＤのデータ構造の一例を示す説明図である。 実行可能状態テーブルのデータ構造の一例を示す説明図である。 実行可能状態テーブルのデータ構造の一例を示す説明図である。 中間結果作成状態テーブルのデータ構造の一例を示す説明図である。 本実施の形態における検索処理の全体の流れを示すフローチャートである。 本実施の形態における検索プラン最適化処理の全体の流れを示すフローチャートである。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 論理シーケンス管理情報の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 論理シーケンス管理情報の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 検索式の一例を示す説明図である。 検索プランの一例を示す説明図である。 変形した検索プランの一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 中間結果の一例を示す説明図である。 論理シーケンス管理情報の一例を示す説明図である。 本実施の形態にかかるマスタノードおよびスレーブノードのハードウェア構成を示す説明図である。
符号の説明
４１ 論理ＤＢ
５１ ＣＰＵ
５２ ＲＯＭ
５３ ＲＡＭ
５４ 通信Ｉ／Ｆ
６１ バス
１００ マスタノード
１０１ 検索要求受付部
１０２ プラン生成部
１０３ 判定部
１０４ 更新部
１０５ 実行要求部
１０６ 転送要求部
１０７ 構成管理部
１０８ 中間結果管理部
１０９ 結果取得部
１２０ 記憶部
１２１ スキーマテーブル
１２２ 分割情報テーブル
１２３ 局所性判定表
１２４ 作成判定表
２００ａ、２００ｂ、２００ｃ、２００ｄ スレーブノード
２０１ 実行要求受付部
２０２ 実行部
２０３ ＤＢ管理部
２０４ 割当部
２０５ 中間結果管理部
２０６ 中間結果転送部
２０７ 転送要求通知部
２０８ 構成通知部
２２０ 物理ＤＢ
３００ クライアント

Claims (9)

  1. 少なくとも１つの項目からなる複数の情報を分散して格納する複数のデータベースを、前記データベースごとに管理する複数の情報管理装置と、前記情報管理装置から前記情報を検索する検索装置とがネットワークを介して接続された検索システムであって、
    前記検索装置は、
    前記項目が満たすべき条件を含む検索要求を受付ける検索要求受付部と、
    前記項目に関連する前記データベースのデータ構造と、前記条件の種類と、取得すべき前記項目をリスト構造で表したシーケンス情報として得られる前記項目が前記データベースに分散して格納されているか否かを表す局所性情報とを対応づけて記憶する局所性記憶部と、
    受付けられた検索要求を解析し、前記シーケンス情報の取得要求、および複数の前記データベースから取得された前記シーケンス情報を統合した論理シーケンスの生成要求を含む前記データベースに対する処理要求である検索プランを生成するプラン生成部と、
    前記シーケンス情報として得られる前記項目のそれぞれについて、項目に関連する前記データベースのデータ構造と、項目が満たすべき前記条件の種類とに対応する前記局所性情報を前記局所性記憶部から取得し、取得した前記局所性情報から、前記シーケンス情報として得られる前記項目が前記データベースに分散して格納されているか否かを判定する判定部と、
    前記項目が複数の前記データベースに分散して格納されていないと判定された場合に、前記論理シーケンスの前記生成要求を削除して前記検索プランを更新する更新部と、
    更新された前記検索プランの実行要求を前記情報管理装置に対して通知する実行要求部と、を備え、
    前記情報管理装置は、
    前記データベースと、
    前記実行要求を前記検索装置から受付ける実行要求受付部と、
    受付けた前記実行要求に基づいて、前記データベースに対して前記検索プランを実行する実行部と、
    を備えたことを特徴とする検索システム。
  2. 前記判定部は、さらに、前記検索要求を解析し、前記シーケンス情報のそれぞれについて、前記シーケンス情報が前記検索要求に対する検索結果として出力されるか否かを判定し、
    前記更新部は、さらに、前記シーケンス情報が前記検索結果として出力されないと判定された場合に、前記検索結果として出力されないと判定された前記シーケンス情報を統合した前記論理シーケンスの前記生成要求を削除して前記検索プランを更新すること、
    を特徴とする請求項１に記載の検索システム。
  3. 前記項目と、前記項目が前記データベース内で一意の値を取るか否かを表す一意性情報とを対応づけて記憶する一意性記憶部と、
    前記情報を前記データベースに分散して格納するときの判断基準とする前記項目を定めた分割情報を記憶する分割情報記憶部と、をさらに備え、
    前記局所性記憶部は、前記一意性情報と前記分割情報とを含む前記データ構造と、前記条件の種類と、前記局所性情報とを対応づけて記憶し、
    前記判定部は、前記シーケンス情報として得られる前記項目のそれぞれについて、項目に対応する前記一意性情報を前記一意性記憶部から取得し、項目に対応する前記分割情報を前記分割情報記憶部から取得し、取得した前記一意性情報と取得した前記分割情報とを含む前記データ構造と、項目が満たすべき前記条件の種類とに対応する前記局所性情報を前記局所性記憶部から取得し、取得した前記局所性情報から、前記シーケンス情報として得られる前記項目が前記データベースに分散して格納されているか否かを判定すること、
    を特徴とする請求項１に記載の検索システム。
  4. 前記局所性記憶部は、前記項目が前記データベース内で一意の値を取らないことを表す前記一意性情報と、前記シーケンス情報として得られる前記項目が前記判断基準とする前記項目でないことを表す前記分割情報と、を含む前記データ構造に対して、前記シーケンス情報として得られる前記項目が前記データベースに分散して格納されていることを表す前記局所性情報を対応づけて記憶すること、
    を特徴とする請求項３に記載の検索システム。
  5. 前記局所性記憶部は、前記項目が前記データベース内で一意の値を取ることを表す前記一意性情報を含む前記データ構造と、前記条件として前記シーケンス情報以外が指定されていること表す前記条件の種類とに対して、前記シーケンス情報として得られる前記項目が前記データベースに分散して格納されていないことを表す前記局所性情報を対応づけて記憶すること、
    を特徴とする請求項３に記載の検索システム。
  6. 前記局所性記憶部は、前記シーケンス情報として得られる前記項目が前記判断基準とする前記項目であることを表す前記分割情報を含む前記データ構造と、前記条件として前記シーケンス情報以外が指定されていること表す前記条件の種類とに対して、前記シーケンス情報として得られる前記項目が前記データベースに分散して格納されていないことを表す前記局所性情報を対応づけて記憶すること、
    を特徴とする請求項３に記載の検索システム。
  7. 前記局所性記憶部は、前記シーケンス情報として得られる前記項目が前記判断基準とする前記項目でないことを表す前記分割情報を含む前記データ構造と、前記条件として前記シーケンス情報が指定されていること表す前記条件の種類とに対して、前記シーケンス情報として得られる前記項目が前記データベースに分散して格納されていることを表す前記局所性情報を対応づけて記憶すること、
    を特徴とする請求項３に記載の検索システム。
  8. 少なくとも１つの項目からなる複数の情報を分散して格納する複数のデータベースを、前記データベースごとに管理する複数の情報管理装置と、前記情報管理装置から前記情報を検索する検索装置とがネットワークを介して接続された検索システムにおける検索方法であって、
    前記検索装置は、前記項目に関連する前記データベースのデータ構造と、検索要求内で前記項目が満たすべき条件の種類と、取得すべき前記項目をリスト構造で表したシーケンス情報として得られる前記項目が前記データベースに分散して格納されているか否かを表す局所性情報とを対応づけて記憶する局所性記憶部を備え、
    前記検索装置によって、前記検索要求を受付ける検索要求受付ステップと、
    前記検索装置によって、受付けられた検索要求を解析し、前記シーケンス情報の取得要求、および複数の前記データベースから取得された前記シーケンス情報を統合した論理シーケンスの生成要求を含む前記データベースに対する処理要求である検索プランを生成するプラン生成ステップと、
    前記検索装置によって、前記シーケンス情報として得られる前記項目のそれぞれについて、項目に関連する前記データベースのデータ構造と、項目が満たすべき前記条件の種類とに対応する前記局所性情報を前記局所性記憶部から取得し、取得した前記局所性情報から、前記シーケンス情報として得られる前記項目が前記データベースに分散して格納されているか否かを判定する判定ステップと、
    前記検索装置によって、前記項目が複数の前記データベースに分散して格納されていないと判定された場合に、前記論理シーケンス情報の前記生成要求を削除して前記検索プランを更新する更新ステップと、
    前記検索装置によって、更新された前記検索プランの実行要求を前記情報管理装置に対して通知する実行要求ステップと、
    前記情報管理装置によって、前記実行要求を前記検索装置から受付ける実行要求受付ステップと、
    前記情報管理装置によって、受付けた前記実行要求に基づいて、前記データベースに対して前記検索プランを実行する実行ステップと、
    を備えたことを特徴とする検索方法。
  9. 少なくとも１つの項目からなる複数の情報を分散して格納する複数のデータベースを、前記データベースごとに管理する複数の情報管理装置にネットワークを介して接続され、前記情報管理装置から前記情報を検索する検索装置であって、
    前記項目が満たすべき条件を含む検索要求を受付ける検索要求受付部と、
    前記項目に関連する前記データベースのデータ構造と、前記条件の種類と、取得すべき前記項目をリスト構造で表したシーケンス情報として得られる前記項目が前記データベースに分散して格納されているか否かを表す局所性情報とを対応づけて記憶する局所性記憶部と、
    受付けられた検索要求を解析し、前記シーケンス情報の取得要求、および複数の前記データベースから取得された前記シーケンス情報を統合した論理シーケンスの生成要求を含む前記データベースに対する処理要求である検索プランを生成するプラン生成部と、
    前記シーケンス情報として得られる前記項目のそれぞれについて、項目に関連する前記データベースのデータ構造と、項目が満たすべき前記条件の種類とに対応する前記局所性情報を前記局所性記憶部から取得し、取得した前記局所性情報から、前記シーケンス情報として得られる前記項目が前記データベースに分散して格納されているか否かを判定する判定部と、
    前記項目が複数の前記データベースに分散して格納されていないと判定された場合に、前記論理シーケンス情報の前記生成要求を削除して前記検索プランを更新する更新部と、
    更新された前記検索プランの実行要求を前記情報管理装置に対して通知する実行要求部と、
    を備えたことを特徴とする検索装置。
JP2007085979A 2007-03-28 2007-03-28 分散データベースから情報を検索するシステム、装置、および方法 Active JP4352079B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2007085979A JP4352079B2 (ja) 2007-03-28 2007-03-28 分散データベースから情報を検索するシステム、装置、および方法
US12/046,022 US8019778B2 (en) 2007-03-28 2008-03-11 System, method, and apparatus for searching information across distributed databases

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2007085979A JP4352079B2 (ja) 2007-03-28 2007-03-28 分散データベースから情報を検索するシステム、装置、および方法

Publications (2)

Publication Number Publication Date
JP2008243078A JP2008243078A (ja) 2008-10-09
JP4352079B2 true JP4352079B2 (ja) 2009-10-28

Family

ID=39914297

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2007085979A Active JP4352079B2 (ja) 2007-03-28 2007-03-28 分散データベースから情報を検索するシステム、装置、および方法

Country Status (2)

Country Link
US (1) US8019778B2 (ja)
JP (1) JP4352079B2 (ja)

Families Citing this family (26)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010165170A (ja) * 2009-01-15 2010-07-29 Fujitsu Ltd 検索処理方法、システム、及びプログラム
JP5072871B2 (ja) * 2009-01-28 2012-11-14 株式会社東芝 構造化文書検索システム、装置、及び方法
JPWO2011004622A1 (ja) * 2009-07-10 2012-12-20 コニカミノルタエムジー株式会社 医療情報システムおよびそのためのプログラム
US20110246550A1 (en) * 2010-04-02 2011-10-06 Levari Doron System and method for aggregation of data from a plurality of data sources
US9183267B2 (en) * 2010-05-24 2015-11-10 Microsoft Technology Licensing, Llc Linked databases
US8832130B2 (en) 2010-08-19 2014-09-09 Infosys Limited System and method for implementing on demand cloud database
JP5172931B2 (ja) 2010-10-25 2013-03-27 株式会社東芝 検索装置、検索方法および検索プログラム
JP5100820B2 (ja) * 2010-11-25 2012-12-19 株式会社東芝 問合せ式変換装置、方法およびプログラム
JP5318155B2 (ja) * 2011-06-14 2013-10-16 株式会社東芝 分散データベース検索装置、分散データベース検索方法、及びプログラム
US9674706B2 (en) * 2011-11-11 2017-06-06 Intel Deutschland Gmbh Database coordinator processor and method for providing certification information
WO2013115121A1 (ja) * 2012-01-31 2013-08-08 シャープ株式会社 生成装置、再生装置、データ構造、生成方法、再生方法、制御プログラム、および記録媒体
US9201916B2 (en) * 2012-06-13 2015-12-01 Infosys Limited Method, system, and computer-readable medium for providing a scalable bio-informatics sequence search on cloud
JP5238915B1 (ja) * 2012-08-23 2013-07-17 ディジタル・ワークス株式会社 分散型データベースシステム
US9898475B1 (en) 2013-02-25 2018-02-20 EMC IP Holding Company LLC Tiering with pluggable storage system for parallel query engines
US10963426B1 (en) 2013-02-25 2021-03-30 EMC IP Holding Company LLC Method of providing access controls and permissions over relational data stored in a hadoop file system
JP5538585B1 (ja) * 2013-03-18 2014-07-02 三菱電機インフォメーションシステムズ株式会社 データ検索システム及びデータ検索プログラム
US9251210B2 (en) 2013-04-19 2016-02-02 Oracle International Corporation Caching external data sources for SQL processing
US20150120697A1 (en) 2013-10-28 2015-04-30 Scalebase Inc. System and method for analysis of a database proxy
US10303702B2 (en) 2014-02-07 2019-05-28 Ignite Scalarc Solutions, Inc. System and method for analysis and management of data distribution in a distributed database environment
US10019473B2 (en) * 2014-06-09 2018-07-10 Oracle International Corporation Accessing an external table in parallel to execute a query
US10936616B2 (en) 2014-06-09 2021-03-02 Oracle International Corporation Storage-side scanning on non-natively formatted data
WO2016048105A1 (ko) * 2014-09-26 2016-03-31 주식회사 바이로메드 간세포 성장인자 및 기질세포 유발인자1알파를 이용한 말초동맥질환의 예방 또는 치료용 조성물
US11061895B2 (en) * 2018-07-18 2021-07-13 Oracle International Corporation Adaptive granule generation for parallel queries with run-time data pruning
CN110166542A (zh) * 2019-05-16 2019-08-23 广东电网有限责任公司信息中心 基于tcp/ip协议的分布式存储系统及数据读写方法
US11520593B1 (en) * 2019-12-18 2022-12-06 Marklogic Corporation Apparatus and method for distributed database query cancellation based upon single node query execution analysis
CN113535745B (zh) * 2021-08-09 2022-01-18 威讯柏睿数据科技(北京)有限公司 一种层次化数据库操作加速系统和方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2827562B2 (ja) 1991-04-19 1998-11-25 富士通株式会社 データベースのオブジェクトの部分集合の管理方式
JP2002175327A (ja) 2000-12-05 2002-06-21 Web I Laboratories Inc データベース管理方法
JP4314221B2 (ja) 2005-07-28 2009-08-12 株式会社東芝 構造化文書記憶装置、構造化文書検索装置、構造化文書システム、方法およびプログラム

Also Published As

Publication number Publication date
JP2008243078A (ja) 2008-10-09
US20090019007A1 (en) 2009-01-15
US8019778B2 (en) 2011-09-13

Similar Documents

Publication Publication Date Title
JP4352079B2 (ja) 分散データベースから情報を検索するシステム、装置、および方法
US11475034B2 (en) Schemaless to relational representation conversion
Lee et al. NeT & CoT: Translating relational schemas to XML schemas using semantic constraints
US8886617B2 (en) Query-based searching using a virtual table
US7293018B2 (en) Apparatus, method, and program for retrieving structured documents
US8768931B2 (en) Representing and manipulating RDF data in a relational database management system
US20050091188A1 (en) Indexing XML datatype content system and method
US7844633B2 (en) System and method for storage, management and automatic indexing of structured documents
US20080082571A1 (en) System and Method for Transforming Tabular Form Date into Structured Document
CA2385570A1 (en) System and method for performing similarity searching
JP2004295870A (ja) アプリケーション定義のシステムにおける整合性ユニットのレプリケーション
US7792851B2 (en) Mechanism for defining queries in terms of data objects
US8082492B2 (en) Structured-document management apparatus, search apparatus, storage method, search method and program
US9063957B2 (en) Query systems
US20080201290A1 (en) Computer-implemented methods, systems, and computer program products for enhanced batch mode processing of a relational database
Ba et al. Uncertain version control in open collaborative editing of tree-structured documents
US8086561B2 (en) Document searching system and document searching method
Fehily SQL
US20140304293A1 (en) Apparatus and Method for Query Based Replication of Database
JP4289022B2 (ja) 構造化文書処理方法及び装置及び構造化文書処理プログラム及び構造化文書処理プログラムを格納した記憶媒体
JP5296128B2 (ja) 構造化文書管理装置、方法およびプログラム
WO2023188049A1 (ja) メタデータ管理システム、メタデータ管理方法、プログラム
Tahiri Alaoui An approach to automatically update the Spanish DBpedia using DBpedia Databus
JP5439606B1 (ja) 構造化文書管理装置、方法およびプログラム
JP3498926B2 (ja) 文書データベース管理システム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20090326

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20090630

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20090727

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120731

Year of fee payment: 3

R151 Written notification of patent or utility model registration

Ref document number: 4352079

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130731

Year of fee payment: 4

S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313114

Free format text: JAPANESE INTERMEDIATE CODE: R313111

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350