はじめに
グラフDBまわりをざっくり押さえるための覚え書き。
Neo4J
「グラフデータベース ―Neo4jによるグラフデータモデルとグラフデータベース入門」は、日本語でグラフDBについて書かれた書籍（特定のデータベースに関する書籍として）だろうか。2015年日本語版出版。
付録として、Neo4J以外のグラフDBについて一通り触れられている。Titanについては紹介だけでなく、インストールと使用方法についての記載がある。Apache Cassandraとの組み合わせのセットアップが解説されている。
Cypher (vs Gremlin)
質問。
Cypher (Neo4j のクエリ言語) と Gremlin (汎用グラフ クエリ/トラバーサル言語) の 2 つのオプションがあることがわかりました。
Gremlinを使用して実行でき、Cypherでは実行できないクエリまたは操作はありますか? またはその逆？
回答。
Cypher は非チューリングの完全な宣言型言語です。Gremlin は、Neo4j Java API の派手なラッパーであり、必須です。明らかに、cypher ではできないことを gremlin で行うことができます。
Gremlin では、命令型と宣言型の両方のスタイルを使用できます。
Apache Spark 3 には Cypher が含まれます。これは、それに関する彼らの見解について多くを語っています。
一般的なクエリには、Cypher で十分であり、おそらくより高速です。Cypher に対する Gremlin の利点は、高レベルのトラバースに入るときです。Gremlin では、正確なトラバーサル パターン (または独自のアルゴリズム) をより適切に定義できますが、Cypher では、エンジンが最適なトラバーサル ソリューション自体を見つけようとします。
私はそのシンプルさから個人的に Cypher を使用しており、現在まで、Gremlin を使用しなければならない状況はありませんでした (Gremlin の graphML インポート/エクスポート機能を使用する場合を除く)。
いつでも Cypher を非常に速く (数日で) 習得してから、(長期的には) 一般的な Gremlin に進むことができます。
Titan
Titan has been decommisioned after the takeover by Datastax. It will be removed from the DB-Engines ranking. A fork has been open-sourced as JanusGraph.
JanusDB
グラフコンピューティングフレームワークApache TinkerPopを使っているのは、DSE Graph同様。
バックエンドデータベースとしてApache Cassandra, Apache HBase,Berkeley DBなどが選べる。
Gremlin
以下で利用されている。
- JanusGraph
- DataStax Enterprise (DSE) Graph
- Neo4j
- Amazon Neptune
- Azure Cosmos DB
DataStax Enterprise (DSE) Graph
Apache Tinkerpop、Gremlin、といった普遍性の高いテクノロジーを活用。バックエンドデータベースを個別にインストール、セットアップする必要なく、Cassandraをバックエンドとして、グラフDBをすぐに使うことができる。
DSE Studioでは、グラフの可視化の機能も提供されている。
ドキュメント
トレーニング
JavaScriptでのグラフの実装
JSONでグラフデータを表現し、JavaScriptでグラフ操作を実装するというアプローチ。
その、Couchbaseでの応用。UDF(ユーザー定義関数)として、JavaScriptでグラフ操作を実装する。
上記記事からの概略。
- グラフは非線形のデータ構造。
- 一つのグラフ
Gには、頂点VのセットとエッジEのセットが含まれる。
グラフは基本的に2つの大きなカテゴリに分けられる。
- 有向グラフ（ダイグラフ）：エッジに方向がある場所。
- 無向グラフ：エッジが方向を表さない場合
グラフを表すにはさまざまな方法がある。
- 隣接行列
- 隣接リスト
接続行列など、他にもいくつかの方法があるが、これら2つが最も一般的に使用される。
グラフ走査
上記記事では、以下の最も一般的と言われるグラフ走査アルゴリズムを実装。
グラフの幅優先探索
グラフの深さ優先探索
グラフDBのユースケース（試論）
ツリー構造には、さまざまな実装があり、RDBを用いた実現も容易に考えうる。あるいは、JSONデータでの表現も、その方法の一つ。
ネットワーク構造のデータ表現が必要なケース、というのがグラフDBのユースケースに関する要約として考えられる。
例えば、映画に関するデータベースを考えてみる（DataStaxトレーニングで用いられている例）。監督、脚本家、など映画関係者、制作年、ジャンルなど作品の属性（さらには評価者の情報を加えても良い）、これらの要素で必要な情報の検索、集計を行う場合、つまりネットワーク構造を持つデータを、テーブルに格納されたデータとして表現されている場合、本質的に全件検索（全件にインデックスを付与する、のはその別の表現）になる。これに対して、データをグラフとして構成しておくことによって、データに対する操作が、直感的かつ高速になる。
グラフDBのユースケースの他の例としては、製造業における、部品と製品（そしてそれらの製造に関わる工場などの情報）の関係、がある。製造業においては、部品は製品を構成する要素でもあるが、部品自体が製品でもありうる。そして、特定の、部品（あるいはそのロット番号）、製品、製造日時、場所（工場）、あるいはさらに出荷先、といった情報のいずれかの情報から、関連するすべての情報を導くという要件が考えられる。
グラフDBの脱神秘化(demystification)
上のイタリックで表示した論点を逆に考えると、グラフDBは、ネットワークとして定義されたデータに対して、自動的にインデックスを作成する機能（であり、グラフクエリを、作成済みインデックスを効果的に活用するSQLに変換する機能）、とみることができる。
実際、グラフフロントエンドとバックエンドデータベースとの関係はそのようなものである（バックエンドデータベースは、広義のテーブル型であり、グラフあるいはネットワークというコンセプトのために設計された特殊なデータベースという訳ではない）。
要するに、RDBの全件検索（ないしインデックス設計）で事足りていれば、特にグラフDBのことなど考えなくとも構わないといってしまうことができるかもしれない。逆に言えば、全件検索によってしか実現しない機能要件が発生し、非機能要件を満たさない問題に遭遇した場合、つまり自身で行うデータモデルとインデックス設計では、問題が解決しない場合、グラフ理論とその実現された実装を押さえておくことによって、解決（提案）につながる機会がある、という考え方ができる。