Loading article…
GQL（Graph Query Language）は、プロパティグラフのための標準化されたクエリ言語であり、ISO/IEC 39075で初めて記述され、2024年4月にISO/IECによってリリースされました。
GQLプロジェクトは、2016年に遡る複数の取り組みの集大成であり、特に2016年7月にNeo4jが他のデータベースベンダーに非公開で提案したこと[ 1 ] 、および同年後半にISO/IEC JTC 1標準化プロセス内でOracleの技術スタッフが提案したこと[ 2 ]が挙げられます。
2019年9月、新しい標準グラフクエリ言語（ISO/IEC 39075 情報技術 - データベース言語 - GQL）[ 3 ]を作成するプロジェクトの提案が、ISO/IEC合同技術委員会1（ISO/IEC JTC 1 ）のメンバーである各国標準化団体の投票により承認されました。JTC 1は、国際的な情報技術標準を担当しています。GQLは、 SQLのような宣言型データベースクエリ言語となることを意図しています。
2019年のGQLプロジェクト提案書には次のように記載されている。
データモデリングの基本的な表現方法としてグラフを用いる方法は、データ管理における新たなアプローチとして注目されています。このアプローチでは、データセットをグラフとしてモデル化し、各データエンティティをグラフの頂点（ノードとも呼ばれる）として、2つのエンティティ間の関係を対応する頂点間のエッジ（リンクとも呼ばれる）として表現します。グラフデータモデルは、その独自の利点から注目を集めています。
まず、グラフモデルは、階層構造、複雑な構造、あるいは任意の構造を持つデータセットに自然に適合します。このような構造は、グラフモデルではエッジとして容易に表現できます。これは、データセットを固定行型のテーブルに正規化する必要があるリレーショナルモデルよりも便利です。
第二に、グラフモデルは、到達可能性クエリ、最短または最も安いパス クエリ、中心性分析など、データ エンティティ間のマルチ ホップ関係を観察する必要があるコストのかかるクエリやデータ分析関数を効率的に実行することを可能にします。現在使用されているグラフ モデルには、リソース記述フレームワーク(RDF) モデルとプロパティ グラフ モデルという 2 つのモデルがあります。RDF モデルは、W3C によって多数の仕様で標準化されています。一方、プロパティ グラフ モデルは、グラフ データベース、グラフ アルゴリズム、グラフ処理機能で多数の実装があります。しかし、プロパティ グラフ用の共通の標準化されたクエリ言語 (リレーショナル データベース システム用の SQL のようなもの) がありません。GQL はこの空白を埋めるために提案されています。[ 4 ]
GQL規格であるISO/IEC 39075:2024 情報技術 - データベース言語 - GQLは、2024年4月12日にISOによって正式に発行されました。[ 5 ]
GQLプロジェクトは、Stefan Plantikow氏（ Neo4jのCypher for Apache Sparkプロジェクトの初代リードエンジニア）とStephen Cannan氏（SQLのテクニカル訂正編集者）が主導しています。彼らはまた、GQL仕様の初期作業草案の編集者でもあります。[ 6 ]
当初の動機どおり、[ 2 ] GQL プロジェクトは、実装可能な規範的自然言語仕様の作成作業を補完し、JTC 1 国際標準を定義する正式なプロセスに参加できない、または参加に興味のない人々からの貢献を可能にする支援的なコミュニティ活動を行うことを目指しています。[ 7 ] [ 8 ] 2019 年 7 月、Linked Data Benchmark Council (LDBC) は、コミュニティ技術ワーキンググループの活動の包括的な組織となることに合意しました。既存言語ワーキンググループとプロパティグラフスキーマワーキンググループは、それぞれ 2018 年後半と 2019 年初頭に結成されました。GQL の正式な指示的意味論を定義するワーキンググループは、2019 年 10 月の第 3 回 GQL コミュニティアップデートで提案されました。[ 9 ]
7 つの国家標準化団体 (米国、中国、韓国、オランダ、英国、デンマーク、スウェーデン) が、このプロジェクトに取り組むために各国の専門家を指名しており、このプロジェクトは ISO/IEC JTC 1 の小委員会 32 (データ管理および交換) のワーキング グループ 3 (データベース言語) によって実施され、通常はISO/IEC JTC 1/SC 32 WG3または単にWG3と略されます。WG3 (および JTC 1 内のその直接の前身となる委員会) は、1987 年以来 SQL 標準を担当しています。[ 10 ] [ 11 ]
GQL は、プロパティ グラフ専用のクエリ言語です。プロパティ グラフは、エンティティ関係モデルやUMLクラス図で表現される概念データ モデルによく似ています(ただし、2 つ以上のエンティティをリンクする n 項関係は含まれません)。グラフでは、エンティティはノードとして、関係はエッジとしてモデル化されます。プロパティ グラフはマルチグラフです。つまり、同じノード ペア間に複数のエッジが存在する可能性があります。GQL グラフは混合型です。エッジの一方の端点ノードがテール (またはソース) で、もう一方のノードがヘッド (またはターゲットまたは宛先) である有向エッジを含むことができますが、無向 (双方向または反射) エッジを含むこともできます。
ノードとエッジは、まとめて要素と呼ばれ、それぞれ属性を持ちます。これらの属性は、データ値またはラベル（タグ）です。プロパティの値はグラフの要素にはなり得ませんし、グラフ全体にもなり得ません。これらの制約は、グラフのトポロジーと、グラフのトポロジーのコンテキストでデータ値を持つ属性との間に明確な分離を意図的に強制するものです。したがって、プロパティグラフデータモデルは、グラフのネスト、つまりあるグラフのノードを別のグラフのエッジとして扱うことを意図的に防止します。各プロパティグラフは、グラフ全体に関連付けられたラベルのセットとプロパティのセットを持つことができます。
GQLクエリは、この構造に対するパターンマッチングによって動作します。ノードは括弧で囲まれ、オプションでラベルとプロパティが付けられます。関係は、ノード間の角括弧で囲まれ、オプションで方向とタイプが付けられます。クエリ結果は、グラフパターンを照合し、ノード、エッジ、またはパスにバインドされた変数を返すことによって生成されます。[ 13 ]
現在のグラフデータベース製品やプロジェクトでは、ここで説明するモデルの限定版がサポートされていることが多い。たとえば、Apache Tinkerpop [ 14 ]では、各ノードと各エッジに単一のラベルを強制している。Cypher では、ノードに 0 個から複数のラベルを付けることができるが、関係には単一のラベル (reltype と呼ばれる) しか付けられない。Neo4j のデータベースでは、文書化されていないグラフ全体のプロパティがサポートされており、Tinkerpop には同じ役割を果たすグラフ値があり、「メタプロパティ」またはプロパティのプロパティもサポートされている。Oracle の PGQL では、ノードとエッジに 0 個から複数のラベルがサポートされているが、SQL/PGQ では、各タイプの要素に 1 個から複数のラベルがサポートされている。ETSIが規定するNGSI-LD情報モデルは、プロパティグラフを正式に規定しようとする試みであり、前述のモデルでラベルの役割を果たす可能性のあるノードと関係 (エッジ) のタイプがあり、共有オントロジーで定義されたクラスを継承することで意味参照をサポートしている。
GQLプロジェクトは、これらのバリアントのスーパーセットとなるであろう標準データモデルを定義する予定であり、少なくともGQLの最初のバージョンでは、SQL/PGQと同様に、ベンダーが各実装におけるラベルのカーディナリティを決定したり、無向関係をサポートするかどうかを選択したりできるようになる見込みである。
ERMモデルやUMLモデルの追加的な側面（汎化やサブタイピング、エンティティやリレーションシップのカーディナリティなど）は、一般データモデルの可能なインスタンスを記述するGQLスキーマや型によって捉えることができる。
GQLを解釈できる最初のインメモリグラフデータベースが利用可能になった。[ 15 ] [ 16 ]実装とは別に、GQLの特定のサブセットの形式化を見つけて構文を読むこともできる。[ 17 ]
GQL プロジェクトは、既存の産業用言語や SQL 標準の新しいセクションなど、複数のソースや入力を活用しています。WG3 内の準備的な議論では、これらの入力のいくつかの歴史[ 18 ]や比較内容[ 19 ]の調査が行われました。GQL は独自の構文を持つ宣言型言語であり、データベース アプリケーションの構築において SQL と同様の役割を果たします。他のグラフ クエリ言語は、分岐やループなどの直接的な手続き機能 (Apache Tinkerpop のGremlin [ 20 ]や GSQL [ 21 ]など定義されており、グラフを反復的に走査してグラフ アルゴリズムのクラスを実行できますが、GQL はそのような機能を直接組み込むことはありません。[ 22 ] [ 23 ]ただし、GQL は、グラフ型システムとグラフを処理するプロシージャの呼び出しインターフェースを共有する、より一般的なグラフ言語のクラスの特定のケースとして想定されています。
WG3 および SC32 ミラー組織による以前の作業、特にINCITSデータ管理 (旧 INCITS DM32) では、SQL 標準の新しい計画パート 16 の定義に役立っており、これにより、読み取り専用のグラフ クエリを SQL SELECT ステートメント内で呼び出すことが可能になり、Cypher、PGQL、および G-CORE に非常に近い構文を使用してグラフ パターンに一致し、結果としてデータ値のテーブルが返されます。SQL/PGQ には、SQL テーブルを、ラベルのセットとデータ プロパティのセットに関連付けられたノードとエッジを持つグラフ ビュー スキーマ オブジェクトにマッピングできるようにする DDL も含まれています。[ 24 ] [ 25 ] [ 26 ] GQL プロジェクトは、ISO 9075 SQL (拡張) の SQL/PGQ 「プロジェクト分割」と密接に連携しており、米国 (INCITS DM32) および国際レベル (SC32/WG3) の技術ワーキング グループには、両方のプロジェクトに取り組む専門家貢献者が複数います。[ 25 ] GQLプロジェクトの提案では、SQL/PGQとGQLの密接な整合性が求められており、GQLは一般的にSQL/PGQの上位セットとなることが示されています。
パターンマッチング言語の詳細については、論文「Graph Pattern Matching in GQL and SQL/PGQ」[ 27 ] [ 28 ]を参照してください。
Cypher [ 29 ]は、もともと Andrés Taylor と Neo4j Inc. の同僚によって設計され、2011 年に同社によって初めて実装された言語です。2015 年以降、オープンソースの言語記述[ 30 ]として、文法ツール、 Cypher クエリを解析するJVMフロントエンド、および実装言語の移植性のためにCucumberを使用した 2000 を超えるテスト シナリオの技術互換性キット (TCK) とともに利用可能になっています。[ 31 ] TCK は、Cypher 改善提案で文書化された言語記述と時間データ型および関数の拡張を反映しています。[ 32 ]
Cypherはグラフ要素の作成、読み取り、更新、削除を可能にする言語であり、そのため分析エンジンやトランザクションデータベースに使用できる。
Cypher は、ノードと関係 (エッジ) トポロジの視覚的表現とラベルの存在およびプロパティ値の述語を組み合わせた、コンパクトな固定長および可変長のパターンを使用します。(これらのパターンは通常「ASCII アート」パターンと呼ばれ、元々は低レベルのグラフ API を使用するプログラムにコメントする方法として生まれました。[ 18 ] ) クエリは、このようなパターンをグラフ データ要素に照合することで、関心のあるノード、関係、およびパスへの参照を抽出できます。これらの参照は、列名がグラフ要素のマルチセットにバインドされる「バインディング テーブル」として出力されます。列の名前は「バインディング 変数」の名前になり、その値はテーブルの各行の特定のグラフ要素参照になります。
例えば、あるパターンでは2列の出力テーブルが生成されます。最初の列には、ラベルが のノードへの参照が含まれます。2番目の列には、ラベル のノードへの参照が含まれ、これはその人が住んでいる都市を示します。 MATCH (p:Person)-[:LIVES_IN]->(c:City) p Person c City
バインディング変数とを逆参照することで、変数によって参照される要素に関連付けられたプロパティ値にアクセスできます。例のクエリはで終了し、次のような完全なクエリになります。 p c RETURN
MATCH ( p : Person ) -[ : LIVES_IN ]-> ( c : City ) RETURN p . first_name , p . last_name , c . name , c . stateこれにより、グラフに格納されている都市の住民の名前を一覧にした、最終的な4列の表が作成されます。
パターンベースのクエリは、同じバインディング変数を使用する複数のパターンを組み合わせることで結合を表現できます。これにより、句を使用して自然な結合を表現します。 MATCH
MATCH ( p : Person ) -[ : LIVES_IN ]-> ( c : City ), ( p : Person ) -[ : NATIONAL_OF ]-> ( EUCountry ) RETURN p . first_name , p . last_name , c . name , c . stateこのクエリは、EU国民の居住地のみを返します。
外部結合は次のように表現できます。 MATCH ... OPTIONAL MATCH
MATCH ( p : Person ) -[ : LIVES_IN ]-> ( c : City ) OPTIONAL MATCH ( p : Person ) -[ : NATIONAL_OF ]-> ( ec : EUCountry ) RETURN p . first_name , p . last_name , c . name , c . state , ec . nameこのクエリは、居住情報を持つグラフ内の各人物の居住都市と、EU国民の場合は出身国を返します。
したがって、クエリはまず、クエリに入力されたグラフのサブグラフを投影し、次にそのサブグラフに関連付けられたデータ値を抽出することができます。データ値は、集計関数などの関数によって処理することもでき、その結果、投影されたグラフに保持されている情報をさまざまな方法で表現する計算値が投影されます。G-COREとMorpheusに倣い、GQLは、マッチングパターンによって定義されたサブグラフ（およびそれらのサブグラフ上で計算されたグラフ）を、クエリによって返される新しいグラフとして投影することを目指しています。
大まかに言うと、GQLはクエリの評価と実行中に3つの重要な要素を監視します。
このようなパターンはプロパティグラフクエリ言語で広く用いられるようになり、SQL/PGQで定義されている高度なパターンサブ言語の基礎となっています。このサブ言語は、GQL言語のサブセットとなる可能性が高いです。Cypherも挿入句と変更句（および）にパターンを使用しており、GQLプロジェクトでは、グラフ型を記述するためのノードパターンとエッジパターンを収集する提案がなされています。 CREATE MERGE
Cypher の現在のバージョン (時間拡張機能を含む) は Cypher 9 と呼ばれています。GQL プロジェクトの前には、スキーマや構成可能なグラフクエリとビューなどの機能を組み込んだ新しいバージョン Cypher 10 [ REF HEADING BELOW ] を作成する計画がありました。グラフの構築と投影を含む Cypher 10 の最初の設計は、2016 年開始の Cypher for Apache Spark プロジェクトで実装されました。[ 33 ]
PGQL [ 34 ] は Oracle Inc. が設計および実装した言語ですが、JVM 解析ソフトウェア [ 36 ] とともにオープンソース仕様 [ 35 ] として公開されています。PGQLは、 SQL式、結果の順序付け、集計などの馴染みのある SQL SELECT 構文と、Cypher に非常によく似たパターンマッチング言語を組み合わせています。クエリ対象のグラフの仕様を指定でき、マクロを使用して「パターン ビュー」または名前付きサブ パターンをキャプチャする機能が含まれています。挿入または更新操作はサポートされておらず、Oracle の PGX 製品などの分析環境向けに主に設計されています。PGQL は Oracle Big Data Spatial and Graph や研究プロジェクト PGX.D/Async [ 37 ]でも実装されています。
G-CORE は、学術および産業分野の研究者と言語設計者のグループによって設計された研究言語で、Cypher、PGQL、およびSPARQLの機能を活用しています。[ 38 ] [ 39 ]このプロジェクトは、Linked Data Benchmark Council (LDBC) の後援の下で実施され、2015 年後半にグラフクエリ言語タスクフォースが結成され、論文執筆作業の大部分は 2017 年に行われました。G-CORE は、グラフ上で閉じられた構成可能な言語です。グラフ入力は、グラフ射影とグラフ集合操作を使用して新しいグラフを構築し、グラフ出力を作成するために処理されます。G-CORE クエリは、副作用のないグラフ上の純粋関数であり、つまり、この言語は、格納されているデータを変更 (更新または削除) する操作を定義しません。G-CORE は、ビュー (名前付きクエリ) を導入します。また、グラフの要素としてパスを組み込み（「パスを第一級市民として扱う」）、投影パス（クエリ時にノードとエッジ要素で計算される）とは独立してクエリを実行できます。G-COREは、LDBC GitHub組織のオープンソース研究プロジェクトで部分的に実装されています。[ 40 ] [ 41 ] [ 42 ]
GSQL [ 21 ]はTigerGraph Inc. の独自グラフデータベース用に設計された言語です。2018 年 10 月以降、TigerGraph の言語設計者は GQL プロジェクトを推進し、開発に取り組んでいます。GSQL は、手続き型フロー制御と反復処理、およびプログラム実行に関連付けられた計算値をグラフ全体またはアキュムレータと呼ばれるグラフの要素に対して収集および変更する機能を備えたチューリング完全な言語です。これらの機能は、反復的なグラフ計算をデータ探索および取得と組み合わせることができるように設計されています。GSQL グラフは、すべての挿入と更新を制約する頂点とエッジのスキーマによって記述する必要があります。したがって、このスキーマは SQL スキーマの閉じた世界特性を持ち、GSQL のこの側面 (Morpheus プロジェクト[ 43 ]から派生した設計提案にも反映されています) は、GSQL の重要なオプション機能として提案されています。
頂点とエッジは、データを含むだけでなく、暗黙の行型に関連付けられたSQL テーブルがデータ コンテナであるのと同様に、推定型を定義する名前付きスキーマ オブジェクトです。GSQL グラフは、これらの頂点とエッジ セットから構成され、複数の名前付きグラフが同じ頂点またはエッジ セットを含めることができます。GSQL は、2017 年 9 月のリリース以来、新しい機能を開発してきました。[ 44 ]特に注目すべきは、Cypher、PGQL、SQL/PGQ で見られる構文に関連する構文を使用する可変長エッジ パターン マッチング[ 45 ]の導入です。これは、Microsoft SQL/Server Graph [ 46 ]が提供する固定長パターンにもスタイルが近いものです。
GSQLは、グラフのサブセットに対してロールベースのアクセス制御を可能にするマルチグラフ[ 47 ]の概念もサポートしています 。マルチグラフは、異なるユーザーに対してきめ細かなアクセス制御が必要なエンタープライズ規模のグラフにとって重要です。
opencypher Morpheus プロジェクト[ 33 ]は、Apache Spark ユーザー向けに Cypher を実装しています。2016 年に開始されたこのプロジェクトは、当初、Morpheus の設計者も参加した 3 つの関連プロジェクト (SQL/PGQ、G-CORE、および複数のグラフのクエリと構築のための Cypher 拡張機能の設計) と並行して実行されました。[ 48 ] Morpheus プロジェクトは、グラフ DDL とクエリ言語の拡張という 2 つの領域における Cypher の拡張 (「Cypher 10」として知られる) のテストベッドとして機能しました。
グラフDDLの機能には[ 49 ]が含まれます
グラフクエリ言語の拡張機能には[ 49 ]が含まれる。
これらの機能は、GQLプロジェクトにおけるプロパティグラフクエリ言語の標準化へのインプットとして提案されている。
GQLクエリでは、パスクエリを使用して2つのノード間のさまざまな種類のパス（最短パス、単純パス、ウォークパス、非巡回パスなど）を返すことができます。ただし、これはパスの存在のみをテストするものであり、重みやコストなどの複雑なパス特性に関する推論はサポートされていません。たとえば、パス内の隣接するエッジの重みを比較することはできません。