プロパティグラフ（Neo4j / AuraDB他）の概要を知る：グラフデータベース

-

グラフデータベース ― Neo4jによるグラフデータモデルとグラフデータベース入門

  • Ian Robinson (著), Jim Webber (著), Emil Eifrem (著), 佐藤 直生 (監訳), 木下 哲也 (翻訳)
  • 発売日：2015/3/25


今でも特別な要件が無い限りデータベース選択の第一候補はRDB（関係データベース）になることが多いと思います。

しかし、多様なプログラミング言語があるように、多様なデータベースがあり、オープンソースあるいはクラウド時代になって、より幅広く利用されるようになりました。（よく NoSQL とひとくくりにされてしまいますけど。）

今回はそのなかでもグラフデータベースの本を取り上げます。

この本のタイトルは『グラフデータベース』となっていますが、グラフデータベースに関する一般論というよりは、サブタイトルの通り『Neo4j によるグラフデータモデルとグラフデータベース入門』といった内容です。

Neo4j は意外に歴史のあるオープンソースのデータベースですが、最近特によく目にするようになりました。（最近では Neo4j のフルマネージドなクラウドサービスである AuraDB も利用できるようになってます。）


さて、グラフデータベースのモデルにもいろいろありますが、Neo4j のデータモデルはプロパティグラフです。

プロパティグラフとは、本書では以下の特徴を備えたものと説明されています。
  • プロパティグラフはノード、関係、プロパティで構成される。
  • ノードはプロパティを持つ。ノードを、任意のキー／値ペアの形式でプロパティを格納するドキュメントと考える。キーは文字列であり、値は任意のデータ型になる。
  • 関係は、ノードをつないで構造化する。関係には必ず方向、ラベル、開始ノード、終了ノードがあり、ダングリング（宙ぶらりんの）関係はない。関係の方向とラベルは、ノードの構造を意味的にはっきりさせる。
  • ノードと同様に、関係もプロパティを持つことができる。関係にプロパティを追加できる機能は、グラフアルゴリズムへの追加メタデータの提供、関係への意味（質や重みなど）の追加、実行時のクエリの制約に特に役立つ。

このように書くと少々難しそうな雰囲気ですが、グラフを図的に考えると（原理そのものは）非常に直感的で分かりやすいものです。

実際、本書の冒頭に以下のように書かれています。
  • 本書の大部分ではグラフデータモデルについて話をしますが、グラフ理論に関する書籍ではありません。グラフデータベースを活用するために、理論はあまり必要ありません。実質的にグラフが何かを理解していれば良いのです。

ちなみにプロパティグラフを扱うデータベースとしては Amazon Neptune 他もあります。

このような状況は、RDB では表現し難いような領域にもアプリ化が進んでいるように思えます。

この本は比較的薄くて読みやすく、グラフデータベース（主にNeo4j / Aura）が得意とするユースケースを始め、プロパティグラフ関連技術の全体像を把握するには良い本だと思います。

＜本の内容＞

【目次】
  • 1章　はじめに
    • 1.1　グラフとは何か
    • 1.2　グラフ領域の概要
    • 1.3　グラフデータベースの能力
    • 1.4　まとめ
  • 2章　つながりのあるデータを格納するための選択肢
    • 2.1　リレーショナルデータベースには関係が欠如している
    • 2.2　NoSQLデータベースにも関係が欠如している
    • 2.3　グラフデータベースは関係を包含する
    • 2.4　まとめ
  • 3章　グラフでのデータモデリング
    • 3.1　モデルと目的
    • 3.2　プロパティグラフモデル
    • 3.3　グラフのクエリ：Cypher入門
    • 3.4　リレーショナルモデリングとグラフモデリングの比較
    • 3.5　クロスドメインモデル
    • 3.6　一般的なモデリングの落とし穴
    • 3.7　アンチパターンの回避
    • 3.8　まとめ
  • 4章　グラフデータベースアプリケーションの構築
    • 4.1　データモデリング
    • 4.2　アプリケーションアーキテクチャ
    • 4.3　テスト
    • 4.4　キャパシティプランニング
    • 4.5　まとめ
  • 5章　実世界のグラフ
    • 5.1　グラフデータベースを選ぶ理由
    • 5.2　一般的なユースケース
    • 5.3　実世界の例
    • 5.4　まとめ
  • 6章　グラフデータベースの内部
    • 6.1　ネイティブグラフ処理
    • 6.2　ネイティブグラフストレージ
    • 6.3　プログラミングAPI
    • 6.4　非機能的な特徴
    • 6.5　まとめ
  • 7章　グラフ理論を使った予測分析
    • 7.1　深さ優先探索と幅優先探索
    • 7.2　ダイクストラ法での経路探索
    • 7.3　A*アルゴリズム
    • 7.4　グラフ理論と予測モデリング
    • 7.5　ローカルブリッジ
    • 7.6　まとめ
  • 付録A　NoSQLの概要
    • A.1　NoSQLの台頭
    • A.2　ACIDとBASEの対比
    • A.3　NoSQLの4象限
    • A.4　キーバリューストア
    • A.5　カラムファミリー
    • A.6　集約ストアでのクエリと処理の比較
    • A.7　グラフデータベース
  • 付録B　Neo4j以外のグラフデータベース
    • B.1　商用のグラフデータベース
    • B.2　オープンソースのグラフデータベース
    • B.3　その他のグラフデータベース
    • B.4　Titanのインストールと使用方法
    • B.5　TinkerPop

目次だけ見ると、かなり技術的な詳細に入り込んでいるように見えますが、個々に深い説明があるわけではありません。むしろ、グラフデータベースのモデルから実装や適用事例まで幅広く概観しているため、全体像を把握するには丁度良い感じだと思います。

なお付録Bは日本語版のみ収録されている内容のようです。

＜感想＞

私はセマンティックウェブが流行ったころに RDF / OWL をかじったこともあり、グラフデータベースに興味はありましたが、トリプル以外のグラフ表現にはほぼ興味が無かったため、Neo4j の名前は知っていてもスルーしてました（涙）。

しかし最近グラフデータベースの利用を検討していたところ、Neo4j のことを思い出して一応調べておこうと思って手に取ったのがこの本です。

この本でプロパティグラフを知って最初に思ったことは、RDBを使ったことがある方に是非読んでいただきたいな、ということでした。

まず、プロパティグラフは RDB にとても近いと感じます。
（ノードとプロパティは RDB のレコードそのもの、そして RDB のテーブル間を join 演算で結合するのではなく、レコードにあたるノード間をリレーションで直接リンクする、といった感じです。）

面白いのはリレーションにもプロパティを持てることで、これは RDB で多対多の関係を表す中間テーブルを作るケースをスッキリ表現できるように見えます。（そう簡単ではない場合も多いと思いますが。）

何となく、プロパティグラフは RDB をご存知の方には理解しやすく、さらに RDB で少し痛いところを救ってくれるように見えます。

RDBでモデリングしていると、どうもスッキリ表現できないな、ということがありますが、この本ではリレーショナルデータベースの表現例とプロパティグラフの表現例を比較することで、プロパティグラフだとシンプルに表現できる場合があることを、理由とともに例示しています。
  • 本書には「皮肉にも、リレーショナルデータベースは関係を扱うのが下手なのです」とまで書いてます（笑）。

RDB では表現が難しいものをグラフならシンプルに表現できる、というのはセマンティックウェブ技術を初めて知った時の感動？を思い出して、何だか懐かしかったです（笑）。

この本にはグラフデータベースが得意なユースケースの例示もあって、とても参考になるのですが、この本の内容だけ読むと RDB を使うのが悪のように思えてしまいます。。。

その意味で、この本の少々残念なところを書いておくと、グラフデータベースが不得意なところが殆ど書かれていないところでしょうか。

プロパティグラフと RDB（と他のNoSQL）との対比でプロパティグラフの優位性を示すなら、プロパティグラフが不得意なところも明示して欲しいところです。
（プロパティグラフも銀の弾丸ではないと思うし、RDB が専門好の方が読むと、RDB を批判しているように読める可能性がある気がしました。）

もっとも、この本をグラフデータベースの一般書ではなく、プロパティグラフ製品のチラシのように考えれば、不利な点は書かないものかもしれません（その意味でもサブタイトルをタイトルにしたほうがよいように思えます）。

ところで RDB がここまで普及した理由を考えると、（様々な要因があるとは思いますが）個人的には SQL 標準の存在が大きいと考えています。

Neo4j のクエリ言語は Cypher で SQL標準のようなものではないと思っていましたが、（私は詳しく調べていませんが）案外そうでもないようで、openCypher や ISO / GQL（Graph Query Language）で標準化が進んでいるようです。


私はこの本で初めて Cypher を知りましたが、Cypher は、あると便利な機能がうまく詰め込まれた、とても実用的でうまく設計されたクエリ言語だと思います。

私の場合はプロパティグラフに興味を持ったというより、Cypher に興味を持ったといえるくらいです。

本書でも Cypher の簡単な解説と利用例が書かれていますが、もし興味を持たれたらネット上のマニュアルを読んでみることをお勧めしたいです。

さて、この本でプロパティグラフや Cypher の面白さを知ると、実際にプログラムから使いたくなるところですが、残念ながら各種プログラミング言語を利用した実装までは書かれていませんので、製品サイト（例えば Neo4j）で各種言語用ドライバーを参照する必要があります。

また、本書の内容の問題ではありませんが、個人的に残念なのは、RDB や NoSQL との比較は書かれているのに、RDF / OWL のトリプルとの比較は無く、ほぼスルーされていることです。（流派の違いなんでしょうか。。。）

このあたりについては、いつか本ブログで書いてみたいと思ってます。

長々と書きましたが、この本はプロパティグラフデータベースの利点、使いどころや勘どころをコンパクトに知ることができる良い本だと思います。



関連記事

コメント

コメントを投稿

このブログの人気の投稿

VirtualBoxのスナップショット機能

-
イメージ
本記事では、VirtualBoxのスナップショットがもつ情報と使い方について見ていきます。   【目次】 ［１］はじめに ［２］スナップショットの保存内容 ［３］VirtualBox マネージャのスナップショット画面 ［４］スナップショットの作成 ［５］スナップショットのプロパティの表示と編集 ［６］スナップショットの復元 ［７］「最新の状態」とスナップショットの履歴 ［８］スナップショットの削除 ［９］エクスポート/インポートの注意事項 ［１］はじめに 仮想マシンを利用するの利点の一つは、ある時点の仮想マシンの状態を保存し（スナップショットを作成）、後に、保存した状態を容易に復元することができることかと思います。 例えば、開発環境のある状態を保存しておき、ライブラリのバージョンアップを実行してみて、その結果が悪ければバージョンアップ前の状態に戻す、ということが簡単にできます。 スナップショットは、実行中の仮想マシンの状態（メモリ等の状態）も保存できますので、エディタで編集中の状態まで保存、復元できたりします。（少し言い過ぎですが、ワープロ編集中にでUndoやRedoを利用するのと同じような感覚でしょうか。） また、スナップショットのデータは、仮想マシンと統合管理されているため、保存、復元操作が非常に簡単です。 （一方で、スナップショットは、一般に言うバックアップとは少し目的が異なるため、バックアップの代替えになるとは限らない点に注意が必要です。） 本記事ではVirtualBoxのスナップショットについて見ていきます。 （参考） Vagrantをお使いの場合は、記事『 Vagrantのスナップショット機能とVirtualBox 』も参考にして下さい。 ［２］スナップショットの保存内容 VirtualBoxのスナップショットについては、ユーザマニュアルに記載があります。 User Manual 1.10. Snapshots（ https://www.virtualbox.org/manual/ch01.html#snapshots ） 詳しくは上記ドキュメントをご参照頂くとして、スナップショットは仮想マシンの構成、ディスクとメモリの内容を保存しています。 ハードウェア構成を含む仮想マシン設定の完全なコピーを持っています。 これにより、例えば、...
続きを読む

Vision API OCR事始め(1)：TEXT_DETECTIONとDOCUMENT_TEXT_DETECTIONの違い

-
イメージ
これまでの記事で、Google Vision APIの使い方の側面（特にPython）について見てきましたが、平行して、今回からOCR（光学文字認識）の機能面についても見ていきたいと思います。まずは、OCRにあたる２つの機能（特徴タイプ）であるTEXT_DETECTIONとDOCUMENT_TEXT_DETECTIONの違いについて見ていきます。 【目次】 ［１］はじめに ［２］Vision APIが提供する２つのOCR機能 ［３］「～向けに最適化されます」とは？ ［４］簡単な実験での違いの例 （１）スパースと思われる画像の例 （２）高密度と思われる画像の例 （３）少し難しい漢字の例（文字の大きさによる違い） （４）手書き文書の例 （５）TEXT_DETECTIONとDOCUMENT_TEXT_DETECTIONの二つを同時に指定した場合の例 ［５］実験から受ける印象 ［６］最後に ［１］はじめに Google Vision APIのOCRは評判が良く、私もデモを見て凄いなと思いました。昔、仕事でOCRをちょっとだけ使ったことがありますが、その頃を思うと、隔世の感があります。 そこで実際に使ってみようと思って、ドキュメント（ガイド）を読んだり、サンプルを試してみたりしました。それはなんとなく理解できるのですが、現実の問題に適用しようとすると、ある画像形式に対してどのような機能を使い、どのように結果を解釈するのが良いのか、など、もう少し自分なりに頭の整理が必要だと感じました。 というわけで、Googleが公開している資料や実験を通して、私なりに理解したことを共有していきたいと思います。 ただし、私はOCRや画像処理 、機械学習 の専門家ではありませんので、誤った理解もあるかもしれません。また、資料や実験結果は、記事を書いている時点のものであり、モデルのバージョンアップやサービス内容の変更によって、結果が異なる可能性があることをご了承ください。 ［２］Vision APIが提供する２つのOCR機能 Vision APIでは、OCR機能として、「テキスト検出」と「ドキュメント テキスト検出（高密度テキスト / 手書き）」の２つを提供しています。 これらは、機能リスト（ https://cloud.google.com/vision/docs/featu...
続きを読む

Ubuntu/Colab環境でPDFファイルのページを画像化する（pdf2image、pdftoppm、pdftocairo）

-
本記事では、UbuntuやGoogle Colaboratory環境で、オープンソースライブラリのPoppler（poppler-utilsに含まれるpdftoppm、pdftocairo）あるいはPythonライブラリのpdf2imageを利用して、PDFファイルのページをJPEGなどの画像ファイルに変換する方法を見ていきます。 【目次】 ［１］PDFファイルを画像に変換したいとき？ ［２］PDFファイル扱うオープンソースライブラリ （参考）ページの画像化と情報抽出について ［３］コマンドラインからの利用：poppler-utils （１）poppler-utils （２）インストール （３）pdftoppmの利用例 （４）pdftocairoの利用例 ［４］Pythonからの利用：pdf2image （１）pdf2image （２）インストール （３）最も簡単な使い方 （４）メモリを節約する方法（output_folderを利用する方法） （５）メモリを節約する方法（fmtを利用する方法） （６）サムネイルの作成サンプル （７）ページを指定して変換する方法（first_page, last_page） （８）大量ページの変換速度を上げる方法（thread_count） （９）解像度（dpi） （１０）pdftocairo/pdftoppmの画像変換結果を直接利用する（use_pdftocairo） （参考）pdfinfo_from_path関数 ［１］PDFファイルを画像に変換したいとき？ PDF（Portable Document Format）ファイルは広く使われている電子文書です。 PDFファイルは、ブラウザでも表示できますし、無料のAdobe Acrobat Readerをインストールして表示することもできます。 しかし、こういったツールでファイル内容を表示するだけではなく、PDFファイル内のページをJPEGなどの画像ファイルに変換して利用したい場合もあります。 例えば、システム開発において、Webサイトやアプリ内で、PDFファイルの概要をサムネイル表示したいとか、PDFファイルをダウンロードさせたり、ブラウザの別タブでPDFファイルを表示するのではなく、（導線が途切れないように）ページを移動することなく内容を見てもらいたい場合など、いろいろ...
続きを読む