JP2016009337A

JP2016009337A - Ｒｄｆデータの検索装置及びｒｄｆデータの検索方法

Info

Publication number: JP2016009337A
Application number: JP2014129622A
Authority: JP
Inventors: 新田　清; Kiyoshi Nitta; 清新田; サブニックイズトック; Savnik Iztok
Original assignee: Yahoo Japan Corp
Current assignee: Yahoo Japan Corp
Priority date: 2014-06-24
Filing date: 2014-06-24
Publication date: 2016-01-18
Anticipated expiration: 2034-06-24
Also published as: JP5978253B2

Abstract

【課題】大量のＲＤＦデータを検索する場合であっても、比較的に高速に検索結果を取得することが可能な技術を提供する。
【解決手段】複数のクエリノード部Ｎ０３は、当該クエリノード部Ｎ０３に割り当てられたグラフパターンに対応するＲＤＦデータをデータベースから取得する。ついで、クエリノード部Ｎ０３は、取得したＲＤＦデータを、その親の位置にあるジョインノード部Ｎ０２に送る。ジョインノード部Ｎ０２は、当該ジョインノード部Ｎ０２の子であるクエリノード部Ｎ０４から送られたＲＤＦデータを結合する。
【選択図】図４

Description

本発明は、ＲＤＦデータの検索装置及びＲＤＦデータの検索方法に関するものである。

現代社会では、さまざまな知識に関するデータを集め、蓄積し、そして検索することへの関心が高まっている。いわゆるセマンティックウエブ（Semantic Web）の研究者の間では、このようなデータは、何らかのグラフデータモデルで表されるという共通認識がある。このようなグラフデータモデルの一つとして、ＲＤＦ（Resource Description Framework）が知られている。ＲＤＦでは、データを、主語（Ｓ）、述語（Ｐ）、目的語（Ｏ）で表す。これら三つからなる組（いわゆるトリプル）は、グラフにおける二つのノードと、それをつなぐエッジに対応する。通常の様々な知識は、このグラフによって表すことができる。

グラフデータを収集して蓄積するための様々なプロジェクトがすでに存在している。もっとも有名な例は、Linked Open Data（LOD）プロジェクトであり、ここでは、３２ギガ以上のトリプルを収集している。

ＲＤＦを用いると、データ間の関係を柔軟に記述することができる。また、リレーショナルデータベースのようなテーブル構造をあらかじめ準備する必要がない。このため、例えばインターネット上で様々な方法により記述されたデータの検索が可能になる。ＲＤＦは、Ｗ３Ｃ（World Wide Web Consortium）により規格化されている(W3C:REC-rdf-syntax-19990222)。

ところで、前記したＲＤＦデータの検索のための標準的手法として、ＳＰＡＲＱＬ（SPARQL Protocol And RDF Query Language）が提案されている。Ｗ３ＣによるSPARQL勧告の文書には、その実装手法に関しての記述はなく、第三者が、その勧告に従うように様々の処理系を実装している（例えば下記特許文献１参照）。

しかしながら、既存の実装を前提とすると、大量のＲＤＦデータを検索する場合には、検索結果を得るまでの時間が長くなってしまうという問題がある。

特開２０１３−６９１３６号公報

本発明は、前記した状況に鑑みてなされたものである。本発明の主な目的は、大量のＲＤＦデータを検索する場合であっても、比較的に高速に検索結果を取得することが可能な装置又は方法を提供することである。

本発明は、下記項目に記載のように表現することができる。

（項目１）
複数のグラフパターンを持つクエリ文を用いて、データベースからＲＤＦデータを検索するための検索装置であって、
前記検索装置は、複数のクエリノード部と、ジョインノード部とを備えており、
前記複数のクエリノード部と、前記ジョインノード部とは、木構造をなすクエリツリーを構成しており、
前記複数のクエリノード部は、前記木構造におけるリーフとなる位置に配置されており、
前記ジョインノード部は、前記リーフを子に持つノードとなる位置に配置されており、
前記複数のクエリノード部は、当該クエリノード部に割り当てられた前記グラフパターンに対応するＲＤＦデータを前記データベースから取得し、ついで、前記取得したＲＤＦデータを、当該クエリノード部の親の位置にある前記ジョインノード部に送る構成とされており、
前記ジョインノード部は、当該ジョインノード部の子である前記複数のクエリノード部から送られた各ＲＤＦデータを結合する構成となっている
ＲＤＦデータの検索装置。

（項目２）
前記クエリノード部は、前記データベースから一つのＲＤＦデータを取得すると、そのＲＤＦデータを前記ジョインノード部に送る構成となっている
項目１に記載のＲＤＦデータの検索装置。

（項目３）
前記複数のグラフパターン及び前記複数のクエリノード部の数は、いずれも３以上である
項目１又は２に記載のＲＤＦデータの検索装置。

（項目４）
前記木構造は、二分木構造である
項目１〜３のいずれか１項に記載のＲＤＦデータの検索装置。

（項目５）
前記複数のクエリノード部は、前記木構造においてもっとも深い位置にある前記クエリノード部から、前記ＲＤＦデータの取得を開始し、ついで、当該クエリノード部の親であるジョインノード部の子である他のクエリノード部において、対応するＲＤＦデータの取得を行い、次いで、前記ジョインノード部において、取得された各ＲＤＦデータを結合する構成となっている
項目１〜４のいずれか１項に記載のＲＤＦデータの検索装置。

（項目６）
前記ジョインノード部の親となる位置に他のジョインノード部があり、かつ、前記他のジョインノード部の子となる位置に、他のクエリノード部が存在する場合には、前記他のジョインノード部は、子となる位置の前記ジョインノード部から送られた前記ＲＤＦデータと、前記他のクエリノード部で取得されたＲＤＦデータとを結合する構成となっている
項目１〜５のいずれか１項に記載のＲＤＦデータの検索装置。

（項目７）
前記複数のクエリノード部のうち、最初に動作を開始するクエリノード部においては、前記データベースからの戻り値を非同期メッセージとして受け取る構成となっており、
それ以降に動作を開始するクエリノード部においては、セッション中の同期メッセージとして、前記データベースからの戻り値を受け取る構成となっている
項目１〜６のいずれか１項に記載のＲＤＦデータの検索装置。

（項目８）
前記クエリノード部への、前記グラフパターンの割り当ては、前記クエリ文を処理するためのパーザにより、前記クエリ文を受け取った後に実行されているものである
項目１〜７のいずれか１項に記載のＲＤＦデータの検索装置。

（項目９）
複数のグラフパターンを持つクエリ文を用いて、データベースからＲＤＦデータを検索するための検索装置を用いた検索方法であって、
前記検索装置は、複数のクエリノード部と、ジョインノード部とを備えており、
前記複数のクエリノード部と、前記ジョインノード部とは、木構造をなすクエリツリーを構成しており、
前記複数のクエリノード部は、前記木構造におけるリーフとなる位置に配置されており、
前記ジョインノード部は、前記リーフを子に持つノードとなる位置に配置されており、
前記検索方法は、
前記複数のクエリノード部が、当該クエリノード部に割り当てられた前記グラフパターンに対応するＲＤＦデータを前記データベースから取得し、ついで、前記取得したＲＤＦデータを、当該クエリノード部の親の位置にある前記ジョインノード部に送るステップと、
前記ジョインノード部が、当該ジョインノード部の子である前記複数のクエリノード部から送られた各ＲＤＦデータを結合するステップと
を備えるＲＤＦデータの検索方法。

（項目１０）
項目９に記載の各ステップをコンピュータに実行させるためのコンピュータプログラム。

このコンピュータプログラムは、適宜な記録媒体（例えばＣＤ−ＲＯＭやＤＶＤディスクのような光学的な記録媒体、ハードディスクやフレキシブルディスクのような磁気的記録媒体、あるいはＭＯディスクのような光磁気記録媒体）に格納することができる。このコンピュータプログラムは、インターネットなどの通信回線を介して伝送されることができる。

本発明によれば、大量のＲＤＦデータを検索する場合であっても、比較的に高速に検索結果を取得することが可能となる。

本発明の一実施形態における検索装置（フロントサーバ）とデータサーバとを概略的に示す説明図である。図１の検索装置において用いるクエリツリーの概念を説明するための説明図である。 SPARQLでのクエリ文の一例を示す説明図である。図２のクエリツリーを用いた検索プロセスの一例を説明するための説明図である。本実施形態において用いるアルファマップの構成例を説明するための説明図である。本実施形態において用いるValマップの構成例を説明するための説明図である。

（データベースシステム）
本発明の一実施形態に係るデータベースシステムを図１に示す。このデータベースシステムは、フロントサーバ１０と、データサーバ２０とを備えている。フロントサーバ１０は、本発明の検索装置の一実施形態に対応している。データサーバ２０は、以降ではデータベースと称することがある。

（データサーバ）
データサーバ２０は、列（ａ）〜（ｆ）と行１〜５とを有する。データは、後述するように、列（ａ）〜（ｆ）に分散されている。行１〜５は、負荷分散のために、他の行の複製データを保持するためのものである。列及び行の数をどの程度とするかは、予想される負荷量に応じて決定可能である。

（データ分散）
以下においては、列に対するデータ分散の一例を説明する。

例えば、データのクラスタリングを用いると、データを自動的に列に分散させることができる。あるいは、例えばDBpedia（C. Bizer, J. Lehmann, G. Kobilarov, S. Auer, C. Becker, R. Cyganiak, and S. Hellmann. {DBpedia} - a crystallization point for the web of data. Web Semantics: Science, Services and Agents on the World Wide Web, 7(3):154 - 165, 2009. The Web of Data.）のような大きなデータセットを列に手動で割り当てることもできる。

さらに別の分散方法としては、SPARQLクエリを用いる方法がある。SPARQLクエリを用いれば、アクセスされる可能性の高いＲＤＦデータ（以下単にトリプルと呼ぶことがある）を特定することができ、そのＲＤＦのクラス（rdf:typeで特定される）を用いてＲＤＦを列に割り当てることができる。

具体的には、例えば、トリプル（s, p, o）のうちのｓを基準として列に割り当てることを考える。この場合、ｓのクラス（s,rdf:type,c）に従ってトリプルを列に割り当てることができる。同様にしてトリプルパターン（トリプルのうちの少なくとも一つが変数であるもの）も列に割り当てることができる。トリプルパターンは、本発明におけるグラフパターンに対応する。例えば、トリプルのうちのoが変数であるものは、例えば（s, p, ?o）のように標記できる。なお、前記の例において、トリプルパターンのうちのｓが変数である場合、例えば（?s,p,o）の場合には、ｓに代えてｐのクラスを用いて列にトリプルパターンを割り当てることができる。なお、例えばトリプルパターンが（s,p,?o）であるとき、特定のトリプル（s,p,o）はそのトリプルパターンのインスタンスになっている。

また、例えば、トリプル（s,p,o）のうちのいずれかを用いて、列にトリプル（またはトリプルパターン）を割り当てることもできる。例えば同じｐを持つトリプルは同じ列に割り当てるという分散処理ができる。

（フロントサーバの構成）
本実施形態のフロントサーバ１０は、複数のグラフパターンを持つクエリ文（具体的にはSPARQLクエリ）を用いて、データベースからＲＤＦデータを検索するための検索装置である。

フロントサーバ１０（図２参照）は、ジョインノード部Ｎ０１〜Ｎ０２と、クエリノード部Ｎ０３〜Ｎ０５とを備えている。ただし、これらのノード部の数は図示の例に制約されない。なお、本実施形態のフロントサーバ１０は、文字表記されたSPARQLクエリを、図２のような木構造に変換する処理系（パーザ）を備えている（図示せず）。つまり、図２の状態は、具体的なクエリ文を受け取った後の状態を示している。

（各ノード部の構成）
前記ジョインノード部Ｎ０１〜Ｎ０２と、クエリノード部Ｎ０３〜Ｎ０５とは、木構造をなすクエリツリーを構成している。ここで、クエリツリーとは、論理的構造を意味しており、その実現方法には制約されない。例えば、クエリツリーは、例えばコンピュータプログラムを用いて実装することができる。本実施形態では、クエリツリーとして、二分木構造を採用している。

クエリノード部Ｎ０３〜Ｎ０５は、木構造におけるリーフとなる位置に配置されている。

ジョインノード部Ｎ０１〜Ｎ０２は、クエリノード部Ｎ０３〜Ｎ０５に相当するリーフを子に持つノードとなる位置に配置されている。ジョインノード部Ｎ０１〜Ｎ０２を基準とすると、リーフノードのみにつながるエッジをインナーエッジと呼び、ジョインノード又はリーフノードにつながるエッジをアウターエッジと呼ぶことができる。理解を容易とするために、本例では、アウターエッジは常に左側に延びることとするが、これに制約されるものではない。

クエリノード部Ｎ０３〜Ｎ０５のそれぞれには、複数のグラフパターンのいずれか一つが割り当てられている。具体的には、本例では、図３に示されるSPARQLクエリを想定する。このクエリは、?c <hasArea> ?aと、?c <hasLatitude> ?lと、?c <hasInfration> ?iという三つのクエリパターン（グラフパターン）を備えている。もちろん、本発明はこの例に制約されない。そして、これらのクエリパターンが、図２に示されるように、リーフにある各クエリノード部に割り当てられている。?c <hasArea> ?aというクエリパターンの意味は、<hasArea>という特定の述語を持つトリプルを検索するという意味である。例えば（<日本>, <hasArea>, <377,800 km²>）というトリプルを検索できる。このトリプルは、日本が377,800 km²の国土面積を持つという意味である。本実施形態では、クエリノード部Ｎ０３〜Ｎ０５へのクエリパターンの割り当ても、前記したパーザにより実行される。つまり、各ノード部とクエリパターンの対応関係は、クエリ文の取得ごとに動的に生成される。

クエリノード部Ｎ０３〜Ｎ０５は、当該クエリノード部に割り当てられたグラフパターンに対応するＲＤＦデータをデータサーバ（データベースに相当）２０から取得し、ついで、取得したＲＤＦデータを、当該クエリノード部の親の位置にあるジョインノード部に送る構成とされている。

また、本実施形態のクエリノード部Ｎ０３〜Ｎ０５は、データサーバ２０から一つのＲＤＦデータを取得すると、そのＲＤＦデータを、親の位置にあるジョインノード部に送る構成となっている。

さらに、本実施形態では、複数のグラフパターン及び複数のクエリノード部の数は、特に制約されないが、例えば３以上とされている。

ジョインノード部Ｎ０１〜Ｎ０２は、当該ジョインノード部の子である複数のクエリノード部から送られた各ＲＤＦデータを結合する構成となっている。

本実施形態では、複数のクエリノード部Ｎ０３〜Ｎ０５のうち、木構造においてもっとも深い位置にあるクエリノード部Ｎ０３から、ＲＤＦデータの取得を開始する。ついで、当該クエリノード部の親であるジョインノード部Ｎ０２の子（つまりインナー側）である他のクエリノード部Ｎ０４において、対応するＲＤＦデータの取得を行う。次いで、ジョインノード部Ｎ０２において、取得された各ＲＤＦデータを結合する。

さらに親の位置にあるジョインノード部Ｎ０１においても同様である。つまり、ジョインノード部Ｎ０２の親となる位置に他のジョインノード部Ｎ０１があり、かつ、他のジョインノード部Ｎ０１の子となる位置（つまりインナー側）に、他のクエリノード部Ｎ０５が存在する場合には、他のジョインノード部Ｎ０１は、子となる位置（アウター側）のジョインノード部Ｎ０２から送られたＲＤＦデータと、他のクエリノード部Ｎ０５（つまりインナー側の子ノード）で取得されたＲＤＦデータとを結合する構成となっている。

さらに本実施形態では、クエリノード部Ｎ０３〜Ｎ０５のうち、最初に動作を開始するクエリノード部Ｎ０３においては、データサーバ２０側からの戻り値を非同期メッセージとして受け取る構成となっている。また、それ以降に動作を開始するクエリノード部Ｎ０４〜Ｎ０５においては、セッション中の同期メッセージとして、データサーバ２０からの戻り値を受け取る構成となっている。

（ノード部で保持可能な特性）
本実施形態では、各ノード部において、下記表１に記載の特性を保持可能となっている。ただし、すべての特性を記述する必要はない。

すなわち、各ノード部で保持可能な特性は下記の通りである。なお、表１においてＴＰはクエリノード、Ｊはジョインノードを表す。
Ｎｏ１：ノードで実行されるプロセスのＩＤ；
Ｎｏ２：ノードのタイプ（クエリかジョインか）；
Ｎｏ３：親ノードにおけるプロセスのＩＤ；
Ｎｏ４：ハッシュテーブルのオブジェクト；
Ｎｏ５：変数位置のためのハッシュテーブル；
Ｎｏ６：ストリーム用カウンタ；
Ｎｏ７：インナーエッジにあるクエリノードのためのプロセスＩＤ；
Ｎｏ８：アウターエッジにあるクエリノードのためのプロセスＩＤ；
Ｎｏ９：トリプルパターン；
Ｎｏ１０：インナーにあるサブツリーにおける変数リスト；
Ｎｏ１１：アウターにあるサブツリーにおける変数リスト；
Ｎｏ１２：当該クエリノードにおける変数リスト。

各ノード部における具体的な処理手順については後述する。

（フロントサーバの動作）
次に、図４をさらに参照して、フロントサーバ１０の動作をさらに詳しく説明する。なお、以下の説明では、フロントサーバの動作時点において、各クエリノード部に対して、図２に示すようにトリプルパターン（グラフパターン）が割り当てられているものとする。また、図４において実線の矢印は非同期メッセージを示し、破線の矢印は同期セッション、同期メッセージ又はファンクションコールを示す。また、本例では、各ノードは所定のプロセスとして実装されている。

（図４のステップＳ１〜Ｓ３）
まず、問い合わせ元からの非同期のevalメッセージがジョインノード部Ｎ０１に届くと、ツリー構造のアウター側に順次そのメッセージが送られ、クエリノード部Ｎ０３に届く。

（図４のステップＳ４）
クエリノード部Ｎ０３がevalメッセージを受け取ると、このノード部Ｎ０３は、非同期のfind_streamメッセージをデータサーバに送る。このfind_streamメッセージには、クエリノード部Ｎ０３に割り当てられたトリプルパターン（この例では?c <hasArea> ?a）と、当該ノードのＩＤとが含まれている。

（図４のステップＳ５）
データサーバ２０は、find_streamメッセージを受け取ると、データサーバ２０内に実装されたプロセスとしてのストリーマ３０を起動する。ストリーマ３０は、データサーバ内のデータ分散の仕組みに従って、特定の列及び行のサーバを検索し、特定のトリプルパターン（この例では?c <hasArea> ?a）に対応する戻り値（つまり特定のトリプル）を取得する。ストリーマ３０は、検索で得たトリプル（戻り値）と、問い合わせ先の情報と、対応するトリプルパターンとを保持する。検索結果としてのトリプルは複数であってもよい。なお、データサーバ２０も本実施形態ではプロセスとして実装されている。以降では、データサーバ２０とストリーマ３０とを別のプロセスとして説明するが、全体としてみれば、ストリーマ３０の動作はデータサーバ２０内での動作の一部と観念できる。

（図４のステップＳ６）
ストリーマ３０は、検索で得た戻り値の一つを、非同期のresultメッセージとしてクエリノード部Ｎ０３に戻す。resultメッセージは、図５及び図６に示すアルファマップとValマップとを有する。ここで、各マップについて説明する。

（アルファマップ）
アルファマップは、検索されたデータベース内のトリプルのＩＤを特定するフィールドと、検索を要求したクエリノード部（この例ではＮ０３）を特定するフィールドとを備えている。

（Valマップ）
Valマップは、トリプルパターンにおける変数のＩＤを特定するフィールドと、検索により得られた値のＩＤを特定するフィールドとを備えている。

これらのアルファマップ及びValマップは、ストリーマ３０から、一つのresultメッセージごとにクエリノード部Ｎ０３に送られる。前記したように、ストリーマは、一つの戻り値（検索結果）ごとにresultメッセージを作成して、クエリノード部Ｎ０３に送る。

（図４のステップＳ７）
クエリノード部Ｎ０３は、ストリーマ３０から送られた一つのresultメッセージを、そこで保持するトリプルパターンと照合する。resultメッセージに含まれるトリプルが、クエリノード部Ｎ０３で保持するトリプルパターンと整合していれば、その親ノードであるジョインノード部Ｎ０２にresultメッセージを送る。

（図４のステップＳ８）
ジョインノード部Ｎ０２では、アウター側の子ノードであるクエリノード部Ｎ０３からresultメッセージを受け取ると、インナー側の子ノードであるクエリノード部Ｎ０４から、そこに割り当てられたトリプルパターンを取得する。このステップは同期セッションfetchにより実行される。

（図４のステップＳ９）
ついで、ジョインノード部Ｎ０２は、resultメッセージ中のValマップにおける変数のＩＤを、クエリノード部Ｎ０４でのトリプルパターンに応じて書き換えて、データサーバ２０に送り、検索を要求する。ここでのジョインノード部Ｎ０２からデータサーバ２０への検索要求は、同期セッションとして行われる。この同期セッションにおいて、データサーバ２０は、前記したストリーマ３０と同様、一つ又は複数の検索結果を取得して、ジョインノード部Ｎ０２に戻り値として送る。この戻り値には、特定されたトリプルのＩＤと、クエリに対応する値とが含まれる。そこで、ジョインノード部Ｎ０２は、それらの結果をアルファマップ及びValマップに追加して、これらのマップを更新する。この時点で、一つのresultメッセージ中に、二つのグラフパターン（具体的には?c <hasArea> ?aと?c <hasLatitude> ?l）に対応する値を含めることができる。なお、ジョインノード部Ｎ０２の段階では、クエリノード部Ｎ０３からのresultメッセージにより、主語は変数でなくて既に特定されているので、その特定の主語に対応する特定の目的語（つまり「?l」に対応する値）が追加される。ここで、ステップＳ９での同期セッションsearchにおける戻り値としての検索結果（トリプル）が複数あった場合には、まず一つの検索結果について、上記の処理を行う。残りの検索結果については、ステップＳ３で受け取ったresultメッセージをジョインノードＮ０２で複製して、resultメッセージとトリプルとの一対一対応を維持しつつ、以降の処理を行う。このようにすると、問い合わせ元への応答速度を向上させることができる。なお、ステップＳ９での検索処理は、クエリノード部Ｎ０４によるＲＤＦデータの取得処理を、ジョインノード部Ｎ０２を媒介として行った例であるとみなすことができる。

（図４のステップＳ１０〜Ｓ１１）
次いで、ジョインノード部Ｎ０２は、更新されたアルファマップ及びValマップを持つresultメッセージを、その親ノードの位置にあるジョインノード部Ｎ０１に、非同期メッセージとして送る。ジョインノード部Ｎ０１での動作は、前記したジョインノード部Ｎ０２と基本的に同様である。すなわち、ジョインノード部Ｎ０１では、アウター側の子ノードであるジョインノード部Ｎ０２からresultメッセージを受け取ると、インナー側の子ノードであるクエリノード部Ｎ０５から、そこに割り当てられたトリプルパターンを取得する。

（図４のステップＳ１２）
ついで、ジョインノード部Ｎ０１は、受け取ったresultメッセージ中のValマップにおける変数のＩＤを、クエリノード部Ｎ０５でのトリプルパターンに応じて書き換えて、データサーバ２０に送り、検索を要求する。ここでのジョインノード部Ｎ０１からデータサーバ２０への検索要求も、ジョインノード部Ｎ０２の場合と同様に、同期セッションとして行われる。この同期セッションにおいて、データサーバ２０は、検索結果を取得して、ジョインノード部Ｎ０１に戻り値として送る。この戻り値には、特定された一つトリプルのＩＤと、クエリに対応する値とが含まれる。そこで、ジョインノード部Ｎ０１は、それらの結果をアルファマップ及びValマップに追加する。この時点で、一つのresultメッセージ中に、三つのグラフパターン（具体的には?c <hasArea> ?aと?c <hasLatitude> ?lと?c <hasInfration> ?i）に対応する値を含めることができる。なお、ジョインノード部Ｎ０１の段階でも、主語は変数でなくてすでに特定されているので、その特定の主語に対応する特定の目的語（つまり「?i」に対応する値）が追加される。

（図４のステップＳ１３）
ついで、ジョインノード部Ｎ０１は、更新されたresultメッセージを、問い合わせ元（例えばユーザ端末）に返すことができる。これにより、特定のSPARQLクエリ（図３参照）に対する一つの検索結果を返すことができる。

ストリーマ３０は、resultメッセージとしてまだ送っていない検索結果が残っている場合には、その結果を、ステップＳ６での新たなresultメッセージを用いて順次クエリノード部Ｎ０３に送ることができる。これにより、前記した手順を逐次繰り返して、検索結果を一つずつ問い合わせ元に返すことができる。

従来のSPARQLクエリの実行においては、データベース管理システム側において、各グラフパターンに対応するトリプルをすべて取得し、それらに論理積演算を施すなどの処理を行った後、問い合わせ元に検索結果を返していた。このため、データベースに蓄積されたトリプルの数が大量になると、問い合わせ結果を得るまでにかなりの長時間を要することがあった。

これに対して、本実施形態では、各クエリノード部Ｎ０３〜Ｎ０５に割り当てられたトリプルパターンに対応するトリプルを、非同期のresultメッセージに追加することで、一組のトリプルパターンを順次ルートノードに送ることができる。したがって、本実施形態では、一つの組のトリプルを順次問い合わせ元に返すことができ、ユーザ側における待ち時間を減少させることができるという利点がある。

また、本実施形態では、複数のクエリノード部のうち、最初に動作を開始するクエリノード部Ｎ０３においては、データベースからの戻り値を非同期メッセージとして受け取る構成となっているので、同期セッションを用いる場合と比較して、ネットワークへの負荷を低く抑えることができる。さらに、本実施形態では、その後にノード間で送られるresultメッセージも非同期としたので、ネットワークへの負荷をさらに軽減できる。

また、本実施形態では、クエリノード部Ｎ０３の動作後に動作を開始するクエリノード部Ｎ０４〜Ｎ０５においては、セッション中の同期メッセージとして、データベースからの戻り値を受け取る構成となっているので、アウターエッジ側から受け取ったresultメッセージが保持された状態で、インナーエッジ側のクエリノード部Ｎ０４に対応するトリプルを取得できる。このため、クエリ文に対応する検索結果を正しく取得する処理が簡易となるという利点がある。

さらに、本実施形態では、クエリツリーの木構造として二分木構造を採用したので、処理が単純化するという利点がある。

また、本実施形態では、複数のグラフパターン及び複数のクエリノード部の数を３としたが、それ以上でもそれ以下でもよい。

さらに、本実施形態では、各ノード（クエリノード部及びジョインノード部）を、別の物理的な計算機上に実装することができる。同様に、データサーバ２０の中の列や行に対応するサーバも、別々に実装できる。このようにすると、各ノードから参照する先を分散することができ、ネットワークの負荷を軽減できる。また、クエリとトリプルデータとを近い位置（例えば同じメモリ内）に配置できる可能性もあり、このようにすれば、ネットワーク負荷をさらに軽減して、処理を高速化できる。

前記した各実施形態の動作は、コンピュータに適宜のコンピュータソフトウエアを組み込むことにより実施することができる。

なお、本発明の内容は、前記実施形態に限定されるものではない。本発明は、特許請求の範囲に記載された範囲内において、具体的な構成に対して種々の変更を加えうるものである。

例えば、前記した実施形態では、ステップＳ７の後にステップＳ８を行う例を示したが、ステップＳ３の時点でステップＳ８を実行して、クエリパターンをジョインノード部Ｎ０２が保持してもよい。ステップＳ１１についても同様に、ステップＳ２の時点で実行されていてもよい。

また例えば、前記した各構成要素は、機能ブロックとして存在していればよく、独立したハードウエアとして存在しなくても良い。また、実装方法としては、ハードウエアを用いてもコンピュータソフトウエアを用いても良い。さらに、本発明における一つの機能要素が複数の機能要素の集合によって実現されても良く、本発明における複数の機能要素が一つの機能要素により実現されても良い。

また、機能要素は、物理的に離間した位置に配置されていてもよい。この場合、機能要素どうしがネットワークにより接続されていても良い。グリッドコンピューティング又はクラウドコンピューティングにより機能を実現し、あるいは機能要素を構成することも可能である。

１０フロントサーバ（検索装置）
２０データサーバ（データベース）
３０ストリーマ
Ｎ０１・Ｎ０２ジョインノード部
Ｎ０３〜Ｎ０５クエリノード部

Claims

複数のグラフパターンを持つクエリ文を用いて、データベースからＲＤＦデータを検索するための検索装置であって、
前記検索装置は、複数のクエリノード部と、ジョインノード部とを備えており、
前記複数のクエリノード部と、前記ジョインノード部とは、木構造をなすクエリツリーを構成しており、
前記複数のクエリノード部は、前記木構造におけるリーフとなる位置に配置されており、
前記ジョインノード部は、前記リーフを子に持つノードとなる位置に配置されており、
前記複数のクエリノード部は、当該クエリノード部に割り当てられた前記グラフパターンに対応するＲＤＦデータを前記データベースから取得し、ついで、前記取得したＲＤＦデータを、当該クエリノード部の親の位置にある前記ジョインノード部に送る構成とされており、
前記ジョインノード部は、当該ジョインノード部の子である前記複数のクエリノード部から送られた各ＲＤＦデータを結合する構成となっている
ＲＤＦデータの検索装置。
前記クエリノード部は、前記データベースから一つのＲＤＦデータを取得すると、そのＲＤＦデータを前記ジョインノード部に送る構成となっている
請求項１に記載のＲＤＦデータの検索装置。
前記複数のグラフパターン及び前記複数のクエリノード部の数は、いずれも３以上である
請求項１又は２に記載のＲＤＦデータの検索装置。
前記木構造は、二分木構造である
請求項１〜３のいずれか１項に記載のＲＤＦデータの検索装置。
前記複数のクエリノード部は、前記木構造においてもっとも深い位置にある前記クエリノード部から、前記ＲＤＦデータの取得を開始し、ついで、当該クエリノード部の親であるジョインノード部の子である他のクエリノード部において、対応するＲＤＦデータの取得を行い、次いで、前記ジョインノード部において、取得された各ＲＤＦデータを結合する構成となっている
請求項１〜４のいずれか１項に記載のＲＤＦデータの検索装置。
前記ジョインノード部の親となる位置に他のジョインノード部があり、かつ、前記他のジョインノード部の子となる位置に、他のクエリノード部が存在する場合には、前記他のジョインノード部は、子となる位置の前記ジョインノード部から送られた前記ＲＤＦデータと、前記他のクエリノード部で取得されたＲＤＦデータとを結合する構成となっている
請求項１〜５のいずれか１項に記載のＲＤＦデータの検索装置。
前記複数のクエリノード部のうち、最初に動作を開始するクエリノード部においては、前記データベースからの戻り値を非同期メッセージとして受け取る構成となっており、
それ以降に動作を開始するクエリノード部においては、セッション中の同期メッセージとして、前記データベースからの戻り値を受け取る構成となっている
請求項１〜６のいずれか１項に記載のＲＤＦデータの検索装置。
前記クエリノード部への、前記グラフパターンの割り当ては、前記クエリ文を処理するためのパーザにより、前記クエリ文を受け取った後に実行されているものである
請求項１〜７のいずれか１項に記載のＲＤＦデータの検索装置。
複数のグラフパターンを持つクエリ文を用いて、データベースからＲＤＦデータを検索するための検索装置を用いた検索方法であって、
前記検索装置は、複数のクエリノード部と、ジョインノード部とを備えており、
前記複数のクエリノード部と、前記ジョインノード部とは、木構造をなすクエリツリーを構成しており、
前記複数のクエリノード部は、前記木構造におけるリーフとなる位置に配置されており、
前記ジョインノード部は、前記リーフを子に持つノードとなる位置に配置されており、
前記検索方法は、
前記複数のクエリノード部が、当該クエリノード部に割り当てられた前記グラフパターンに対応するＲＤＦデータを前記データベースから取得し、ついで、前記取得したＲＤＦデータを、当該クエリノード部の親の位置にある前記ジョインノード部に送るステップと、
前記ジョインノード部が、当該ジョインノード部の子である前記複数のクエリノード部から送られた各ＲＤＦデータを結合するステップと
を備えるＲＤＦデータの検索方法。
請求項９に記載の各ステップをコンピュータに実行させるためのコンピュータプログラム。