Loading article…
グラフデータベース( GDB ) は、ノード、エッジ、プロパティを使用してデータを表現および格納するセマンティッククエリにグラフ構造を使用するデータベースです。 [ 1 ]このシステムの重要な概念は、グラフ(またはエッジまたは関係) です。グラフは、ストア内のデータ項目をノードとエッジの集合に関連付け、エッジはノード間の関係を表します。関係により、ストア内のデータを直接リンクでき、多くの場合、1 つの操作で取得できます。グラフデータベースは、データ間の関係を優先的に保持します。関係はデータベースに永続的に格納されているため、関係のクエリは高速です。グラフデータベースを使用すると、関係を直感的に視覚化できるため、相互接続性の高いデータに役立ちます。[ 2 ]
グラフデータベースは一般的にNoSQLデータベースと呼ばれています。グラフデータベースは、どちらも一般的なグラフを表現するという点で1970年代のネットワークモデルデータベースに似ていますが、ネットワークモデルデータベースはより低いレベルの抽象化で動作し[ 3 ] 、エッジの連鎖を簡単にたどることができません[ 4 ] 。
グラフデータベースの基盤となるストレージメカニズムは様々です。グラフデータベースでは、リレーションシップは第一級オブジェクトであり、ラベル付け、方向付け、プロパティの付与が可能です。リレーショナルエンジンに依存し、グラフデータをテーブルに格納するものもあります（ただし、テーブルは論理要素であるため、このアプローチではグラフデータベース管理システムと物理ストレージデバイスの間に抽象化レベルが設けられます）。また、キーバリューストアやドキュメント指向データベースをストレージとして使用するものもあり、これらは本質的にNoSQL構造となります。
2021年現在グラフクエリ言語は、リレーショナルデータベースにおけるSQLのように普遍的に採用されていません。使用されているシステムは多岐にわたり、その多くは1つの製品に密接に結びついています。初期の標準化の取り組みにより、Gremlin、SPARQL、Cypherなどのマルチベンダークエリ言語が生まれました。2019年9月、新しい標準グラフクエリ言語（ISO/IEC 39075 情報技術 - データベース言語 - GQL）を作成するプロジェクトの提案が、ISO/IEC合同技術委員会1（ISO/IEC JTC 1）のメンバーによって承認されました[ 5 ]。GQLは、SQLのような宣言型データベースクエリ言語となることを意図しています。クエリ言語インターフェースに加えて、一部のグラフデータベースはアプリケーションプログラミングインターフェース（API）を介してアクセスされます。
グラフデータベースはグラフ計算エンジンとは異なります。グラフデータベースは、リレーショナルオンライントランザクション処理（OLTP）データベースを変換した技術です。一方、グラフ計算エンジンは、一括分析のためのオンライン分析処理（OLAP）で使用されます。 [ 6 ]グラフデータベースは、2000年代に、大手テクノロジー企業が独自のグラフデータベースを使用して成功を収めたこと[ 7 ]と、オープンソースのグラフデータベースの登場により、大きな注目を集めました。
ある研究では、RDBMSはグラフクエリの実行において既存のグラフ分析エンジンと「同等」の性能であると結論付けた。[ 8 ]
1960年代半ば、IBMのIMSなどのナビゲーションデータベースは階層モデルでツリーのような構造をサポートしていましたが、仮想レコードを使用することで厳密なツリー構造を回避することができました。[ 9 ] [ 10 ]
グラフ構造は、1960年代後半からネットワークモデルデータベースで表現できるようになった。 1959年にCOBOLを定義したCODASYLは、1969年にネットワークデータベース言語を定義した。
ラベル付きグラフは、1980年代半ばから論理データモデルなどのグラフデータベースで表現されてきた。[ 11 ] [ 12 ]
商用オブジェクトデータベース（ODBMS）は1990年代初頭に登場しました。2000年には、オブジェクトデータ管理グループがODMG'93出版物でオブジェクトと関係（グラフ）構造を定義するための標準言語を発表しました。[ 13 ]
2000年代半ばから後半にかけて、Neo4jやOracle Spatial and Graphといった、ACID特性を保証する商用グラフデータベースが登場した。
2010年代には、水平方向に拡張可能な商用ACIDグラフデータベースが利用可能になった。さらに、SAP HANAはインメモリとカラム型テクノロジーをグラフデータベースにもたらした。[ 14 ]また、2010年代には、OrientDB、ArangoDB、MarkLogic （バージョン7.0以降）など、グラフモデル（およびリレーショナルデータベースやドキュメント指向データベースなどの他のモデル）をサポートするマルチモデルデータベースが利用可能になった。この間、さまざまなタイプのグラフデータベースは、ソーシャルメディア企業の出現により、ソーシャルネットワーク分析で特に人気が高まった。また、この10年間には、 Amazon NeptuneやNeo4j AuraDBなどのクラウドベースのグラフデータベースが利用可能になった。
グラフ理論に基づくと、グラフデータベースは、概念的に理解されている方法を反映する形でデータを保存します。ノードはエンティティを表し、エッジはエンティティ間の関係を表します。[ 15 ]
それは、ノードやエッジなどのオブジェクトの集合から構成される。
ラベル付きプロパティグラフモデルは、ノード、関係、プロパティ、およびラベルのセットによって表現されます。データのノードとその関係の両方に名前が付けられ、キーと値のペアで表されるプロパティを格納できます。ノードはグループ化するためにラベル付けできます。関係を表すエッジには、常に開始ノードと終了ノードがあり、方向付けられているという 2 つの特性があります。[ 16 ]これにより、グラフは有向グラフになります。関係にもプロパティを持たせることができます。これは、ノードの関係に追加のメタデータと意味を提供するのに役立ちます。[ 17 ]関係を直接格納することで、定数時間での走査が可能になります。[ 18 ]
RDFグラフモデルでは、情報の追加はそれぞれ別のノードで表されます。たとえば、グラフ内で別のノードとして表される人物に名前プロパティを追加する必要があるシナリオを考えてみましょう。ラベル付きプロパティグラフモデルでは、これは人物のノードに名前プロパティを追加することで行われます。しかし、RDFでは、hasName元の人物ノードに接続する別のノードを追加する必要があります。具体的には、RDFグラフモデルはノードとアークで構成されます。RDFグラフ表記またはステートメントは、主語のノード、目的語のノード、述語のアークで表されます。ノードは空白のままにすることも、リテラルにすることも、URIで識別することもできます。アークもURIで識別できます。ノードのリテラルには、プレーン（型なし）と型付きの2種類があります。プレーンリテラルは、語彙形式とオプションで言語タグを持ちます。型付きリテラルは、特定のデータ型を識別するURIを持つ文字列で構成されます。データにURIがない場合、空白ノードを使用してデータの状態を正確に示すことができます。[ 19 ]
グラフデータベースは、グラフのようなクエリを実行するための強力なツールです。例えば、グラフ内の2つのノード間の最短経路を計算する場合などが挙げられます。その他にも、グラフデータベース上で自然な方法でグラフのようなクエリを実行できます（例えば、グラフの直径の計算やコミュニティの検出など）。
グラフは柔軟性があり、アプリケーションの機能を損なうことなく、ユーザーが既存のグラフに新しいデータを挿入できます。データベースの設計者は、データベースの将来の使用例の詳細を綿密に計画する必要はありません。[ 20 ]
グラフデータベースの基盤となるストレージメカニズムは様々です。リレーショナルエンジンに依存し、グラフデータをテーブルに「格納」するもの（ただし、テーブルは論理要素であるため、このアプローチではグラフデータベース、グラフデータベース管理システム、およびデータが実際に格納される物理デバイスの間に別のレベルの抽象化が課せられます）。キーバリューストアまたはドキュメント指向データベースをストレージに使用し、本質的にNoSQL構造となるものもあります。ノードは他のドキュメントストアと同様に表現されますが、2つの異なるノードをリンクするエッジは、ドキュメント内に特別な属性（_from属性と_to属性）を持ちます。
データ検索のパフォーマンスは、ある特定のノードから別のノードへのアクセス速度に依存します。インデックスフリー隣接性では、ノードが直接物理RAMアドレスを持ち、物理的に他の隣接ノードを指すように強制されるため、高速な取得が可能になります。インデックスフリー隣接性を持つネイティブ グラフ システムでは、ノード間のリンクを見つけるために他のタイプのデータ構造をたどる必要はありません。グラフ内の直接関連するノードは、いずれかのノードが取得されるとキャッシュに格納されるため、ユーザーが初めてノードを取得するときよりもデータ検索がさらに高速になります。ただし、このような利点にはコストがかかります。インデックスフリー隣接性では、グラフ走査を使用しないクエリの効率が犠牲になります。ネイティブ グラフ データベースは、格納されたデータに対するCRUD操作を処理するためにインデックスフリー隣接性を使用します。
データの種類によってグラフのカテゴリが複数認識されています。ガートナーは、グラフの5つの大まかなカテゴリを提案しています。[ 21 ]
エドガー・F・コッドが1970年にリレーショナルモデルに関する論文を発表して以来[ 22 ] 、リレーショナルデータベースは大規模データストレージシステムの事実上の業界標準となっています。リレーショナルモデルでは、厳密なスキーマとデータ正規化が必要であり、これによりデータが多数のテーブルに分割され、データベース内の重複データがすべて削除されます。データの正規化は、データの一貫性を維持し、 ACIDトランザクションをサポートするために行われます。しかし、これにより、リレーションシップをクエリする方法に制限が生じます。
関係モデルの設計動機の一つは、行ごとの高速アクセスを実現することでした。[ 22 ]問題は、格納されたデータ間に複雑な関係を構築する必要がある場合に発生します。関係は関係モデルで分析できますが、複数のテーブルにわたる多くの異なる属性に対して多数の結合操作を実行する複雑なクエリが必要です。関係モデルを扱う場合、関係を取得する際に外部キー制約も考慮する必要があり、追加のオーバーヘッドが発生します。
関係データベースと比較して、グラフデータベースは連想データセットに対して高速であることが多く[ 23 ] 、オブジェクト指向アプリケーションの構造により直接的に対応します。結合操作は通常必要としないため、大規模なデータセットに対してもより自然に拡張できます[ 24 ] 。結合操作はコストがかかる場合が多いからです。厳密なスキーマへの依存度が低いため、進化するスキーマを持つアドホックなデータや変化するデータの管理に適していると宣伝されています。
逆に、リレーショナルデータベース管理システムは、多数のデータ要素に対して同じ操作を実行する際に一般的に高速であり、データの自然な構造での操作を可能にします。グラフデータベースの利点と、リレーショナルデータベースに対する最近の人気にもかかわらず[ 25 ]、グラフモデル自体が既存のリレーショナルデータベースを置き換える唯一の理由となるべきではありません。グラフデータベースは、パフォーマンスが桁違いに向上し、レイテンシが低減するという証拠がある場合に有効になる可能性があります。[ 26 ]
リレーショナルモデルは、データ内の情報を使用してデータをまとめます。たとえば、電話番号に市外局番「311」が含まれるすべての「ユーザー」を検索することができます。これは、選択したデータストアまたはテーブルを検索し、選択した電話番号フィールドで文字列「311」を探すことによって行われます。これは、大きなテーブルでは時間のかかる処理になる可能性があるため、リレーショナルデータベースはインデックスを提供します。インデックスを使用すると、選択したデータとレコードの一意のキー（または主キー）のみを含む小さなサブテーブルにデータを格納できます。電話番号にインデックスが付けられている場合、同じ検索が小さなインデックステーブルで実行され、一致するレコードのキーが収集され、次に、それらのキーを持つレコードをメインデータテーブルで検索します。通常、テーブルは、キーによる検索が非常に高速になるように格納されます。[ 27 ]
リレーショナルデータベースには、レコード間の固定的な関係という概念は本来userpk含まれていません。代わりに、関連データは、あるレコードの一意のキーを別のレコードのデータに格納することによって相互にリンクされます。たとえば、ユーザーの電子メールアドレスを含むテーブルには、関連付けられているユーザーレコードの主キーを含むデータ項目があるかもしれません。ユーザーとその電子メールアドレスをリンクするために、システムはまず選択されたユーザーレコードの主キーを検索し、userpk電子メールテーブルの列（または、より可能性が高いのはそれらのインデックス）でそれらのキーを検索し、電子メールデータを抽出し、次にユーザーレコードと電子メールレコードをリンクして、選択されたすべてのデータを含む複合レコードを作成します。この操作は結合と呼ばれ、計算コストが高くなる可能性があります。クエリの複雑さ、結合の数、およびさまざまなキーのインデックス付けによっては、システムは複数のテーブルとインデックスを検索し、それらをすべてソートして一致させる必要がある場合があります。[ 27 ]
対照的に、グラフデータベースはレコード間の関係を直接格納します。電子メールアドレスは、userpk列内のユーザーキーを検索して見つけるのではなく、ユーザーレコードには電子メールアドレスレコードを直接参照するポインタが含まれています。つまり、ユーザーを選択すると、ポインタを直接たどって電子メールレコードにアクセスできるため、一致するレコードを見つけるために電子メールテーブルを検索する必要はありません。これにより、コストのかかる結合操作を排除できます。たとえば、市外局番「311」のユーザーのすべての電子メールアドレスを検索する場合、エンジンはまず従来の検索を実行して「311」のユーザーを見つけ、次にそれらのレコードで見つかったリンクをたどって電子メールアドレスを取得します。リレーショナルデータベースは、まず「311」のすべてのユーザーを見つけ、主キーのリストを抽出し、電子メールテーブルでそれらの主キーを持つレコードを再度検索し、一致するレコードをリンクします。このような一般的な操作の場合、グラフデータベースは理論的に高速になります。[ 27 ]
グラフアプローチの真価は、複数階層にわたる検索を実行する際に明らかになります。たとえば、「311」の市外局番を持つ「加入者」（ユーザーと他のユーザーをリンクするテーブル）を持つユーザーを検索する場合を考えてみましょう。この場合、リレーショナルデータベースでは、まず「311」の市外局番を持つすべてのユーザーを検索し、次に加入者テーブルでそれらのユーザーを検索し、最後にユーザーテーブルを検索して一致するユーザーを取得する必要があります。これに対し、グラフデータベースでは、「311」のすべてのユーザーを検索し、次に加入者関係を通じてバックリンクをたどって加入者ユーザーを見つけます。これにより、複数の検索、ルックアップ、および出力の構築に必要な複数のレコードからの一時データをすべて保持するためのメモリ使用量を削減できます。ビッグO記法で表すと、このクエリは次のようになります。時間、つまりデータサイズの対数に比例する。対照的に、関係バージョンでは複数になる。検索に加えてすべてのデータレコードを結合するのに必要な時間。[ 27 ]
グラフ検索の相対的な利点は、クエリの複雑さが増すにつれて大きくなります。たとえば、「『風と共に去りぬ』で主役を演じた俳優が出演した映画に出演した俳優が出演した潜水艦の映画」を知りたいとします。この場合、まずシステムは『風と共に去りぬ』に出演した俳優を見つけ、彼らが出演したすべての映画を見つけ、それらの映画の中で『風と共に去りぬ』の主役ではないすべての俳優を見つけ、次に彼らが出演したすべての映画を見つけ、最後にそのリストを「潜水艦」という説明を含むものに絞り込む必要があります。リレーショナルデータベースでは、これには映画テーブルと俳優テーブルを個別に複数回検索し、潜水艦映画をもう一度検索し、それらの映画に出演したすべての俳優を見つけ、収集した（大量の）結果を比較する必要があります。これに対し、グラフデータベースでは、『風と共に去りぬ』からクラーク・ゲーブルまでたどり、彼が出演した映画へのリンクを集め、それらの映画から他の俳優へのリンクを集め、それらの俳優から映画のリストまでリンクをたどります。結果として得られた映画のリストを「潜水艦」で検索することができます。これらすべてを1回の検索で行うことができます。[ 28 ]
プロパティは、この構造に別の抽象化レイヤーを追加し、多くの一般的なクエリも改善します。プロパティは基本的に、任意のレコード、場合によってはエッジにも適用できるラベルです。たとえば、クラーク・ゲーブルに「俳優」というラベルを付けると、システムは監督やカメラマンではなく、俳優であるすべてのレコードをすばやく見つけることができます。エッジにラベルを付けることが許可されている場合、映画「風と共に去りぬ」とクラーク・ゲーブルの関係に「主役」というラベルを付けることができ、映画「風と共に去りぬ」で「主役」「俳優」である人物を検索すると、データベースはヴィヴィアン・リー、オリヴィア・デ・ハヴィランド、クラーク・ゲーブルを返します。同等の SQL クエリでは、人物と映画をリンクするテーブルに追加されたデータに依存する必要があり、クエリ構文がさらに複雑になります。このようなラベルは、特定の状況下では検索パフォーマンスを向上させる可能性がありますが、一般的にはエンドユーザーに追加の意味データを提供する方がより有用です。[ 28 ]
リレーショナルデータベースは、データ間の関係が1レベルまたは2レベルしかないフラットなデータレイアウトに非常に適しています。たとえば、会計データベースでは、特定の顧客のすべての請求書のすべての明細項目を検索する必要がある場合があり、これは3つの結合クエリになります。グラフデータベースは、より多くのリンクを含むデータセットを対象としています。特に、 「友達」の関係が実質的に無制限であるソーシャルネットワーキングシステムに適しています。これらの特性により、グラフデータベースは、オンラインシステムやビッグデータ環境でますます一般的になっているタイプの検索に自然に適しています。このため、グラフデータベースは、Facebook、Google、Twitterなどの大規模なオンラインシステムや、レコード間に深いリンクを持つ同様のシステムで非常に人気が高まっています。
さらに分かりやすく説明するために、2 つのテーブルを持つリレーショナル モデルを考えてみましょう。1 つのテーブル (と列peopleを持つ) と、と を持ち、 はテーブルからの外部キーであるテーブルです。この場合、ジャックのすべての友人を検索すると、次の SQL クエリになります。person_idperson_namefriendfriend_idperson_idpeople
SELECT p2.person_name FROM people p1 JOIN friend ON ( p1.person_id = friend.person_id ) JOIN people p2 ON ( p2.person_id = friend.friend_id ) WHERE p1.person_name = ' Jack ' ;同じクエリは次のように翻訳できます --
MATCH ( p1 : person { name : 'Jack' }) -[ : FRIEND_WITH ]- ( p2 : person ) RETURN p2 . nameg . V (). hasLabel ( "person" ). has ( "name" , "Jack" ). out ( "friendsWith" ). hasLabel ( "person" ). values ( "name" )プレフィックスfoaf : <http://xmlns.com/foaf/0.1/>SELECT ?name WHERE { ?s a foaf : Person . ?s foaf : name "Jack" . ?s foaf : knows ?o . ?o foaf : name ?name . }プレフィックスfoaf : <http://xmlns.com/foaf/0.1/>SELECT ?name WHERE { ?s foaf : name "Jack" ; foaf : knows ?o . ?o foaf : name ?name . }SELECT people.name FROM ( SPARQL PREFIX foaf : <http://xmlns.com/foaf/0.1/> SELECT ?name WHERE { ?s foaf : name "Jack" ; foaf : knows ?o . ? o foaf : name ? name . } ) AS people ;上記の例は、基本的なリレーションシップクエリの簡単な例です。これらは、データ総量が増えるにつれてクエリの複雑さが増すという、リレーショナルモデルのクエリの複雑さの概念を簡潔に示しています。これに対し、グラフデータベースのクエリは、リレーションシップグラフを容易にソートして結果を表示できます。
また、グラフデータベースの単純で簡潔な宣言型クエリは、リレーショナルデータベースと比較して必ずしも優れたパフォーマンスを提供するとは限らないことを示す結果もあります。グラフデータベースはデータの直感的な表現を提供しますが、集合演算が必要な場合はリレーショナルデータベースの方が優れた結果を提供します。[ 18 ]
以下は、注目すべきグラフデータベースの一覧です。
ネットワークモデルは [...] 適切な抽象化レベルを欠いており、データベースモデルと実際の実装を分離することが困難である。
ネットワークモデルは [...] 適切な抽象化レベルを欠いており、データベースモデルと実際の実装を分離することが困難である。