特開2023-90684 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

▶ ダッソー　システムズの特許一覧

特開2023-90684分散グラフデータベースにおけるＳＰＡＲＱＬクエリの最適化

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4
5
6

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023090684

(43)【公開日】2023-06-29

(54)【発明の名称】分散グラフデータベースにおけるＳＰＡＲＱＬクエリの最適化

(51)【国際特許分類】

G06F 16/28 20190101AFI20230622BHJP

【ＦＩ】

G06F16/28

【審査請求】未請求

【請求項の数】15

【出願形態】ＯＬ

【外国語出願】

(21)【出願番号】P 2022201058

(22)【出願日】2022-12-16

(31)【優先権主張番号】21306834

(32)【優先日】2021-12-17

(33)【優先権主張国・地域又は機関】EP

(71)【出願人】

【識別番号】500102435

【氏名又は名称】ダッソーシステムズ

【氏名又は名称原語表記】ＤＡＳＳＡＵＬＴＳＹＳＴＥＭＥＳ

(74)【代理人】

【識別番号】110000752

【氏名又は名称】弁理士法人朝日特許事務所

(72)【発明者】

【氏名】フレデリックラベイト

(72)【発明者】

【氏名】ジャン・フィリッペサフト・ディザーン

(72)【発明者】

【氏名】アルバンローラー

(72)【発明者】

【氏名】デイビッド・エドワードテュークスベリー

【テーマコード（参考）】

5B175

【Ｆターム（参考）】

5B175HA04

5B175KA12

(57)【要約】（修正有）

【課題】ＲＤＦグラフに対するＳＰＡＲＱＬクエリのための演算子のグラフをクエリエンジンによって生成する方法、システムおよびプログラムを提供する。
【解決手段】方法は、クエリエンジンによって実行可能な演算子のグラフを提供するステップを有する。当該グラフは、複数の基本演算子を含み、そのうちの少なくとも２つは、夫々の基本グラフパターンにマッチするＲＤＦグラフのＲＤＦトリプルを見つけ出すように構成された第１のタイプ演算子である。方法はまた、グラフの第１のタイプである複数の基本演算子の中から、演算子群を識別するステップを含む。演算子群の夫々の基本グラフパターンは、同じ主語および／または述語および／または目的語を有し、上記識別された演算子群は、基本グラフパターンにマッチするＲＤＦグラフのＲＤＦトリプルを見つけ出すように構成された等価演算子によって、提供されたグラフにおいて置換される。
【選択図】図１

【特許請求の範囲】

【請求項1】

ＲＤＦグラフに対するＳＰＡＲＱＬクエリのための演算子のグラフ（ＤＡＧ）をクエリエンジンによって生成するためのコンピュータ実施方法であって、
－前記クエリエンジンによって実行可能な演算子のグラフをストレージエンジンに問い合わせを行うことによって提供するステップ（Ｓ１０）であって、前記提供されたグラフは、複数の基本演算子を含み、前記提供されたグラフの前記基本演算子のうちの少なくとも２つは、それぞれの基本グラフパターンにマッチする前記ＲＤＦグラフのＲＤＦトリプルを見つけ出すようにそれぞれが構成された第１のタイプ（ＦＩＮＤ）の基本演算子であるステップ（Ｓ１０）と、
－前記提供されたグラフの前記第１のタイプである前記少なくとも２つの基本演算子の中から、演算子群を、前記演算子群のそれぞれの基本グラフパターンが、同じ主語および／または述語および／または目的語を有するように識別するステップ（Ｓ２０）であって、前記ストレージエンジンに問い合わせが行われると、前記識別された演算子群は、前記演算子群の前記それぞれの基本グラフパターンにマッチする前記ＲＤＦグラフのＲＤＦトリプルを見つけ出すように構成された等価演算子によって、前記提供されたグラフにおいて置換される（Ｓ３０）ステップ（Ｓ２０）と
を含む方法。

【請求項2】

前記演算子群の前記それぞれの基本グラフパターンは、一定の述語を有する、請求項１に記載の方法。

【請求項3】

前記演算子群の前記それぞれの基本グラフパターンは、一定の目的語を有する、請求項１または２に記載の方法。

【請求項4】

前記演算子群の前記それぞれの基本グラフパターンは、同じ主語を有する、請求項１から３のいずれか一つに記載の方法。

【請求項5】

前記提供されたグラフは、１つまたは複数のＲＤＦトリプルおよびブール式を入力として受け付け、かつ前記１つまたは複数のＲＤＦトリプルの部分集合を出力するように構成された少なくとも１つの第２のタイプ（ＦＩＬＴＥＲ）の基本演算子をさらに含み、前記部分集合におけるＲＤＦトリプルのそれぞれのトリプルの一部に対する前記ブール式の適用は真であり、前記方法は、
－前記提供されたグラフの前記少なくとも２つの第１のタイプの基本演算子の中から演算子群を識別するステップの前に、前記少なくとも１つの第２のタイプの基本演算子のそれぞれを、前記第１のタイプのそれぞれの基本演算子のすぐ後ろに移動させるステップであって、前記第１のタイプの前記それぞれの基本演算子は、前記第２のタイプの前記少なくとも１つの基本演算子が受け付けるように構成されたＲＤＦトリプルを見つけ出すことが可能であるステップをさらに含み、
前記等価演算子は、制約を入力として受け付けるようにさらに構成され、前記方法は、前記第２のタイプの前記少なくとも１つの基本演算子のそれぞれについて、
－前記第２のタイプの前記演算子を、少なくとも部分的に制約の集合に変えられ得る式に分割するステップと、
－前記第２のタイプの前記基本演算子を前記グラフから除去し、前記制約の集合を、少なくとも、前記第２のタイプの前記基本演算子のすぐ後ろの前記第１のタイプの前記それぞれの基本演算子を置換するそれぞれの等価演算子に入力するステップとをさらに含む、請求項１から４のいずれか一つに記載の方法。

【請求項6】

前記制約のそれぞれは、前記ストレージエンジンによって検証され、前記制約の集合は、以下のうちの少なくとも１つまたは複数を含む、請求項５に記載の方法：
－数値制約、
－値の種類または言語の種類に対する制約、および
－文字列（strings）についての制約。

【請求項7】

前記部分集合におけるＲＤＦトリプルのそれぞれのトリプルの前記一部は、それぞれのＲＤＦトリプルの主語および／または目的語を含む、請求項５または６のいずれか一つに記載の方法。

【請求項8】

前記第２のタイプの前記少なくとも１つの基本演算子を移動させるステップの後であって、前記演算子を分割するステップの前に、前記第２のタイプの各基本演算子について、
－前記第２のタイプの前記基本演算子を論理積形式に正規化するステップをさらに含む、請求項５から７のいずれか一つに記載の方法。

【請求項9】

前記提供されたグラフは、
－それぞれが前記ＲＤＦグラフにおけるＲＤＦトリプルの変数の要素の値に対応する１つまたは複数のインデックスを入力として受け付け、かつ
－前記インデックスのそれぞれの値を出力するように構成された少なくとも１つの第３のタイプ（ＧｅｔＶａｌｕｅｓ）の基本演算子をさらに含み、
前記等価演算子は、第１のタグを入力としてさらに受けつけ、前記方法は、前記少なくとも１つの第３のタイプの基本演算子のそれぞれについて、
－前記第３のタイプの前記演算子の対応するＲＤＦトリプルを見つけ出すことが可能な等価演算子を前記演算子のグラフにおいて識別するステップと、
－前記識別された等価演算子の前記第１のタグの値を予め定義された値に設定し、前記第３のタイプの前記演算子を前記提供されたグラフから除去するステップとをさらに含む、請求項１から８のいずれか一つに記載の方法。

【請求項10】

前記演算子群の前記演算子のうちの少なくとも１つは、基本グラフパターンのための第２のタグ（ＯＰＴＩＯＮＡＬ）を有し、前記等価演算子は、前記第２のタグ（ＯＰＴＩＯＮＡＬ）を入力としてさらに受け付け、前記等価演算子は、前記演算子群における少なくとも演算子の前記それぞれの基本グラフパターンにマッチする前記ＲＤＦグラフの少なくともいずれかのＲＤＦトリプルを、前記第２のタグを得ることなく見つけ出す、請求項１から９のいずれか一つに記載の方法。

【請求項11】

－同じ主語および／または同じ目的語を有する少なくとも２つの等価演算子を前記演算子のグラフにおいて識別するステップと、
－前記ストレージエンジンに問い合わせが行われると、前記識別された２つの等価演算子を、前記識別された２つの等価演算子のそれぞれの識別された基本グラフパターンにマッチする前記ＲＤＦグラフのＲＤＦトリプルを見つけ出すことが可能な等価演算子によって置換するステップとをさらに含む、請求項１から１０のいずれか一つに記載の方法。

【請求項12】

前記ＲＤＦグラフは、２つ以上の部分グラフへの未知のパーティショニング（partitioning）を有する分散ＲＤＦグラフである、請求項１から１１のいずれか一つに記載の方法。

【請求項13】

請求項１から１２のいずれか一つに記載の方法を実施するための命令を含むコンピュータプログラム。

【請求項14】

請求項１３に記載のコンピュータプログラムが記録されたコンピュータ可読記憶媒体。

【請求項15】

請求項１３に記載のコンピュータプログラムが記録されたメモリに結合されたプロセッサを備えるシステム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、コンピュータプログラムおよびコンピュータシステムの分野に関し、より詳細には、ＲＤＦグラフ上でＳＰＡＲＱＬクエリのための演算子のグラフ（ＤＡＧ）をクエリエンジンによって生成するための方法、システムおよびプログラムに関する。

【背景技術】

【0002】

数多くのシステムおよびプログラムが、オブジェクトの設計、エンジニアリングおよび製造のための市場に提供されている。ＣＡＤは、コンピュータ支援設計（Ｃｏｍｐｕｔｅｒ－ＡｉｄｅｄＤｅｓｉｇｎ）の略称であり、例えば、オブジェクトを設計するためのソフトウェア・ソリューションに関する。ＣＡＥは、コンピュータ支援エンジニアリング（Ｃｏｍｐｕｔｅｒ－ＡｉｄｅｄＥｎｇｉｎｅｅｒｉｎｇ）の略称であり、例えば、将来の製品の物理的挙動をシミュレーションするためのソフトウェア・ソリューションに関する。ＣＡＭは、コンピュータ支援製造（Ｃｏｍｐｕｔｅｒ－ＡｉｄｅｄＭａｎｕｆａｃｔｕｒｉｎｇ）の略称であり、製造のプロセスおよび作業を定義するためのソフトウェア・ソリューションに関する。このようなコンピュータ支援設計システムでは、グラフィカル・ユーザ・インターフェースは、技術の効率化に関して重要な役割を果たす。これらの技術は、製品ライフサイクル管理（ＰＬＭ）システム内に組み込まれる場合がある。ＰＬＭとは、企業が、拡張エンタープライズの概念にわたって、着想からサポート終了に至る製品開発のために、製品データを共有し、共通のプロセスを適用し、企業知識を活用することを支援する事業戦略のことである。ダッソー・システムズ（ＣＡＴＩＡ、ＥＮＯＶＩＡおよびＤＥＬＭＩＡの商標で）が提供するＰＬＭソリューションにより、製品エンジニアリングの知識を編成するエンジニアリングハブと、製品エンジニアリングの知識を管理する製造ハブと、エンジニアリングハブおよび製造ハブの両方への企業の統合および接続を可能にする企業ハブが提供される。これら全てを合わせて、システムは、製品定義、製造準備、生産およびサービスの最適化を促進するダイナミックかつ知識ベースの製品創造および意思決定サポートを可能にするために、製品、プロセス、リソースをリンクするオープンオブジェクトモデルを提供する。

【0003】

ディスクまたはＳＳＤにデータを格納するデータベースとは対照的に、グラフデータベースは、インメモリデータベース、すなわち、データの格納を主としてメモリに依存する専用データベースにおける利用に特に適合されている。

【0004】

データセットが非常に大規模であるという問題にＲＤＦグラフデータベースが直面しているという理由から、そして、このようなデータベースの性能およびスケーラビリティを維持する目的で、データを異なる物理的位置にわたって格納する分散手法が必要とされている。物理的位置にわたるデータの分散は、データベースのいくつかの局面、あるいは受け取ったクエリに対する応答（例えば、書込みまたは読出し）を最適化するようになされる場合がある。この分散は、必ずしも既知ではなく、実行可能でもない。

【0005】

３つのカテゴリの分散手法が提案されている。

【0006】

１．既存のクラウド・コンピューティング・プラットフォーム（小規模ファイルに基づくＨＤＦＳのような）を用いて大規模ＲＤＦグラフを分散する、クラウドベースの手法。これらの手法では、最も一般的にはＭａｐＲｅｄｕｃｅ技術（並列分散計算）を用いるか、あるいは同技術に着想を得た、例えば、Ｓｐａｒｋ（大規模データ処理用の統一解析エンジンである）を用いた、トリプルパターンベースの結合プロセスが採用される。クラウドベースの手法では、ＭａｐＲｅｄｕｃｅのような計算をグラフ計算に適合させることは困難である。ＭａｐＲｅｄｕｃｅは、基本的には分割・適用・組合せ（split-apply-combine）戦略である一方、ＳＰＡＲＱＬのグラフ準同型（graph homomorphism）は、はるかに高い意味論レベルを有する。

【0007】

２．パーティションベースの手法は、ＲＤＦグラフを部分グラフの集合に分割し、ＳＰＡＲＱＬクエリをサブクエリに分解する。サブクエリは、分散リレーショナルデータベース（リレーショナルデータベースを用いたこの手法の詳細については［２］を参照されたい）に類似した技術を用いて、分割されたデータ上で実行される。ＲＤＦにおけるスキーマの欠如（例えば、開世界仮説（Open World Assumption））は、ＳＱＬ戦略をＳＰＡＲＱＬクエリ処理に適合させることを困難にしている。この手法では、パーティショニング戦略を実施することは難しい。なぜなら、リレーショナルデータベースとは異なり、ＲＤＦにはスキーマが存在しないからである。特に、パーティショニング戦略は、別の目的（例えば、書込みスループット）では選択されたかもしれない。

【0008】

これらの手法はいずれも、ネットワークの饒舌さ（network chattiness）、すなわち、中間結果の数の増加をもたらし、性能を低下させる。

【0009】

３.連合（Federated）ＳＰＡＲＱＬ処理システムは、多数のＳＰＡＲＱＬエンドポイント、典型的には、リンクト・オープン・データ（Linked Open Data）・ターゲットに対するクエリを評価する。その場合、当該システムは、データ統合手法（すなわち、異なるソースにあるデータを組み合わせ、それらの統一されたビューをユーザに提供することによる）である。

【0010】

文献、Peng, et al., "Processing SPARQL queries over distributed RDF graphs.", The VLDB Journal 25.2 (2016): 243-268では、分散環境において大規模ＲＤＦグラフに対してＳＰＡＲＱＬクエリを処理するための技術が提案されており、部分評価・アセンブリ・フレームワーク（partial evaluation and assembly framework）が採用されている。この文献が提案する戦略は、データグラフを分割することにのみ基づくものであり、何らかのグラフ分割アルゴリズムを用いてＲＤＦグラフを頂点が互いに素なフラグメント（vertex-disjoint fragments）に分割する、クエリ分解には基づいていない。したがって、この方法は、グラフのパーティショニングを要件としており、未知のパーティショニングに適用することはできない。

【発明の概要】

【発明が解決しようとする課題】

【0011】

このような状況においては、ＲＤＦグラフに対するＳＰＡＲＱＬクエリのための演算子のグラフ（ＤＡＧ）をクエリエンジンによって生成するための改良された方法がなお必要とされている。

【課題を解決するための手段】

【0012】

したがって、ＲＤＦグラフに対するＳＰＡＲＱＬクエリのための演算子のグラフをクエリエンジンによって生成するためのコンピュータ実施方法であって、上記クエリエンジンによって実行可能な演算子のグラフをストレージエンジンに問い合わせを行うことによって提供するステップであって、上記提供されたグラフは、複数の基本演算子を含み、上記提供されたグラフの上記基本演算子のうちの少なくとも２つは、それぞれの基本グラフパターンにマッチする上記ＲＤＦグラフのＲＤＦトリプルを見つけ出すようにそれぞれが構成された第１のタイプの基本演算子であるステップと、上記提供されたグラフの上記第１のタイプである上記少なくとも２つの基本演算子の中から、演算子群を、上記演算子群のそれぞれの基本グラフパターンが、同じ主語および／または述語および／または目的語を有するように識別するステップであって、上記ストレージエンジンに問い合わせが行われると、上記識別された演算子群は、上記演算子群の上記それぞれの基本グラフパターンにマッチする上記ＲＤＦグラフのＲＤＦトリプルを見つけ出すように構成された等価演算子によって、上記提供されたグラフにおいて置換されるステップとを含む方法が開示される。

【0013】

上記方法は、以下のうちの１つまたは複数を含み得る。

【0014】

－上記演算子群の上記それぞれの基本グラフパターンは、一定の述語を有し、
－上記演算子群の上記それぞれの基本グラフパターンは、一定の目的語を有し、
－上記演算子群の上記それぞれの基本グラフパターンは、同じ主語を有し、

【0015】

－上記提供されたグラフは、１つまたは複数のＲＤＦトリプルおよびブール式を入力として受け付け、かつ上記１つまたは複数のＲＤＦトリプルの部分集合を出力するように構成された少なくとも１つの第２のタイプの基本演算子をさらに含み、上記部分集合におけるＲＤＦトリプルのそれぞれのトリプルの一部に対する上記ブール式の適用は真であり、上記方法は、上記提供されたグラフの上記少なくとも２つの第１のタイプの基本演算子の中から演算子群を識別するステップの前に、上記少なくとも１つの第２のタイプの基本演算子のそれぞれを、上記第１のタイプのそれぞれの基本演算子のすぐ後ろに移動させるステップであって、上記第１のタイプの上記それぞれの基本演算子は、上記第２のタイプの上記少なくとも１つの基本演算子が受け付けるように構成されたＲＤＦトリプルを見つけ出すことが可能であるステップをさらに含み、上記等価演算子は、制約を入力として受け付けるようにさらに構成され、上記方法は、上記第２のタイプの上記少なくとも１つの基本演算子のそれぞれについて、上記第２のタイプの上記演算子を、少なくとも部分的に制約の集合に変えられ得る式に分割するステップと、上記第２のタイプの上記基本演算子を上記グラフから除去し、上記制約の集合を、少なくとも、上記第２のタイプの上記基本演算子のすぐ後ろの上記第１のタイプの上記それぞれの基本演算子を置換するそれぞれの等価演算子に入力するステップとをさらに含み、

【0016】

－上記制約のそれぞれは、上記ストレージエンジンによって検証され、上記制約の集合は、以下のうちの少なくとも１つまたは複数を含み：数値制約、値の種類または言語の種類に対する制約、および文字列（strings）についての制約、
－上記部分集合におけるＲＤＦトリプルのそれぞれのトリプルの上記一部は、それぞれのＲＤＦトリプルの主語および／または目的語を含み、

【0017】

－上記第２のタイプの上記少なくとも１つの基本演算子を移動させるステップの後であって、上記演算子分割ステップの前に、上記第２のタイプの各基本演算子について、上記第２のタイプの上記基本演算子を論理積形式に正規化するステップをさらに含み、

【0018】

－上記提供されたグラフは、それぞれが上記ＲＤＦグラフにおけるＲＤＦトリプルの変数の要素の値に対応する１つまたは複数のインデックスを入力として受け付け、かつ上記インデックスのそれぞれの値を出力するように構成された少なくとも１つの第３のタイプの基本演算子をさらに含み、上記等価演算子は、第１のタグを入力としてさらに受けつけ、上記方法は、上記少なくとも１つの第３のタイプの基本演算子のそれぞれについて、上記第３のタイプの上記演算子の対応するＲＤＦトリプルを見つけ出すことが可能な等価演算子を上記演算子のグラフにおいて識別するステップと、上記識別された等価演算子の上記第１のタグの値を予め定義された値に設定し、上記第３のタイプの上記演算子を上記提供されたグラフから除去するステップとをさらに含み、

【0019】

－上記演算子群の上記演算子のうちの少なくとも１つは、基本グラフパターンのための第２のタグを有し、上記等価演算子は、上記第２のタグを入力としてさらに受け付け、上記等価演算子は、上記演算子群における少なくとも演算子の上記それぞれの基本グラフパターンにマッチする上記ＲＤＦグラフの少なくともいずれかのＲＤＦトリプルを、上記第２のタグを得ることなく見つけ出し、

【0020】

－同じ主語および／または同じ目的語を有する少なくとも２つの等価演算子を上記演算子のグラフにおいて識別するステップと、上記ストレージエンジンに問い合わせが行われると、上記識別された２つの等価演算子を、上記識別された２つの等価演算子のそれぞれの識別された基本グラフパターンにマッチする上記ＲＤＦグラフのＲＤＦトリプルを見つけ出すことが可能な等価演算子によって置換するステップとをさらに含み、かつ／または
－上記ＲＤＦグラフは、２つ以上の部分グラフへの未知のパーティショニング（partitioning）を有する分散ＲＤＦグラフである。

【0021】

上記方法を実行するための命令を含むコンピュータプログラムがさらに提供される。

【0022】

上記コンピュータプログラムが記録されたコンピュータ可読記憶媒体がさらに提供される。

【0023】

上記コンピュータプログラムが記録されたメモリに結合されたプロセッサと、グラフィカル・ユーザ・インターフェースとを備えるシステムがさらに提供される。
以下、非限定的な例について添付の図面を参照しながら説明する。

【図面の簡単な説明】

【0024】

【図1】上記方法の一例を示すフローチャートである。

【図2】ＳＰＡＲＱＬコア内部のＳＰＡＲＱＬクエリの実行のワークフロー例を示す。

【図3】演算子ＤＡＧの例を示す。

【図4】演算子ＤＡＧの別の例を示す。

【図5】上記方法によって生成された演算子ＤＡＧの例を示す。

【図6】上記システムの例を示す。

【発明を実施するための形態】

【0025】

図１のフローチャートを参照すると、ＲＤＦグラフに対するＳＰＡＲＱＬクエリのための演算子のグラフ（すなわち、有向非巡回グラフあるいはＤＡＧ）をクエリエンジンによって生成するためのコンピュータ実施方法が提示される。当該方法は、上記クエリエンジンによって実行可能な演算子のグラフをストレージエンジンに問い合わせを行うことによって提供するステップを含む。当該提供されたグラフは、複数の基本演算子を含む。上記提供されたグラフの上記基本演算子のうちの少なくとも２つは、それぞれの基本グラフパターンにマッチする上記ＲＤＦグラフのＲＤＦトリプルを見つけ出すようにそれぞれが構成された第１のタイプの基本演算子である。上記方法は、上記提供されたグラフの上記第１のタイプである上記少なくとも２つの基本演算子の中から、演算子群を、当該演算子群のそれぞれの基本グラフパターンが同じ主語および／または述語および／または目的語を有するように識別するステップをさらに含む。上記ストレージエンジンに問い合わせが行われると、上記識別された演算子群は、当該演算子群のそれぞれの基本グラフパターンにマッチする上記ＲＤＦグラフのＲＤＦトリプルを見つけ出すように構成された等価演算子によって、上記提供されたグラフにおいて置換される。

【0026】

このような方法は、ＲＤＦグラフに対するＳＰＡＲＱＬクエリのための演算子のグラフの最適化による生成において改良されたソリューシ

【0027】

ョンとなる。当該最適化は、上記ストレージエンジンに問い合わせが行われると、いくつかの演算子からなる群を、演算子群のそれぞれの基本グラフパターンにマッチする上記ＲＤＦグラフのＲＤＦトリプルを見つけ出すことが可能な等価演算子によって、上記クエリの提供されたグラフにおいて置換することによって実現される。このような置換は、分散ストレージエンジンを呼び出すオーバーヘッドを削減することにより、通信コストを大きく削減するものである。

【0028】

特に、上記方法は、異なる物理的位置にわたって（すなわち、データの分布上で）ＲＤＦグラフ（すなわち、データの集まり）をどのように分散させるかについての前提要件無しに、このような最適化を実現する。上記方法が要件とするのは、上記ストレージエンジンが、それぞれの基本グラフパターンにマッチするＲＤＦグラフのＲＤＦトリプルを見つけ出すことによって上記クエリに応答することが可能であるということと、上記パーティショニング戦略が未知であるとされるということだけである。

【0029】

「データベース」とは、探索および検索のために編成されたデータ（すなわち、情報）の任意の集まり（例えば、グラフ指向データベース）を意味する。当該技術分野において公知であるように、グラフ指向データベースは、グラフ理論を用いた、したがってノードおよび弧を用いたオブジェクト志向データベースであり、データの表現および格納を可能にするものである。当該グラフは、ストア内のデータ項目をノードおよびエッジの集まりに関係付け、エッジは、ノード間の関係を表す。この関係により、ストア内のデータ同士を直接リンクさせることが可能となり、また、多くの場合において、１度の作業で当該データを検索することが可能となる。データを暗黙的な結合によってリンクさせる他のデータベースモデル（例えば、リレーショナルデータベース）とは対照的に、グラフデータベースは、データ間の関係を優先順位として保持している。メモリに格納された場合、グラフデータベースは、コンピュータによる迅速な探索および検索を可能にする。とりわけ、グラフデータベースは、様々なデータ処理作業と協働して、関係を高速に検索、修正および削除するように構築される。グラフ指向データベースは、グラフデータベースとも称される。すなわち、「グラフ指向データベース」および「グラフデータベース」という表現は同義である。

【0030】

一例では、上記グラフデータベースは、ＲＤＦグラフデータベースであってもよい。ＲＤＦグラフは、グラフの格納および検索のために使用される従来のデータモデルである。ＲＤＦグラフは、ラベル付けされた有向グラフデータ形式である。このような形式は、ウェブで情報を表現するために広く用いられている。情報のＲＤＦ表現をグラフとして指定するための標準規格がＷ３Ｃによって公開されている。例えば“RDF 1.1 Concepts and Abstract Syntax",Ｗ３Ｃ勧告、２０１４年２月２５日（あるいは、さらにＲＤＦ－ｓｔａｒの原案）を参照されたい。使用される抽象構文のコア構造は、それぞれが述語を含むタプルの集合である。このようなＲＤＦタプルの集合は、ＲＤＦグラフと呼ばれる。

【0031】

一例では、ＲＤＦタプルは、ノードおよびエッジを含む３つまたは４つの要素を含み得る。一例では、各ＲＤＦタプル（各ＲＤＦタプルの要素）は、主語、述語および目的語を含むトリプルであってもよい。このような一例では、ＲＤＦグラフはノードおよび有向弧の図として視覚化されてもよく、図中、各トリプルは、ノード－弧－ノードのリンクとして表現される。あるいは、ＲＤＦトリプルは、２つのノードによって視覚化されてもよく、これらのノードは、上記の主語および目的語と、これらを接続する弧（上記の述語）である。

【0032】

一例では、上記ＲＤＦタプルは、ＲＤＦクアッド（quad）であってもよい。ＲＤＦクアッドは、グラフラベルをＲＤＦトリプルに追加することによって得られてもよい。このような例において、ＲＤＦタプルは上記ＲＤＦグラフを含む。ＲＤＦクアッド（Ｎ－クアッドとも称される）を指定する標準規格がＷ３Ｃによって公開されている。例えば、“RDF 1.1 N-Quads, A line-based syntax for RDF datasets",Ｗ３Ｃ勧告、２０１４年２月２５日を参照されたい。ＲＤＦクアッドは、ＲＤＦトリプルにグラフ名を追加することによって得られてもよい。グラフ名は、空であるか（すなわち、デフォルトグラフまたは名称のないグラフの場合）、あるいはＩＲＩ（例えば、述語）であってもよい。各クアッドのグラフ名は、データセットにおいて当該クアッドがその一部を構成するグラフである。以下、ＲＤＦタプル（またはタプル）という用語は、その一方または他方の使用が明示されない限り、ＲＤＦトリプルまたはＲＤＦクアッドを区別なく指すものとする。

【0033】

ＲＤＦグラフデータベースは、数十億ものタプルを有し得る。例えば、Ｕｎｉｐｒｏｔデータセットは、タンパク質の配列および機能の情報源である。

【0034】

グラフデータベースのクエリエンジンの可能な最適化は、グラフデータベースが開世界または閉世界と相互作用するという仮定による影響を受ける。それ自体知られているように、知識表現に用いられるロジックの形式体系において、開世界仮説（ＯＷＡ）は、あるステートメントの真理値は、それが真であると知られているか否かにかかわらず、真であり得るという仮定である。これは、真である全てのステートメントは、真であるとしても知られているとする閉世界仮説とは逆である。一方、閉世界システムは、全てを配置するための場所を必要とする（例えば、フレーム上のスロット、オブジェクト指向クラス（OO class）上のフィールド、またはＤＢにおける列）。ＯＷＡは、意図的にあいまいに表現され、他者が再利用および拡張することが可能とされた不完全な情報をデフォルトで想定している。セマンティックウェブは、再利用可能な形式で分散された知識およびデータである、コンピュータが理解可能なウェブの構想であり、ＲＤＦ（セマンティックウェブについてのＷ３Ｃ勧告）は、開世界仮説に従う。これにより、データのモデル化およびデータの格納におけるフレキシビリティを高めることが可能になる。しかしながら、ＳＱＬを用いた関係モデルと同様に、閉世界仮説の制約は、クエリ最適化にとって有用である。なぜなら、当該制約は、データがどのようにして格納されているかについてより多くの情報を提供するからである。

【0035】

「ＲＤＦグラフに対するＳＰＡＲＱＬクエリの為の演算子のグラフを生成する」とは、当該ＳＰＡＲＱＬクエリのクエリプランに対応する演算子のグラフの生成することを意味する。「クエリプラン」または「クエリ実行プラン」とは、ＳＱＬリレーショナルデータベース管理システムにおけるデータにアクセスするために使用される一連のステップを意味する。それ自体知られているように、上記演算子のグラフは、ノード（すなわち、頂点）およびエッジを含み、各ノードは、上記一連の演算子に含まれる演算子に対応し、各エッジは、当該エッジによって接続される２つの演算子間の関係を定義する。上記演算子のグラフは、有向非巡回グラフ（ＤＡＧ）である。以下、ＤＡＧおよびグラフとう用語は、演算子に適用される場合、同義で用いられ得る。それ自体知られているように、このような演算子のグラフは、上記クエリエンジンによって生成される。

【0036】

一例では、上記クエリは、ＳＰＡＲＱＬクエリである。ＳＰＡＲＱＬは、ＲＤＦデータに問い合わせを行うためのＷ３Ｃ勧告であり、ＲＤＦトリプルのトリプルパターンの上に構築されたグラフマッチング言語である。ＳＰＡＲＱＬは、データがＲＤＦとしてネイティブに格納されるか、あるいはミドルウェアを介してＲＤＦとして視認されるかについて、多様なデータソースわたってクエリを表すことが可能なＲＤＦデータのためのクエリ言語である。ＳＰＡＲＱＬは、主として、グラフ準同型に基づく。グラフ準同型は、２つのグラフ間のその構造に関するマッピングである。より具体的には、隣接する頂点を隣接する頂点に対してマッピングする、２つのグラフの頂点集合間の関数である。

【0037】

ＳＰＡＲＱＬは、必須パラメータおよび任意パラメータをそれらの論理積および論理和と共に問い合わせる機能を備えている。ＳＰＡＲＱＬはまた、集約、サブクエリ、否定、式による値の生成、拡張可能な値の試験、およびソースＲＤＦグラフによるクエリの制約もサポートする。ＲＤＦトリプルのトリプルパターンとは、各主語、各述語または各目的語が（クエリの）変数であり得るＲＤＦトリプルを意味する。これは、ＳＰＡＲＱＬクエリが、ＳＰＡＲＱＬにおいて考えられる８つの異なるトリプルパターンに応答する必要があることを意味する。このような８つのトリプルパターンは、（Ｓ，Ｐ，Ｏ）、（Ｓ，？Ｐ，Ｏ）、（Ｓ，Ｐ，？Ｏ）、（Ｓ，？Ｐ，？Ｏ）、（？Ｓ，Ｐ，Ｏ）、（？Ｓ，？Ｐ，Ｏ）、（？Ｓ，Ｐ，？Ｏ）および（？Ｓ，？Ｐ，？Ｏ）を含み、当該パターンにおいて、変数の前に記号？が付されている。変数は、トリプルパターンの出力であり、ＳＰＡＲＱＬクエリの出力であってもよい。いくつかの例において、変数は、ＳＥＬＥＣＴクエリの出力であってもよい。ＳＰＡＲＱＬクエリの出力は、上記変数（例えば、加算のようなアグリゲータ）を用いて構築され得る。クエリにおける変数は、グラフ準同型（すなわち、クエリの結果を得るために必要な中間ノード）を構築するために使用され得る。いくつかの一例では、クエリにおける変数は、出力にも中間結果にも使用されなくてもよい。基本グラフパターン（ＢＧＰ）は、上記８つのトリプルパターンのうちの１つであってもよい。ＳＰＡＲＱＬは、いくつかのＢＧＰ、および場合によって他の演算子の結果を結合することにより、より複雑なクエリを構築し得る。よって、競争力のあるＳＰＡＲＱＬエンジンには、少なくとも、トリプルパターンの高速解法および効率的な結合方法が必要とされる。加えて、ＢＧＰにおいて結合される中間結果の量を最小化する効率的なプランを構築するために、クエリオプティマイザが必要とされる。

【0038】

一例では、上記グラフデータベースは、既存のトリプルストアを有する。トリプルストア（ＲＤＦストアとも称される）は、当該技術分野において公知であるように、セマンティッククエリを介したトリプルの格納および検索のための専用データベースである。トリプルストアは、少なくとも、上述のＳＰＡＲＱＬの８つの基本的なトリプルパターンに対して応答することができる。トリプルストアは、トリプルパターンと共に、フィルタリング制約（例えば、「ｘ＞５」）に対しても応答し得る。このようなトリプルストアは、クエリエンジンによってＳＰＡＲＱＬクエリが実行されるストレージエンジンであると考えられる。ストレージエンジン（「データベースエンジン」とも呼ばれる）は、当該技術分野において公知であるように、データベースからのデータの生成（Ｃｒｅａｔｅ）、読出し（Ｒｅａｄ）、更新（Ｕｐｄａｔｅ）および削除（Ｄｅｌｅｔｅ）（ＣＲＵＤ）のためにデータベース管理システム（ＤＢＭＳ）が使用する基本ソフトウェアコンポーネントである。加えて、一例では、上記トリプルストアは分散データベースである。「分散データベース」とは、例えばシステム管理者によって異なる物理的位置にわたってデータが格納されるデータベースを意味する。

【0039】

図１に戻り、ステップＳ１０において、上記方法は、上記クエリエンジンによって実行可能な演算子のグラフをストレージエンジンに問い合わせを行うことによって提供するステップを含む。「演算子のグラフ」とは、演算子のグラフを取得することを意味する。一例では、演算子のグラフ（ＤＡＧ）を提供するステップは、入力としてクエリプランを提供し、当該クエリプランを演算子のＤＡＧに変換するステップを含み得る。当該入力クエリプランは、クエリプラン最適化のための任意の方法による最適化済みクエリプランであってもよい。このような一例では、上記入力クエリプランは、演算子のＤＡＧである中間表現（Intermediate Representation）（以下、「ＩＲ」と称する）に変えられる。グラフ提供ステップは、当該技術分野における任意の標準的な方法によって実現され得る。一例では、ＲＤＦグラフは、２つ以上の部分グラフへの未知のパーティショニングを有する分散ＲＤＦグラフである。この１つまたは複数の部分グラフは、異なるメモリに格納されてもよい。「未知のパーティショニング」とは、上記１つまたは複数の部分グラフの分布が上記方法によって利用不可能であり、実施できないということを意味する。これは、上記方法が分散手法においてスケーラブルに、また、演算子のＤＡＧを生成することによって、分布においてパーティショニングを把握することもこれを課すこともなくクエリを最適化することを可能にする、改良されたソリューションとなる。例えば、このようなソリューションは、クエリ（すなわち、読出し）を、上記パーティショニング戦略が他の側面、例えば、書込みを最適化するように設定されている分散ＲＤＦグラフに対して最適化するのに完全に適している。

【0040】

演算子のＤＡＧは、複数の基本演算子で構成され、上記提供されたグラフの基本演算子のうちの少なくとも２つは、第１のタイプの基本演算子である。「基本グラフパターン」とは、Ｗ３Ｃの公式定義から公知であるようなトリプルパターンの集合を意味する。最も基本的な演算子（「Ｆｉｌｔｅｒ」等）は、基本ＳＰＡＲＱＬパターン（ＦＩＬＴＥＲ句等）に一対一でマッチしており、クエリプランから容易に生成される。上記第１のタイプの演算子は、それぞれの基本グラフパターンにマッチするＲＤＦグラフのＲＤＦトリプルを見つけ出すように構成されている（すなわち、「Ｆｉｎｄ」演算子）。上記基本グラフパターンは、上記クエリのそれぞれの基本演算子に対応する。換言すれば、上記１つまたは複数の基本演算子のそれぞれは、基本グラフパターンを実行するように構成されている。

【0041】

上記ＤＡＧの基本演算子のそれぞれは、上記クエリエンジンによる１つまたは複数の呼出しと同時に実行されてもよく、その結果、バッファと呼ばれるバッチに通常グループ化されるタプルのストリームを生成してもよい。その後、当該バッファは、ＤＡＧにおける次の演算子によって消費される。

【0042】

図１に戻り、ステップＳ２０において、上記方法は、上記提供されたグラフの上記第１のタイプである上記少なくとも２つの基本演算子の中から、演算子群を、当該演算子群のそれぞれの基本グラフパターンが、同じ主語および／または述語および／または目的語を有するように識別する。換言すれば、上記方法は、上記演算子の提供されたグラフにおいて特定のパターンを識別する。

【0043】

一例では、上記演算子群の上記それぞれの基本グラフパターンは、一定の述語を有する。これに代えて、あるいはこれに加えて、上記演算子群の上記それぞれの基本グラフパターンは、一定の目的語を有する。「一定の述語／目的語」とは、上記演算子群がグラウンド値（ground value）を有する述語／目的語を共有すること、すなわち、上記述語／目的語は上記クエリの変数ではなく、上記クエリによって指定される値を有することを意味する。さらに、これに代えて、あるいはこれに加えて、上記演算子群のそれぞれの基本グラフパターンは、同じ主語を有していてもよい。上記演算子群のそれぞれの基本グラフパターンは、一定の述語もしくは一定の目的語もしくは同じ主語、または一定の述語および一定の目的語、または一定の述語および同じ主語、または一定の目的語および同じ主語、または一定の述語および一定の目的語および同じ主語を含み得ることが理解される。上記演算子群のそれぞれの基本グラフパターンを上記ケースのそれぞれ（すなわち、一定の述語および／または一定の目的語および／または同じ主語）に限定することにより、上記等価演算子は、実装が容易でありかつストレージエンジン上で効率的な状態に維持される。上記方法により、ＳＰＡＲＱＬクエリにおいて頻繁に出現することが知られている様々な特定のパターンを実装するために必要な演算子の数がさらに削減される。各場合のための最適化は、ネットワークコスト、すなわちクエリエンジンに送信されるデータ量の削減に関して実現される。

【0044】

図１に戻り、ステップＳ３０において、上記識別された演算子群は、当該演算子群の上記それぞれの基本グラフパターンにマッチする上記ＲＤＦグラフのＲＤＦトリプルを見つけ出すように構成された等価演算子によって、上記提供されたグラフにおいて置換される。上記識別された演算子群を等価演算子によって「置換する」とは、上記方法が、当該群に属する演算子を上記演算子のグラフから除去し、上記等価演算子を上記演算子のグラフに追加することによって、演算子のグラフを「更新する」ことを意味する。上記等価演算子は、上記演算子群の演算子のうちの１つの代わりに追加されてもよい。例えば、上記群の第１の演算子は、上記演算子の提供されたＤＡＧにおいて出現する。

【0045】

一例では、上記提供されたグラフは、少なくとも１つの第２のタイプの基本演算子をさらに含む。当該第２のタイプの演算子は、１つまたは複数のＲＤＦトリプルおよびブール式を入力として受け付け、当該１つまたは複数のＲＤＦトリプルの部分集合を、当該部分集合におけるＲＤＦトリプルのそれぞれのトリプルの一部に対する上記ブール式の適用が真となるように出力するように構成され得る。換言すれば、上記第２のタイプの演算子は、「Ｆｉｌｔｅｒ」タイプの演算子であり、入力ＲＤＦトリプル（ＤＡＧにおける別の演算子の出力であり得る）をブール式に基づいてフィルタリング制約としてフィルタリングする。

【0046】

一例では、上記部分集合におけるＲＤＦトリプルのそれぞれのトリプルの上記一部は、それぞれのＲＤＦトリプルの主語および／または目的語を有する。換言すれば、等価演算子の後に、当該等価演算市の入力の上記主語および／または目的語のいずれかに対して作用する（すなわち、上記ＲＤＦトリプルのうちの１つの主語および／または目的語を有する）「Ｆｉｌｔｅｒ」タイプの演算子が続く場合、当該「Ｆｉｌｔｅｒ」タイプの演算子における式が検査され、可能な場合は、等価演算子内で制約に変えられる。

【0047】

一例では、上記方法は、上記提供されたグラフの上記少なくとも２つの第１のタイプの基本演算子の中から演算子群を識別するステップの前に、上記少なくとも１つの第２のタイプの基本演算子のそれぞれを、上記第１のタイプのそれぞれの基本演算子のすぐ後ろに移動させるステップをさらに含む。上記第１のタイプのそれぞれの基本演算子は、上記少なくとも１つの第２のタイプの基本演算子が受け付けるように構成されたＲＤＦトリプルを見つけ出すことが可能である。換言すれば、このような例において、上記方法は、「Ｆｉｌｔｅｒ」演算子を、これらをサポートすることができる「Ｆｉｎｄ」演算子の隣に移動させる。

【0048】

このような一例では、上記識別された等価演算子は、入力として制約を受け付けるようにさらに構成されてもよく、上記方法は、上記第２のタイプの上記少なくとも１つの基本演算子のそれぞれについて、当該第２のタイプの演算子を、少なくとも、部分的に制約の集合に変えられ得る式に分割するステップをさらに含む。「演算子を分割する」とは、当該演算子を変換することを意味する。上記分割ステップは、複雑な制約を含む単一の演算子を、それぞれがより単純な制約を含むいくつかの演算子（同じ「第２のタイプ」の演算子の全て）に変換し得る。上記方法は、上記第２のタイプの上記基本演算子を上記演算子のグラフから除去し、上記制約の集合を、少なくとも、上記第２のタイプの上記基本演算子のすぐ後ろの上記第１のタイプの上記それぞれの基本演算子を置換するそれぞれの等価演算子に入力するステップをさらに含み得る。このような置換は、ＤＡＧの演算子を組み合わせることによって分散ストレージエンジンを呼び出すオーバーヘッドを削減することにより、通信コストを削減するものである。

【0049】

上記制約のそれぞれは、上記ストレージエンジンによって検証されてもよい。上記等価演算子は、各ＲＤＦトリプルの主語および／または目的語に対して当該制約を適用してもよい。上記制約の集合は、以下のうちの少なくとも１つまたは複数を含む。数値制約（例えば、「等しい」、「異なる」、「超える」、「未満」）、値の種類または言語（例えば、英語、フランス語等）の種類に対する制約、および文字列についての制約（例えば、正規表現（ｒｅｇｅｘ）制約）。これに加えて、またはこの代わりに、上記制約の集合は、他の制約（例えば、日付に対する制約等）を含み得る。これにより、ストレージエンジンとクエリエンジンとの間で送信されるデータ量が削減される。なぜなら、これらの制約はストレージエンジンによって検査され、不適合な出力は直ちに（すなわち、クエリエンジンに送られる前に）排除されるからである。

【0050】

上記方法は、上記第２のタイプの上記少なくとも１つの基本演算子を移動させるステップの後であって、上記演算子分割ステップ（上述のような）の前に、そして、上記第２のタイプの各基本演算子について、当該第２のタイプの基本演算子を論理積形式に正規化するステップをさらに含み得る。「論理積形式」とは、ブール論理の分野で知られているような連言標準形を意味する。「基本演算子を正規化する」とは、当該演算子がＡＮＤＳＰＡＲＱＬ演算子、ＯＲＳＰＡＲＱＬ演算子およびＮＯＴＳＰＡＲＱＬ演算子を含む式を含む場合に、当該式が単純式（その一部がＮＯＴによって否定され得る）の論理和の論理積として書き直されることを意味する。正規化ステップの例において、上記方法は、制約を形状「（Ｃ１ＡＮＤＣ２）ＯＲＣ３」から「（Ｃ１ＯＲＣ３）ＡＮＤ（Ｃ２ＯＲＣ３）」に変換する。上記方法は、ブール式を含む全ての制約を、ＡＮＤ演算子が制約の第１のレベルに配置される（これは、上記文献において「論理積形式」と呼ばれる）ように修正してもよい。これがもたらす効果は、複雑な制約を簡単な制約に分割することがより簡単になるということである。なぜなら、ＯＲ式はいくつかの演算子に分割することができないが、ＡＮＤ式は分割可能であるからである。一例では、上記提供されたグラフ（すなわち、ＤＡＧ）は、少なくとも１つの第３のタイプの基本演算子をさらに含む。第３のタイプの基本演算子は、上記ＲＤＦグラフにおけるＲＤＦトリプルの要素の値にそれぞれが対応する１つまたは複数のインデックスを入力として受け付け、かつ当該インデックスのそれぞれの値を出力するように構成され得る。ＲＤＦトリプルの要素は、当該ＲＤＦトリプルの主語、目的語または述語のいずれかであってもよい。一般に、各インデックスは、ＲＤＦグラフにおける頂点の値、より具体的には、辞書における値、さらにより具体的には、ＲＤＦグラフからのＵＲＩリテラルまたはＲＤＦリテラルに対応し得る。換言すれば、第３のタイプの基本演算子は、後述するように「ＧｅｔＶａｌｕｅｓ」タイプの演算子であってもよい。各インデックスは、ＲＤＦグラフにおける頂点の値に対応するか、あるいは、辞書における値に対応する。それ自体知られているように、「辞書」とは、連想配列、マップ、記号表を意味する。あるいは、辞書は、（キー、値の）対の集まりであって、考えられる各キーが当該集まりにおいて最大で１回出現するような集まりで構成された抽象データ型である。

【0051】

このような例において、等価演算子は、第１のタグを入力としてさらに受け付けてもよい。加えて、上記方法は、上記少なくとも１つの第３のタイプの基本演算子のそれぞれについて、上記第３のタイプの上記演算子の対応するＲＤＦトリプルを見つけ出すことが可能な等価演算子を上記演算子のグラフにおいて識別するステップと、上記識別された等価演算子の上記第１のタグの値を予め定義された値に設定し、上記第３のタイプの上記演算子を上記提供されたグラフから除去するステップとをさらに含み得る。これにより、上記方法は、提供されたＤＡＧの「ＧｅｔＶａｌｕｅｓ」型演算子を等価演算子にさらに組み合わせることによって、呼出しのオーバーヘッドをさらに削減することが可能となる。

【0052】

一例では、上記演算子群の上記演算子のうちの少なくとも１つは、基本グラフパターンのための第２のタグを有する。第２のタグは、ＳＰＡＲＱＬにおいて知られているような「ＯＰＴＩＯＮＡＬ」タグであってもよい。その場合、等価演算子は、第２のタグを入力としてさらに受け付けてもよい。このような一例では、等価演算子は、上記演算子群における少なくとも演算子の上記それぞれの基本グラフパターンにマッチする上記ＲＤＦグラフの少なくともいずれかのＲＤＦトリプルを、上記第２のタグを得ることなく見つけ出してもよい。一例では、あるパターンが「ＯＰＴＩＯＮＡＬ」としてタグ付けされている場合、ストレージエンジンは、当該パターンが任意パターンに一致しない場合であっても、任意ではないパターンにマッチする第１のトリプル集合を返す。加えて、ストレージエンジンは、任意パターンに一致しかつその主語が上記第１の集合からのトリプルの主語でもあるトリプルを返す。これにより、等価演算子によるクエリに対する応答において、上記方法が改善される。なぜなら、ＲＤＦにおいてスキーマが存在しない場合、モデルは、所与のパターンについて、予想されるあらゆる述語に対してトリプルが存在することを保証することができず、ＯＰＴＩＯＮＡＬ句を含めることが必要となるからである。

【0053】

上記方法は、同じ主語および／または同じ目的語を有する少なくとも２つの等価演算子を上記演算子のグラフにおいて識別するステップと、上記ストレージエンジンに問い合わせが行われると、上記識別された２つの等価演算子を、上記識別された２つの等価演算子のそれぞれの識別された基本グラフパターンにマッチする上記ＲＤＦグラフのＲＤＦトリプルを見つけ出すことが可能な等価演算子によって置換するステップとをさらに含み得る。換言すれば、上記方法は、既に識別された２つの等価演算子を組み合わせ得る。これにより、演算子のＤＡＧの演算子をさらに組み合わせることによって、呼出しのオーバーヘッドがさらに削減される。

【0054】

上記方法は、コンピュータによって実施される。これは、上記方法のステップ（または実質的に全てのステップ）が少なくとも１つのコンピュータまたは任意の同様のシステムによって実行されることを意味する。したがって、上記方法のステップは、上記コンピュータにより、場合によっては、全自動または半自動で実施される。一例では、上記方法のうちの少なくともいくつかのステップの起動は、ユーザとコンピュータとの対話によって行われ得る。ユーザとコンピュータとの対話の必要なレベルは、想定される自動化のレベルに依存するものであってもよく、また、ユーザの意向を実現する必要性との間でバランスが取られてもよい。一例では、このレベルは、ユーザによって定義され、かつ／あるいは予め定義されてもよい。

【0055】

方法をコンピュータによって実施する典型的な例は、この目的に適合されたシステムを用いて方法を実施することである。このシステムは、方法を実施するための命令を含むコンピュータプログラムが記録されたメモリとグラフィカル・ユーザ・インターフェース（ＧＵＩ）とに結合されたプロセッサを備えていてもよい。このメモリは、データベースも格納していてもよい。当該メモリは、係る記憶に適合した任意のハードウェアであり、場合によっては、いくつかの物理的に別個の部分（例えば、プログラム用の部分、そして場合によっては、データベース用の部分）を含む。

【0056】

図６は、上記システムの一例を示し、本例において、システムは、クライアント・コンピュータ・システム、例えば、ユーザのワークステーションである。

【0057】

本例のクライアントコンピュータは、内部通信バス１０００に接続された中央処理装置（ＣＰＵ）１０１０および同じく当該バスに接続されたランダム・アクセス・メモリ（ＲＡＭ）１０７０を備える。このクライアントコンピュータは、上記バスに接続されたビデオ・ランダム・アクセス・メモリ１１００に関連付けられたグラフィック処理ユニット（ＧＰＵ）１１１０をさらに備える。ビデオＲＡＭ１１００は、当該技術分野においてフレームバッファとしても知られている。大容量記憶装置コントローラ１０２０は、ハードドライブ１０３０といった大容量メモリ装置に対するアクセスを管理する。コンピュータのプログラム命令およびデータの具現化に適した大容量メモリ装置としては、あらゆる形態の不揮発性メモリが含まれ、例としては、ＥＰＲＯＭ、ＥＥＰＲＯＭやフラッシュメモリ装置といった半導体メモリ装置；内蔵ハードディスクやリムーバブルディスクといった磁気ディスク；光磁気ディスク；およびＣＤ－ＲＯＭディスク１０４０が挙げられる。上記のいずれも、専用に設計されたＡＳＩＣ（特定用途向け集積回路）によって補足されるか、あるいはこれに組み込まれてもよい。ネットワークアダプタ１０５０は、ネットワーク１０６０に対するアクセスを管理する。クライアントコンピュータは、カーソル制御装置、キーボード等といった触覚装置１０９０も備えてもよい。カーソル制御装置は、ユーザがディスプレイ１０８０上の所望の位置にカーソルを選択的に配置できるようにするために、クライアントコンピュータにおいて使用される。さらに、カーソル制御装置は、ユーザが種々のコマンドを選択し、制御信号を入力することを可能にする。カーソル制御装置は、システムに対して制御信号を入力するための多数の信号生成装置を有する。典型的には、カーソル制御装置は、マウスであってもよく、上記信号を生成するためにマウスのボタンが使用される。これに代えて、あるいはこれに加えて、クライアント・コンピュータ・システムは、センシティブパッドおよび／またはセンシティブスクリーンを備えてもよい。

【0058】

上記コンピュータプログラムは、上記システムに上記方法を実施させるための手段を含む、コンピュータによって実行可能な命令を含み得る。上記プログラムは、上記システムのメモリを含む、任意のデータ記憶媒体に記録可能であってもよい。上記プログラムは、例えば、デジタル電子回路もしくはコンピュータハードウェア、ファームウェア、ソフトウェア、またはこれらの組み合わせで実装されてもよい。上記プログラムは、装置として、例えば、プログラマブルプロセッサによる実行のために機械可読記憶装置において具現化された製品として実装されてもよい。方法のステップは、入力データに対して操作を行い、出力を生成することによって、上記方法の機能を実施するための命令のプログラムをプログラマブルプロセッサが実行することによって実行されてもよい。したがって、上記プロセッサは、プログラマブルであってもよく、また、データ記憶システム、少なくとも１つの入力装置および少なくとも１つの出力装置からデータおよび命令を受信し、それらにデータおよび命令を送信するように結合されてもよい。アプリケーションプログラムは、高水準の手続き型またはオブジェクト指向型のプログラム言語で、あるいは、必要に応じて、アセンブリ語または機械語で実装されてもよい。いずれの場合も、言語は、コンパイルされた言語または翻訳された言語であってもよい。上記プログラムは、完全インストールプログラムまたは更新プログラムであってもよい。いずれの場合も、上記システムにプログラムを適用することにより、上記方法を実施するための命令が得られる。

【0059】

上記方法の上述の例の実施態様例について以下に述べる。

【0060】

実施態様例は、結合される中間結果の数を最小化することを目的とした、ＳＰＡＲＱＬクエリオプティマイザの分野に関する。実施態様一例では、分散データベースである、上述のような既存のトリプルストアが存在するとする。このようなクエリオプティマイザの目的は、基本トリプルストアとの通信コストを削減することによって、かつ、異なる物理的位置にわたって（すなわち、データの分布上で）データの集まりをどのように分散させるかについての前提要件なしに、クエリを最適化することである。基本トリプルストアが分散データベースではない場合の考慮事項について、以下に述べる。

【0061】

実施態様例は、実行不能である未知のパーティショニングを含む、基本トリプルストアを有する分散データベースによるＳＰＡＲＱＬクエリ（の性能）の最適化に関する。換言すれば、実施態様例は、ＳＰＡＲＱＬにおける８つの異なる可能なトリプルパターンに応答することのみが要求される分散ＲＤＦストレージエンジンに対してＳＰＡＲＱＬクエリの性能を最適化する。パーティショニング戦略は、未知であるとする。実施態様例は、「ＳＰＡＲＱＬコア」と呼ばれるクエリエンジン内でＳＰＡＲＱＬクエリを最適化する処理を行う。換言すれば、実施態様例は、上記トリプルストアによる、ＳＰＡＲＱＬコアクエリエンジン内でのＳＰＡＲＱＬクエリの最適化に関する。

【0062】

分散ＲＤＦグラフにおいては、パーティション上でトリプルマッチを探し、それが見つからないということは、キャッシュミスと同等であるとみなされ得る。ＭａｐＲｅｄｕｃｅあるいはクエリパーティショニングの代わりに、実施態様一例では、演算をひとまとめにグループ化して、それらの演算を単一のトリプルではなくトリプルのブロックに適用するクエリプランを作成する。例えば、グラフパターンのマッチングは、主語および／または述語および／または目的語（これらはグラフも含むように拡張可能である）のベクトルに対して行われる。制約（例えば、フィルタ）は、従来の最適化（ＳＱＬにおいてテーブルスキャンに対してプッシュダウンされた制約）と同様に、これらのベクトルと共にプッシュダウンされてもよい。これにより、ネットワーク上の饒舌さが低減する。すなわち、ネットワークは、メインメモリのベクトル化におけるＣＰＵと同様に、最適化すべきリソースであると考えられる。換言すれば、実施態様一例では、パーティション上でトリプルが見つからないということは、メインメモリのベクトル化におけるキャッシュミスと同様に、隠すべき欠陥であると考えられる。実施態様一例では、パーティショニング戦略に対する要件は無く、不要なデータがクエリエンジンまでプルされることはない。これは、ＭａｐＲｅｄｕｃｅのような手法の欠点を有しない、グラフ演算のために完全に最適化されたクラウドベースの手法である。したがって、実施態様例は、ネットワークを介して送られるデータに関して、基本トリプルストアのデータまたはグラフのパーティショニングに対する要件無しに、分散環境においてＳＰＡＲＱＬクエリを最適化する。

【0063】

ＳＰＡＲＱＬ内でのＳＰＡＲＱＬクエリの実行のワークフロー例が図２に示されている。実施態様一例では、「ｑｕｅｒｙＰｌａｎＴｏＩＲ」から「ＯｐｔｉｍｉｓｅｄＩＲ」までのステップのこのような実行を最適化する。「ＩＲ」という用語は、「中間表現」を表し、これは、一部のクエリエンジンが、ＬＬＶＭにおける中間表現としてコンパイル済みコードを生成することが可能であるということに由来する。このコード生成は、ベクトル化におけるメインメモリの単一ノード最適化と同様の趣旨で公知の方法によって実行され得る。

【0064】

このようなメインメモリ最適化について以下に述べる。

【0065】

実施態様例は、メインメモリ・データベース上でクエリ（またはサブクエリ）を実行するためのクエリ最適化技術から着想を得たものである。インメモリデータベース（ＩＭＤＢ、メモリ・データベース・システムすなわちＭＭＤＢ、またはメモリ常駐データベースともいう）は、コンピュータデータの格納を主としてメインメモリに依存するデータベース管理システムである。当該システムは、ディスク格納機構を採用するデータベース管理システムとは対照的である。インメモリデータベースは、ディスク最適化型データベースよりも高速である。なぜなら、ディスクへのアクセスはメモリへのアクセスよりも低速であり、また、内部最適化アルゴリズムは、より単純であり、実行するＣＰＵ命令数がより少ないからである。分散データベースは、メインメモリ・データベース（例えば、ＮｕｏＤＢ）であってもよい。

【0066】

メインメモリクエリ処理の先行技術は、ベクトル化（例えば、これは、ＮｕｏＤＢクエリエンジンの最新バージョンに当てはまる）と呼ばれる技術により、実行するＣＰＵ命令をできる限り少なくすることである。要約すると、ベクトル化は、ＣＰＵを最適化することと、ただ１つのタプルではなく、タプルのブロックに対して演算を実行することによってキャッシュミスを隠すこととで構成される。

【0067】

ほとんどのクエリエンジンにおいて、各関係演算子は、Ｖｏｌｃａｎｏ式の反復を用いて実装される。このモデルは、ディスクが主なボトルネックであった過去においては良好に機能していたが、インメモリデータベース管理システム（ＤＢＭＳ）用の最新のＣＰＵにおいては非効率である。したがって、最新クエリエンジンのほとんどは、ベクトル化（例えば、ＶｅｃｔｏｒＷｉｓｅ）またはデータ処理を中心とするコード生成（例えば、ＨｙＰｅｒ）のいずれかを使用している。Ｖｏｌｃａｎｏ式の反復モデルと同様、ベクトル化は、各演算子が結果タプルを生成する次の方法を有する、プル型反復を使用する。しかしながら、次の呼出しはそれぞれ、ただ１つのタプルではなく、タプルのブロックを取り出し、これにより、反復子を呼び出すオーバーヘッドが償却される。実際のクエリ処理作業は、１つまたは複数のタイプ特化列に対して簡単な演算を実行する（例えば、整数のベクトルについてハッシュを演算する）プリミティブによって行われる。償却およびタイプ特化は共に、従来のエンジンのオーバーヘッドのほとんどを解消する。

【0068】

データの全てを単一のマシン上のメインメモリに有している必要があるため、メインメモリのベクトル化クエリ処理には、いくつかの欠点がある。したがって、スケーラブルなソリューションではない。なぜなら、クエリエンジンおよびデータが必ずしも同じマシン上に存在しない、ＲＤＦグラフ上の分散クエリにこのような処理を使用することで、単一のマシン上のキャッシュに全てのデータを有することが必要となるからである。この方法は、ただ１つの物理的位置で実行されるクエリのサブパートにのみ使用され得る。

【0069】

上記実施態様例は、入力としてクエリプランを有し得る。入力クエリプランは、クエリプラン最適化のための任意の方法に従って最適化されてもよい。すなわち、「最適化済みクエリプラン」であってもよい。実施態様例は、入力クエリプランを演算子の有向非巡回グラフ（ＤＡＧ）であるＩＲに変える。あるいは、いくつかの変形一例では、実施態様例は、入力として演算子のＤＡＧを有し得る。

【0070】

演算子のＤＡＧにおける演算子は、クエリ実行の基本要素に対応する。すなわち、各演算子は、バッファと呼ばれるバッチに通常グループ化された、タプルのストリームを生成する。次いで、各演算子のバッファは、ＤＡＧにおける次の演算子によって消費される。演算子の実行は、基本トリプルストア、ＲＤＦターム（すなわち、算術的な文字列変換等）に対する一般的な計算の呼出しに対応する。ＲＤＦタームは、２０１４年２月２５日のＷ３Ｃ勧告、RDF 1.1 Semanticsに示されている。

【0071】

演算子のＤＡＧは、ストレージエンジンに問い合わせを行うことにより、クエリエンジンによって実行可能である。この実行は、概して、マルチスレッド化されている。換言すれば、タプルバッファは、次の演算子によって直ちに消費されるか、後の実行のためにキューに入れられてもよく、別の待機スレッドによって「奪われ（stolen）」（すなわち、引き継がれ）てもよく、この場合、当該スレッドは対応する演算子を実行する。

【0072】

実施態様例は、反復性を有していてもよく、また、ＩＲをより効率的にするために、すなわち、特に、冗長計算を無くすこと、定数を伝播させること、ＩＲ生成のアーティファクトを除去すること、および、演算子の数を削減することによって「最適化済みＩＲ」を得るために、ＩＲに対していくつかの「変換パス」を適用してもよい。例えば、実施態様例は、基本的なトリプルパターン演算子を組み合わせて、多数の述語を有する単一の演算子としてもよい。実施態様例は、基本トリプルストアとの通信コストを最適化するために、演算子の数のこのような削減を行ってもよい。

【0073】

その後、演算子は、ＩＲエグゼキュータ（Executor）であるマルチスレッド化「実行エンジン」によって復号化されるか実行され、あるいは、生成済みコードに変換される。「エグゼキュータ・コンテキスト（executor context）」または「生成済みコード」は、「クエリレコード」のリストを出力し、次いで、これらはＳＰＡＲＱＬコアのクエリレコード処理部に送られる。

【0074】

実施態様に係る中間表現、すなわちＩＲは、以下の要素で構成される。（ｉ）以下に詳述する演算子ＤＡＧ（有向非巡回グラフ）。（ｉｉ）ＩＲが単純な整数によって参照できるように、ＩＲに含まれるすべての定数値およびインデックスを含む定数表。以下において、「演算子が定数を含む」とは、定数表における対応する定数をルックアップすることができる定数ＩＤを当該演算子が含むことを意味する。実施態様例は、定数表を用いて、ＩＲＤＡＧ自体に値を数回格納する（これによって計算コストが高くなり得る）ことを回避する。これにより、定数表におけるあらゆる値に対応するあらゆるインデックスを１回の呼出しで取り出す（またはその逆を行う）ことによって実施態様例が改良される。（ｉｉｉ）ＳＰＡＲＱＬにおけるＳＥＬＥＣＴ句、ならびにＯＲＤＥＲＢＹ句、ＬＩＭＩＴ句およびＤＩＳＴＩＮＣＴ句の内容に対応する後処理パラメータ。ＳＥＬＥＣＴ、ＯＲＤＥＲＢＹ、ＬＩＭＩＴおよびＤＩＳＴＩＮＣＴは、ＳＰＡＲＱＬにおいて周知である。

【0075】

実施態様例によれば、演算子ＤＡＧは、「演算子」とよばれるノードがエグゼキュータの基本演算を表す、演算子のグラフである。演算子ＤＡＧは、１つの根（すなわち、グラフの始点）および１つの葉（すなわち、グラフの終点）を有し得る。この１つの葉は、ｅｍｉｔ演算子である。

【0076】

ＤＡＧにおける演算子は、３種類のデータ、すなわち、インデックス、値および／またはフラグを操作し得る。

【0077】

インデックスは、ストレージエンジンにおけるインデックスに対応しており、「ＩＳｔｏｒａｇｅＥｎｇｉｎｅ：ｆｉｎｄ」に対する呼出しの主要な出入力として主に使用される。一例では、「ｕｎｄｅｆｉｎｅｄ」インデックスが存在する。値は、任意のＲＤＦ値、すなわち、空白ノード、ＵＲＩおよびリテラル（型付き（typed）リテラルおよび言語タグ付きリテラルの両方）、ならびに２つの特殊な値、すなわち、評価誤差を表す「ｕｎｅｖａｌｕａｂｌｅ」およびいずれの値にもバインドされていない変数を表す「ｕｎｄｅｆ」である。一例では、式の評価のほとんどが値に対してなされ、クエリの最終的な結果は値のリストである。実施態様一例では、ストレージエンジンは、インデックスから値を得る方法および、これとは逆に、特定の値に対応するインデックスを得る方法を提供する。同期バリアを実装するために、実行エンジンによってフラグが使用される。

【0078】

あらゆるクエリ実行の最終結果は、値のタプルのリストである。このリストは、クエリにマッチするタプルが存在しない場合は、空であってもよい。各演算子の入出力は、タプルのリストである。これらのタプルは、０個以上のインデックス、値およびフラグを含み得る。上記タプルのリストはバッファと呼ばれ、インデックス、値およびフラグは、バッファの「列」と呼ばれ、バッファの個々のタプルはバッファの「ライン」と呼ばれる。列は、それらのインデックスおよび種類（インデックス、値またはフラグ）によって定義される。列のインデックスは、論理値である。すなわち、入力バッファ内の位置ではなく、識別子である。実施態様例における実行エンジンは、論理値をバッファ内の位置にマッピングする役割を担う。インデックス列および値列は、元のクエリにおける変数、またはＩＲ生成または変換パス中に生成された一次変数に対応し得る。同じ識別子を有するインデックス列および値列は、同じ論理変数に対応し得る。フラグ列と、同じ識別子を有するインデックス列／値列との間に相関は無くてもよい。

【0079】

実施態様例は、各演算子を、毎回異なるバッファ上で、数回実行してもよい。実施態様例は、「ベクトル化済み」実行エンジンも使用してもよく、各演算子を数個のラインを含むバッファ上で実行してもよい。これは、個々の演算子実行の呼出し１回あたりのオーバーヘッドを削減し、ストレージエンジンに対する合計呼出し数を削減することによる、最適化された実行となる。

【0080】

あらゆる演算子の出力は、ＤＡＧにおける当該演算子の子（存在する場合）のそれぞれの入力である。根演算子の入力は、ラインが１個で列が０個であるバッファであり、葉演算子の出力は、通常、全てが値である列を有するバッファである。実施態様例は、タプルが「ＱｕｅｒｙＲｅｃｏｒｄｓ」に変換され、「ＱｕｅｒｙＲｅｃｏｒｄＰｒｏｃｅｓｏｒ」に送られる前に、葉演算子の出力バッファの後処理を行ってもよい。実施態様は、当該技術分野で公知である任意の方法によって後処理を行ってもよい。

【0081】

次に、図３を参照し、基本的な例について述べる。

【0082】

以下のクエリ:

【0083】

【数1】

【0084】

を図３に従ってＤＡＧに変える。ここで、ｉ０，ｉ１，．．．は、インデックス列０，１，．．．に対応し、同様に、ｖ０，ｖ１，．．．は、値列０，１，．．．に対応する。

【0085】

図３の各矢印は、前のノードの出力（次の演算子あるいは子演算子の入力である）である列の集合を示す。第１のノードの入力列の集合３０１は、定義上、空である。第１の「Ｆｉｎｄ」ノードは、２つのインデックス列ｉ０およびｉ１（元のクエリの変数？ａおよび？ｂに対応する）を生成し、これらは当該ノードの出力に現れる。第２の「Ｆｉｎｄ」ノードは、第３のインデックス列ｉ２を生成する。このノードはまた、列ｉ０をその出力に保持している。なぜなら、列ｉ０は後に必要であるからである。しかし、列ｉ１は、当該「Ｆｉｎｄ」の後は不要であり、したがって、破棄される。

【0086】

これらの「Ｆｉｎｄ」ノードは、元のクエリにおける個々のＢＧＰに対応しており、その実行は、「ＩＳｔｏｒａｇｅＥｎｇｉｎｅ：：ｆｉｎｄ」に対する呼出しである。各「Ｆｉｎｄ」ノードは、その挙動を決定するパターンを有する。例えば、第１のノードは、パターン「＊＜ｐ＞＊」に適合し得る全ての主語および目的語のインデックスを見つけ出し、これらをインデックス列ｉ０およびｉ１にマッピングする。第２の「Ｆｉｎｄ」ノードは、列ｉ１を入力として使用する。換言すれば、その入力ラインのそれぞれについて、このノードは、「ｉ１＜ｑ＞＊」にマッチするあらゆるインデックスを見つけ出し、各応答（もしあれば）について、元のタプルのｉ０を含むラインと当該応答とを出力する。

【0087】

「ＧｅｔＶａｌｕｅｓ」は、列ｉ０およびｉ１、すなわち、ｖ０およびｖ１に対応する値を上記ストレージから取得し、それらを値列に出力する。図３の一例では、「ＧｅｔＶａｌｕｅｓ」は、後で必要とされないｉ０およびｉ１を破棄するが、それらが後にクエリにおいて必要とされる場合は保持する。

【0088】

「Ｅｍｉｔ」ノードは、常に、ＤＡＧの葉ノードである。このノードは、その出力を後処理部に転送する。図３の一例では、後処理部は、ノード「Ｅｍｉｔ」の出力を「ＱｕｅｒｙＲｅｃｏｒｄｓ」のリストに変える。

【0089】

それ自体知られているように、２つのグラフパターンを組み合わせる２項演算子である「ＯＰＴＩＯＮＡＬ」パターンがＳＰＡＲＱＬにおいて存在する。「ＯＰＴＩＯＮＡＬ」パターンは、任意の群パターンであり、ＳＰＡＲＱＬパターンのタイプを要し得る。当該群がマッチする場合、解は拡張され、一致しない場合、元の解が与えられる。ＳＰＡＲＱＬにおけるＯＰＴＩＯＮＡＬは、ＩＲにおいて特定の処理を必要とする。

【0090】

以下に、実施態様例における基本演算子について述べる。

【0091】

●「Ｆｉｎｄ」：この演算子は、それぞれが定数、（種類インデックスの）入力列または（同じく種類インデックスの）出力列であり得る３つのパラメータ（主語、述語および目的語）を含む「パターン」を有する。入力列は、存在する場合、「ｕｎｄｅｆ」インデックスを含むことはできない。この演算子は、「ＩＳｔｏｒａｇｅＥｎｇｉｎｅ：：ｆｉｎｄ」に対する呼出しに対応し、各入力ラインについて、０個、１個または複数個の出力ラインを生成し得る。

【0092】

●「ＧｅｔＶａｌｕｅｓ」：１つまたは複数のインデックス列が与えられると、この演算子は、対応する値列を出力に追加する。この演算子は、未定義のインデックスを有する入力列を受け付ける（かつ、その場合は未定義値を返す）。

【0093】

●「ＧｅｔＩｎｄｅｘ」：この演算子は、「ＧｅｔＶａｌｕｅｓ」に付属する。すなわち、値列が与えられると、対応するインデックス列を生成する。

【0094】

●「Ｅｍｉｔ」：ＤＡＧの葉ノードであり、その入力を後処理部に送る。

【0095】

●「Ｆｉｌｔｅｒ」：ブ―ル型の値を生成する式が与えられると、「Ｆｉｌｔｅｒ」は、この式を各ラインに対して実行し、当該式の有効ブ―ル値が真に等しい場合は、その場合に限り、当該ラインを出力にコピーする。一部の式は、ブ―ル値の代わりに、誤差を値としてさらに返してもよい。エラー値はフィルタを通過しない。

【0096】

●「ＣｏｍｐａｒｅＩｎｄｅｘ」：この演算子は、ブ―ルフラグ「ｅｑｕａｌ」を有していてもよく、２つのインデックス列が与えられると、当該２つの列が等しい（すなわち、「ｅｑｕａｌ」が真である）か、あるいは異なる（すなわち、「ｅｑｕａｌ」が偽である）場合は、その場合に限り、ラインを出力にコピーする。

【0097】

実施態様例は、後述されるような「ＳｔａｒＦｉｎｄ」と呼ばれる別の演算子を含み得る。「ＳｔａｒＦｉｎｄ」演算子は、「Ｆｉｎｄ」に類似した基本的な前提（いくつかの入力および１つのパターンが与えられると、「Ｆｉｎｄ」は、当該パターンにマッチするものを出力する）を有するが構造および挙動がより複雑である新たな演算子である。実施態様例において、「ＳｔａｒＦｉｎｄ」演算子は、「Ｆｉｎｄ」のパターンと類似し、以下の性質を有する、１つまたは複数のパターンを含み得る。

【0098】

－上記1つまたは複数のパターンが２つ以上のパターンを含む場合、全てのパターンは同じ主語を有し、
－上記１つまたは複数のパターンのそれぞれの述語は定数であり（すなわち、変数ではなく）、かつ／または
－上記１つまたは複数のパターンのそれぞれの目的語は定数または出力列でなくてはならない。

【0099】

上記の性質に加えて、上記パターンのいずれかにおける各主語、各述語または各目的語は、値および／またはインデックスを必要とするとしてタグ付けがなされ得る。これに代えて、あるいはこれに加えて、「ＳｔａｒＦｉｎｄ」演算子は、制約の集合であって、当該集合が生成し得る出力を制限する集合（すなわち、「Ｆｉｌｔｅｒ」）をサポートする。

【0100】

意味論上、実施態様例に係る１つの「ＳｔａｒＦｉｎｄ」演算子は、いくつかの基本演算子の組み合わせに対応する。すなわち、
－各パターンは、Ｆｉｎｄ演算子に対応し、
－値を必要とするとしてタグ付けされた主語、述語または目的語は、「ＧｅｔＶａｌｕｅｓ」演算子に対応し、かつ／または
－各制約は、「Ｆｉｌｔｅｒ」演算子に対応する。「ＳｔａｒＦｉｎｄ」演算子は、ストレージエンジンによって実装される。

【0101】

実施態様一例では、したがって、バッチ（すなわち、バッファ）に対する「ＳｔａｒＦｉｎｄ」演算子の各実行は、ストレージエンジンに対する１回の呼出しであり、これは基本演算子を用いた数回の呼出しに相当する。

【0102】

実施態様例は、複数個のパターンを有する「ＳｔａｒＦｉｎｄ」演算子を使用し得る。ＲＤＦモデル化における回帰性の規則的パターンは、ＳＱＬ表の個々の行に対応する複数の主語が、ＳＱＬ表の列に対応する述語の制限されたセットを有するトリプルの中に現れる、表のような状態である。開世界仮説に従っているため、データ形式が物理的に表に分割されていると想定することはできないものの、ＳＰＡＲＱＬクエリが、同じ主語を共有しかつ一定の述語を有するいくつかのトリプルを含むことはしばしばある。このような多数のパターンを有するあらゆるクエリについて、いくつかのＦｉｎｄ演算子の代わりに１つの「ＳｔａｒＦｉｎｄ」演算子を使用することができる。

【0103】

「ＳｔａｒＦｉｎｄ」演算子の実施態様例は、「ｖａｌｕｅ」タグを使用し得る。それ自体知られているように、Ｆｉｎｄ演算子は、上記データベースからインデックスを見つけ出す。ＳＰＡＲＱＬクエリにおける変数が、結果として返されるか、あるいはＦＩＬＴＥＲ句またはＢＩＮＤ句（特に）において使用されることが予想される場合は常に、当該変数について、Ｆｉｎｄ演算子の後に「ＧｅｔＶａｌｕｅｓ」演算子が続かなくてはならない。実際には、ほぼすべてのクエリは、Ｅｍｉｔ演算子の前の少なくとも１つの「ＧｅｔＶａｌｕｅｓ」演算子で終わる。実施態様一例では、Ｆｉｎｄの代わりにＳｔａｒＦｉｎｄが使用できる場合は常に、「ＳｔａｒＦｉｎｄ」演算子の「ｒｅｔｕｒｎｖａｌｕｅａｓｗｅｌｌａｓｉｎｄｅｘ」タグによって、「ＧｅｔＶａｌｕｅｓ」演算子は不要となる。多くのクエリの場合、ＧｅｔＶａｌｕｅｓ演算子は、完全に排除することが可能である。

【0104】

「ＳｔａｒＦｉｎｄ」演算子の実施態様例は、数値制約（例えば、「等しい」、「異なる」、「超える」、「未満」）、値の種類または言語の種類に対する制約および／または文字列についての特定の制約（例えば、正規表現（ｒｅｇｅｘ）制約）といった、当該演算子のパターンの主語および目的語に適用され得る制約の集合をサポートし得る。実施態様例は、これらの制約をストレージエンジンによってチェックしてもよく、不適合な出力は直ちに（すなわち、クエリエンジンに送られる前に）排除される。これにより、ストレージエンジンとクエリエンジンとの間で送信されるデータ量がしばしば大きく削減される。加えて、実施態様例は、例えば、ＳＱＬスキーマが、閉世界構成においてデータのトラバースを最適化するために利用され得るのと同様に、ストレージエンジンによる制約を、データトラバースを最適化するために活用してもよい。

【0105】

実施態様一例では、「ＳｔａｒＦｉｎｄ」演算子は、主語および／または目的語に対する２つ以上の制約を有することをサポートする。このような一例では、上記主語および／または目的語はあらゆる制約にマッチし得る。このことは、ある範囲の値に目的語を制約するために有用である。さらに、「ＳｔａｒＦｉｎｄ」演算子は、制約を否定することをサポートしてもよく、その場合、制約に一致しない目的語だけが保持される。

【0106】

実施態様例は、「ｏｐｔｉｏｎａｌ」タグを許可することにより、「ＳｔａｒＦｉｎｄ」演算子をさらに最適化してもよい。ＲＤＦにスキーマが存在しない状況では、モデルは、所与の主語について、予想されるあらゆる述語に対してトリプルが存在することを多くの場合保証しない。したがって、モデルのような「有向目的語」の場合でさえ、ＢＧＰの一部または全部がＯＰＴＩＯＮＡＬ句の内部に配置される場合がしばしばある。実施態様一例では、「ＳｔａｒＦｉｎｄ」は、各パターンに対して「ｏｐｔｉｏｎａｌ」タグを許可する。このような実施態様一例では、パターンが「ｏｐｔｉｏｎａｌ」としてタグ付けされている場合、ストレージエンジンは、当該パターンが任意パターンに一致しない場合であっても、任意ではないパターンにマッチする主語を返す。そして、任意パターンにマッチするトリプルが存在する場合、ストレージエンジンは、当該トリプルも返さなくてはならない。換言すれば、「ＳｔａｒＦｉｎｄ」は、１つのＢＧＰを含むＯＰＴＩＯＮＡＬ句の等価物をサポートする。

【0107】

「ＳｔａｒＦｉｎｄ」の実施態様例は、いくつかの制限を、サポートされたパターンにおいて適用してもよい。換言すれば、「ＳｔａｒＦｉｎｄ」は、クエリにおいて見つけ出され得る全てのパターンをサポートしなくてもよい。特に、上述のように、「ＳｔａｒＦｉｎｄ」は、そのパターン内にあるあらゆる述語が定数であることを要件とし得る。このような制限により、「ＳｔａｒＦｉｎｄ」は、ストレージエンジン上で効率的に実装するのに十分な程度に簡潔な状態に維持される。ＳｔａｒＦｉｎｄの目的は、ストレージエンジン上で完全なクエリを実行することではなく、ＳＰＡＲＱＬクエリにおいて頻繁に出現することが知られている非常に特殊なパターンの実装に必要な演算子の数を削減することである。

【0108】

したがって、実施態様例は、パーティショニング戦略の実施が不可能である場合、例えば、書込み性能を最適化するためにパーティショニング戦略が選択され、当該戦略が変更される場合に、分散ＲＤＦグラフに対するＳＰＡＲＱＬクエリの性能を最適化する。実施態様一例では、パーティショニング戦略は未知であるとされる。特に、実施態様例は、パーティショニング戦略を実施することなく、分散ストレージエンジンのコストを最小化するために、ＩＲの生成を最適化する。

【0109】

このような最適化を実現するため、実施態様は、いくつかの基本演算子を置換することが可能である新たな「ＳｔａｒＦｉｎｄ」演算子を定義する。実施態様は、主語および／または述語および／または目的語のベクトルを用いて、「ＳｔａｒＦｉｎｄ」演算子をできる限り多く生成するために、ＩＲの生成をさらに最適化する。加えて、実施態様例は、Ｃｏｎｓｔｒａｉｎｔｓおよび／またはＧｅｔＶａｌｕｅｓをＳｔａｒＦｉｎｄ演算子に付加する。

【0110】

実施態様例に係るＳＰＡＲＱＬクエリのための最適化されたＩＲ生成の例について、以下に述べる。

【0111】

ＩＲは、まず、基本演算子のみを含む未最適化形式で生成されてもよい。上記クエリは、まず、抽象構文木に構文解析されてもよく、当該構文解析は、その要素の一部を並べ替えるか、あるいは明らかに無用な構成（クエリにおけるＦＩＬＴＥＲ（ＴＲＵＥ）句等）を削除することにより、必要に応じて、最適化されてもよい。必要に応じて最適化されるこの構文木は、クエリプランと呼ばれる。

【0112】

最も基本的な演算子（「Ｆｉｌｔｅｒ」等）は、基本ＳＰＡＲＱＬパターン（ＦＩＬＴＥＲ句等）に一対一でマッチしており、上記クエリプランから容易に生成される。しかし、ＩＲは、２つの追加の制約（ＳＰＡＲＱＬパターンと比較して）を有してもよい。すなわち、

【0113】

－ＩＲにおける「Ｆｉｎｄ」演算子は、当該演算子に対する出力である（すなわち、上記クエリプランにおいて先に出現していない）変数を、入力である（すなわち、上記クエリプランにおいて先に出現した演算子における出力であった）変数と区別してもよい。これは、先の演算子から値を受けとったか、あるいは受け取らなかった変数を受け付け得る、ＳＰＡＲＱＬにおける（そして上記クエリプランにおける）グラフパターンとは異なる。この場合、演算子のグラフは、２つの枝、すなわち、変数が入力である場合の１つの枝と、変数が出力である場合の１つの枝とを含み得る。

【0114】

－ＩＲにおける「Ｆｉｎｄ」演算子は、上記辞書からのみインデックスを検索してもよく、後の演算子が（検索されたインデックスに）対応する値を必要とする場合、（対応する値を得るために）「ＧｅｔＶａｌｕｅｓ」演算子が当該演算子の前に挿入されてもよい。加えて、「ＧｅｔＶａｌｕｅｓ」演算子が、ＳＰＡＲＱＬクエリのＳＥＬＥＣＴ句に出現する変数のために必要となり得る。

【0115】

実施態様一例では、クエリプランの１つの枝が、ＩＲにおけるいくつかの枝に対応していてもよい。例えば、１つの枝において変数？ａを生成するが、別の枝では生成しないＵＮＩＯＮノードを有するクエリと、同じ変数？ａが出現するＢＧＰとが与えられると、ＩＲは、この１つのＢＧＰに対して２つの「Ｆｉｎｄ」演算子を含んでいてもよく、当該演算子の一方は、変数？ａが入力であるＵＮＩＯＮの第１の枝に対応し、他方は、変数？ａが出力であるＵＮＩＯＮの第２の枝に対応する。

【0116】

実施態様例は、クエリプランのトラバースされたノードの数においてＯ（ｎ）の複雑性を維持しながら、重複パターンの数をできる限り最小化するために、ＳＰＡＲＱＬＣｏｒｅによって実装されるアルゴリズムを含む。実施態様例は、以下の２つの制約に従うＩＲを生成するための生成アルゴリズムのみを必要とする。

【0117】

－いくつかの枝が、変数？ｘを含む「Ｆｉｎｄ」演算子に繋がる場合、それらの経路の全てが当該変数？ｘを生成するか、あるいはいずれも当該変数？ｘを生成せず、かつ

【0118】

－いずれかの演算子（「Ｆｉｌｔｅｒ」等）が変数の値を読み出す必要がある場合、「Ｆｉｎｄ」演算子によって提供されるインデックスから当該値を生成するために、当該演算子の前に「ＧｅｔＶａｌｕｅｓ」ノードが出現する。

【0119】

クエリプランからＩＲを生成するアルゴリズムは、当該技術分野において公知であるいかなるアルゴリズムであってもよい。このようなアルゴリズムのいくつかは、先行技術において利用可能であるが、生成されるＩＲの品質、アルゴリズムの簡潔性およびアルゴリズムの実行時間との間の様々な妥協を伴う。

【0120】

ＳＰＡＲＱＬＣｏｒｅのＩＲ生成アルゴリズムの一例について以下に述べる。

【0121】

上述のように、ＩＲは、修正された構文木であるクエリプランから関数ｑｕｅｒｙＰｌａｎＴｏＩＲによって生成され得る。クエリプランにおけるノードは、グラフパターンと呼ばれる。ＤＡＧの規則を遵守しつつ、できる限り小数のノードを用いてＤＡＧを生成するため、ｑｕｅｒｙＰｌａｎＴｏＩＲは、フロンティア法に基づく（frontier-based）アルゴリズムを実装してもよい。

【0122】

上述のように、「列」は、変数のインデックスまたは変数の値のいずれであってもよい。「Ｆｉｎｄ」演算子は変数のインデックス列を生成し、「ＧｅｔＶａｌｕｅｓ」演算子はインデックス列から値列を生成する。「ｑｕｅｒｙＰｌａｎＴｏＩＲ」は、それ自体で知られているような深さ優先探索アルゴリズムによってクエリプランをトラバースしてもよい。このトラバースのいずれかのステップにおいて、ＤＡＧにおいて現在生成されている全ての枝のリスト、および、各枝について、当該枝における演算子によって生成された全ての列の集合を維持してもよい。この枝のリストは、フロンティアと呼ばれる。次いで、上記アルゴリズムは、自身がトラバースしているＧｒａｐｈＰａｔｔｅｒｎを解析し、上記枝にいくつかの演算子を付加し、付加された演算子から新たなフロンティアを生成する。

【0123】

上記フロンティアにおける２つの枝が、定義された列の同じ集合を有する場合、上記アルゴリズムの次のステップは、同一の演算子をこれらに付加し、これにより、当該２つの枝を併合することができる。より詳細には、２つの枝は、当該２つの枝のいずれかに存在する各列について、以下の場合に併合が可能である。

【0124】

●当該列が、いかなるＴｒｉｐｌｅＰａｔｔｅｒｎによってもクエリにおいて後で読み出されない場合、または
●当該列が、両方の枝において定義済みであるか、あるいは両方の枝において未定義である場合。

【0125】

クエリにおいて「後で」読み出される列は、決定列と呼ばれる。各ＧｒａｐｈＰａｔｔｅｒｎについての決定列の集合は、ｑｕｅｒｙＰｌａｎＴｏＩＲの開始前に１回のパスで計算され、それにより、Ｏ（ｎ）の複雑性が維持される。

【0126】

したがって、ＧｒａｐｈＰａｔｔｅｒｎをトラバースするための完全なアルゴリズムは、以下のようなものとなる。

【0127】

●現在のＧｒａｐｈＰａｔｔｅｒｎについての決定変数の集合を取得し、

【0128】

●各決定列が枝に存在するか否かを記述するビットマップを計算し、当該ビットマップをハッシュ表におけるキーとして用いることにより、同じ決定列集合を有する全ての枝をフロンティアにおいて見つけ出し、かつ
●所与の決定列集合を有する枝の全ての集合について、
〇ＧｒａｐｈＰａｔｔｅｒｎと当該決定列集合とに対応する新たな演算子リストを生成し、
〇当該演算子リストの先頭をこれらの枝のそれぞれに付加し、かつ
〇当該リストの末尾を新たなフロンティアに追加する。

【0129】

演算子に対するＧｒａｐｈＰａｔｔｅｒｎのマッピングの例について以下に述べる。

【0130】

あるＴｒｉｐｌｅＰａｔｔｅｒｎについて、実施態様例は、１つの「Ｆｉｎｄ」演算子を生成してもよく、当該ＴｒｉｐｌｅＰａｔｔｅｒｎのあらゆる変数は、当該変数がＧｅｎｅｒａｔｉｏｎＣｏｎｔｅｘｔにおいて定義されている場合は入力となり、そうでない場合は出力となる。

【0131】

あるＦｉｌｔｅｒＰａｔｔｅｒｎについて、フィルタ式に出現する変数がＧｅｎｅｒａｔｉｏｎＣｏｎｔｅｘｔにおいて対応するインデックス列を有するが、対応する値列は有しておらず、「Ｆｉｌｔｅｒ」演算子が当該式をバイトコード形式で含む場合、実施態様例は、「ＧｅｔＶａｌｕｅｓ」演算子を生成してもよい。

【0132】

あるＯｐｔｉｏｎａｌＰａｔｔｅｒｎについて、実施態様例は、新たなフラグを有する「ＯＰＴＩＯＮＡＬ」演算子を生成し、現在のＧｅｎｅｒａｔｉｏｎＣｏｎｔｅｘｔを有する任意句（「ＯＰＴＩＯＮＡＬ」演算子に対応する）を生成し、「ＳｅｔＦｌａｇ」演算子を付加してもよい。実施態様例は、当該枝の末尾を新たなフロンティアにさらに追加し、上記ＯｐｔｉｏｎａｌＰａｔｔｅｒｎの元のＧｅｎｅｒａｔｉｏｎＣｏｎｔｅｘｔを有するフロンティアに上記「ＯＰＴＩＯＮＡＬ」演算子の第２の子を追加してもよい。

【0133】

一部のタイプの演算子（例えば、上述の「ＳｔａｒＦｉｎｄ」）は、ＧｒａｐｈＰａｔｔｅｒｎｓからは生成されず、代わりに、ＩＲＤＡＧを簡潔化および最適化する変換パスによって生成される。

【0134】

変換パスの例および最適化について以下に述べる。

【0135】

実施態様例において、ＩＲＤＡＧのデータ構造により、ＤＡＧのトラバースおよび修正に役立つ関数が提供される。これらの関数は、いくつかの変換またはチェックパスを実装するために使用され得る。加えて、変換パスは、「ＳｔａｒＦｉｎｄ」演算子生成パスであってもよい。

【0136】

実施態様例において、「ＳｔａｒＦｉｎｄ」演算子の生成は、いくつかのパスで進行する。まず、並び替え（すなわち、移動）パスは、可能な場合には、あらゆる「Ｆｉｌｔｅｒ」演算子を、当該「Ｆｉｌｔｅｒ」演算子に含まれる変数を生成する最後の「Ｆｉｎｄ」演算子のすぐ後ろに移動させる。換言すれば、このステップは、「Ｆｉｌｔｅｒ」演算子を、これらを制約としてサポートすることが可能な「Ｆｉｎｄ」演算子の隣に移動させる。次に、全ての「Ｆｉｌｔｅｒ」演算子を論理積形式に正規化する。換言すれば、ＡＮＤＳＰＡＲＱＬ演算子、ＯＲＳＰＡＲＱＬ演算子およびＮＯＴＳＰＡＲＱＬ演算子を含む式を「Ｆｉｌｔｅｒ」が含む場合、「Ｆｉｌｔｅｒ」の対応する式を単純式（その一部はＮＯＴによって否定され得る）の論理和の論理積として書き直す。次いで、「Ｆｉｌｔｅｒ」演算子を、制約に変えることが可能な式、可能でない式に分割（すなわち、変換する）。「Ｆｉｌｔｅｒ」演算子は、当該演算子が既に、分割することなく制約に変えることが可能な単純式である場合は分割されなくてもよい。

【0137】

次に、一定の述語と、出力または一定の目的語とを有する「Ｆｉｎｄ」演算子を、１つのパターンを有する「ＳｔａｒＦｉｎｄ」演算子に変える。この新たな「ＳｔａｒＦｉｎｄ」の後に、その主語または目的語に対して作用するＦｉｌｔｅｒが続く場合、当該Ｆｉｌｔｅｒにおける式を検査し、可能な場合には、当該式を「ＳｔａｒＦｉｎｄ」内の制約に変える。同様に、「ＳｔａｒＦｉｎｄ」演算子がＯｐｔｉｏｎａｌ句に対応するノード内に出現している場合、当該ノードを除去し、ＳｔａｒＦｉｎｄにおけるパターンを「ｏｐｔｉｏｎａｌ」としてタグ付けする。次いで、演算子のグラフにおける連続する「ＳｔａｒＦｉｎｄ」演算子を検査する。当該演算子が同じ主語を有する場合、そのパターンと、その主語に対する制約とを組み合わせることにより、これらを併合する。最後に、別のパスにより、全ての「ＧｅｔＶａｌｕｅｓ」演算子を見つけ出し、「ＧｅｔＶａｌｕｅｓ」演算子内部の変数が「ＳｔａｒＦｉｎｄ」演算子によって生成されたか否かを判定するためにグラフを上る。その場合、上記変数を「ＧｅｔＶａｌｕｅｓ」演算子から排除し、「ＳｔａｒＦｉｎｄ」演算子に、値および対応する変数のインデックスを返すべきであるということを示すタグを追加する。

【0138】

ＩＲＥｘｅｃｕｔｏｒは、実行エンジンにおいてベクトル化を実現するためのインタプリタである。換言すれば、ＩＲが与えられると、ＩＲＥｘｅｃｕｔｏｒは、多数のスレッドに対してＩＲを解釈して実行し、ＱｕｅｒｙＲｅｃｏｒｄｓ．５．６．１３の形式でクエリ応答を生成する。ＩＲＥｘｅｃｕｔｏｒは、当該技術分野において公知であるいかなる方法に従うものであってもよい。

【0139】

実施態様例のクエリに対する適用例について、図４および図５を参照して以下に述べる。

【0140】

一例として、以下のクエリを取り上げる。

【0141】

【数2】

【0142】

先行技術によるクエリの演算子のグラフは、図４に示されるようなものであり、図中、各「Ｆｉｎｄ」演算子および各「ＧｅｔＶａｌｕｅｓ」演算子は、ストレージエンジンに対するバッチあたり１回の呼出しに対応する。クエリが１バッチのみを必要とする程度に短いものであると仮定すると、これは、ストレージエンジンに対して５回の呼出しが行われることを示す。

【0143】

本発明によれば、演算子のグラフは以下の通りである。

【0144】

実施態様例に係る演算子のグラフは図５のようなものである。同図から分かるように、ストレージエンジンに対する個々の呼出しに必要な演算子の数が１に減少しており、これにより、分散ストレージエンジンの呼出しのオーバーヘッドが大きく削減される。さらに、実施態様例において定義される「ＳｔａｒＦｉｎｄ」演算子の存在により、各演算子とクエリエンジンとの間を往復したであろう中間データはクエリエンジンを通過する必要がない。これにより、クエリのネットワークコストが大きく削減される。

【図1】