グラフデータベースとは何ですか?接続されたデータを保存するためのより良い方法

キーバリュー、ドキュメント指向、列ファミリー、グラフ、リレーショナル...今日、私たちはデータの種類と同じ数の種類のデータベースを持っているようです。これによりデータベースの選択が難しくなる可能性がありますが、適切なデータベースの選択が 容易になります。もちろん、それはあなたの宿題をすることを必要とします。あなたはあなたのデータベースを知る必要があります。 

世の中で最も理解されていないタイプのデータベースの1つは、グラフデータベースです。高度に相互接続されたデータを処理するために設計されたグラフデータベースは、リレーショナルデータベースよりも「リレーショナル」と表現される場合があります。グラフデータベースは、膨大な情報のウェブで複雑な関係をキャプチャすることが目標である場合に役立ちます。 

ここでは、グラフデータベースとは何か、他のデータベースとは異なる理由、および解決するために構築されたデータの問題の種類について詳しく説明します。

グラフデータベースとリレーショナルデータベース

従来のリレーショナルデータベースまたはSQLデータベースでは、データはテーブルに編成されています。各テーブルは、固定数の列を持つ特定の形式でデータを記録し、各列には独自のデータ型(整数、時刻/日付、自由形式のテキストなど)があります。

このモデルは、主に1つのテーブルのデータを処理する場合に最適に機能します。また、複数のテーブルに保存されているデータを集約している場合も、それほど悪くはありません。しかし、その動作にはいくつかの注目すべき制限があります。

アルバム、バンド、レーベル、パフォーマーを含む音楽データベースについて考えてみましょう。これらのレーベル(4つの異なるテーブル)でリリースされたそのバンドによってこのアルバムで取り上げられたすべてのパフォーマーを報告する場合は、それらの関係を明示的に説明する必要があります。リレーショナルデータベースでは、新しいデータ列(1対1または1対多の関係の場合)または新しいテーブル(多対多の関係の場合)を使用してこれを実現します。

適度な数の関係を管理している限り、これは実用的です。数百万または数十億の関係(たとえば、友達の友達の友達)を扱っている場合、これらのクエリは適切に拡張できません。

つまり、データ自体ではなくデータ間の 関係が主な関心事である場合は、別の種類のデータベース(グラフデータベース)が適切です。

グラフデータベースの機能

「グラフ」という用語は、数学での単語の使用に由来します。そこでは、ノード(または頂点)のコレクションを記述するために使用されます。各ノードには情報(プロパティ)が含まれ、ノード間の関係(またはエッジ)にラベルが付けられています。

ソーシャルネットワークはグラフの良い例です。ネットワーク内の人はノードになり、各人の属性(名前、年齢など)はプロパティになり、人を結ぶ線(「友達」、「母」、「スーパーバイザー」)は、それらの関係を示します。 

従来のデータベースでは、関係に関するクエリの処理に長い時間がかかる場合があります。これは、関係が外部キーで実装され、テーブルを結合することによって照会されるためです。 SQL DBAが言うように、結合の実行にはコストがかかります。特に、多数のオブジェクトを並べ替える必要がある場合、またはさらに悪いことに、複数のテーブルを結合して一種の間接(「友達の友達」など)クエリを実行する必要がある場合はそうです。そのグラフデータベースは優れています。 

グラフデータベースは、データとともに関係を保存することによって機能し ます。関連するノードはデータベース内で物理的にリンクされているため、これらの関係へのアクセスは、データ自体へのアクセスと同じくらい迅速です。言い換えると、リレーショナルデータベースが行う必要があるように関係を計算する代わりに、グラフデータベースは単にストレージから関係を読み取ります。クエリを満たすことは、グラフを歩く、つまり「トラバース」するという単純な問題です。  

グラフデータベースは、オブジェクト間の関係をネイティブな方法で格納するだけでなく、関係に関するクエリをすばやく簡単に行うだけでなく、さまざまな種類のオブジェクトやさまざまな種類の関係をグラフに含めることができます。他のNoSQLデータベースと同様に、グラフデータベースにはスキーマがありません。したがって、パフォーマンスと柔軟性の観点から、グラフデータベースは、リレーショナルデータベースやテーブル指向データベースよりもドキュメントデータベースやKey-Valueストアに近くなります。

グラフデータベースのユースケース

グラフデータベースは、作業しているデータが高度に接続されている場合に最適に機能し、通常は多対多の関係を介して、他のデータをリンクまたは参照する方法で表す必要があります

繰り返しますが、ソーシャルネットワークは便利な例です。グラフデータベースは、アクティビティフィードなど、ソーシャルネットワークで見られるデータビューを構築および表示するために必要な作業量を削減します。また、ネットワーク内の他の友人との距離が近いために特定の人物を知っているかどうかを判断します。

グラフデータベースの別のアプリケーションは、他のデータ表現を介して引き出すのが難しいグラフデータの接続パターンを見つけることです。不正検出システムは、グラフデータベースを使用して、他の方法では気付かなかった可能性のあるエンティティ間の関係を明らかにします。 

同様に、グラフデータベースは、エンティティ間の関係または相互依存性を管理するアプリケーションに自然に適合します。多くの場合、レコメンデーションエンジン、コンテンツおよび資産管理システム、IDおよびアクセス管理システム、規制コンプライアンスおよびリスク管理ソリューションの背後にあるグラフデータベースがあります。 

グラフデータベースクエリ

グラフデータベースは、他のNoSQLデータベースと同様に、通常、SQLの代わりに独自のカスタムクエリ手法を使用します。

一般的に使用されるグラフクエリ言語の1つは、Neo4jグラフデータベース用に開発されたCypherです。2015年後半以降、Cypherは独立したオープンソースプロジェクトとして開発され、他の多くのベンダーが自社製品のクエリシステムとして採用しています(SAP HANAなど)。

スコットの友達であるすべての人の検索結果を返すCypherクエリの例を次に示します。

MATCH(a:Person {name: 'Scott'})-[:FRIENDOF]->(b)RETURN b 

矢印記号(->)は、グラフ内の有向関係を表すためにCypherクエリで使用されます。

もう1つの一般的なグラフクエリ言語であるGremlinは、ApacheTinkerPopグラフコンピューティングフレームワーク用に考案されました。Gremlin構文は、一部の言語のORMデータベースアクセスライブラリで使用されている構文と似ています。

グレムリンでの「スコットの友達」クエリの例を次に示します。

gV()。has( "name"、 "Scott")。out( "friendof") 

多くのグラフデータベースは、組み込みまたはサードパーティのライブラリを介してグレムリンをサポートしています。

さらに別のクエリ言語はSPARQLです。もともとは、メタデータのためにResource Description Framework(RDF)形式で格納されたデータを照会するためにW3Cによって開発されました。言い換えれば、SPARQLはグラフデータベース検索用に考案されたものではありませんが、それらに使用することができます。全体として、CypherとGremlinはより広く採用されています。

SPARQLクエリは、いくつかのつまりSQLを彷彿とさせる要素、持っている SELECTWHERE句を、しかし、構文の残りの部分は根本的に異なるです。SPARQLをSQLに関連しているとはまったく考えないでください。さらに言えば、他のグラフクエリ言語に関連しているとは考えないでください。

人気のグラフデータベース

グラフデータベースは比較的ニッチなユースケースを提供するため、リレーショナルデータベースほど多くはありません。プラス面として、これにより、傑出した製品を特定して議論しやすくなります。

Neo4j

Neo4jは、簡単に最も成熟し(11年以上)、一般的な使用のためのグラフデータベースの中で最もよく知られています。以前のグラフデータベース製品とは異なり、SQLバックエンドを使用しません。Neo4jは、数十万以上の関係を返すクエリのように、大きなグラフ構造をサポートするように徹底的に設計されたネイティブグラフデータベースです。

Neo4jには、無料のオープンソースエディションと有料のエンタープライズエディションの両方があり、後者にはデータセットのサイズに制限がありません(他の機能の中でも)。サンドボックスを使用して、Neo4jをオンラインで試すこともできます。サンドボックスには、練習用のサンプルデータセットがいくつか含まれています。

詳細については、Neo4jのレビューを参照してください。

Microsoft Azure Cosmos DB

Azure CosmosDBクラウドデータベースは野心的なプロジェクトです。これは、一貫性のあるAPIセットを備えた単一の統合サービスを通じて、複数の種類のデータベース(従来のテーブル、ドキュメント指向、列ファミリー、グラフ)をエミュレートすることを目的としています。

そのために、グラフデータベースは、Cosmos DBが動作できるさまざまなモードの1つにすぎません。グラフデータベースは、グラフタイプのクエリにGremlinクエリ言語とAPIを使用し、別のインターフェイスとしてApacheTinkerPop用に作成されたGremlinコンソールをサポートします。

Cosmos DBのもう1つの大きなセールスポイントは、インデックス作成、スケーリング、およびジオレプリケーションがAzureクラウドで自動的に処理されることであり、ユーザー側でノブをいじることはありません。Microsoftのオールインワンアーキテクチャがパフォーマンスの観点からネイティブグラフデータベースまでどのように測定するかはまだ明らかではありませんが、CosmosDBは確かに柔軟性と拡張性の便利な組み合わせを提供します。

詳細については、Azure CosmosDBのレビューを参照してください。

JanusGraph

JanusGraphはTitanDBプロジェクトから分岐し、現在LinuxFoundationの管理下にあります。サポートされているバックエンド(Apache Cassandra、Apache HBase、Google Cloud Bigtable、Oracle BerkeleyDB)のいずれかを使用してグラフデータを保存し、Gremlinクエリ言語(およびApache TinkerPopスタックの他の要素)をサポートします。 Apache Solr、Apache Lucene、またはElasticsearchプロジェクトを介して全文検索を組み込みます。

JanusGraphプロジェクトのサポーターの1つであるIBMは、Compose forJanusGraphと呼ばれるIBMCloud上のJanusGraphのホストバージョンを提供しています。Azure Cosmos DBと同様に、Compose for JanusGraphは、リソース使用量に基づいた価格設定で、自動スケーリングと高可用性を提供します。