TL;DR
つながり方に注目するためのDB。
数多のDBの中での位置づけ
SQL
| 分類 | データモデル/種別 | 実装例 |
|---|---|---|
| RDB | Relational Model | MySQL |
NoSQL
| 種別 | 実装例 |
|---|---|
| Column | HBase |
| Document | MongoDB |
| Key-value | Redis |
| Graph | Neo4j |
| Multi-model | Couchbase |
参考：
「Database」https://en.wikipedia.org/wiki/Database#Models
「NoSQL」https://en.wikipedia.org/wiki/NoSQL#Types_and_examples_of_NoSQL_databases
なぜGraphが必要なのか
RDBは大規模データに向かない
- テーブル間結合が遅い
- レコード数が増えると、検索に掛かる時間と難易度が増大する
- メモリ枯渇の危険性
- ディスクのスワップ枯渇の危険性
- ディスクI/Oの限界
- テーブルを上手く正規化しないとロック地獄になる
- etc...
参考：
「集計はRDBばかりに頑張らせるのをやめると幸せになれる。」 http://qiita.com/taruhachi/items/496d217ed2338239f0d2
Graph DBの長所と短所
長所
- ACID特性が担保されている
- オブジェクト間の関連づけを簡単に表現できる
- 検索が局所的なのでスケールしやすい
短所
- 全体から検索するのは苦手
参考：
「GraphDB徹底入門」http://www.slideshare.net/doryokujin/graphdbgraphdb
「The ACID Consistency Model」https://neo4j.com/blog/acid-vs-base-consistency-models-explained/
Graph DBの使いどころ
- 最短経路探索
- グラフの一部を抜き出す
Graph DBの成り立ち
Property Graph model
- ノード
- プロパティを持つ
- リレーション(エッジ)
- プロパティを持つ
- 関係の向きを持つ
- プロパティ
- key-value型のデータ
参考：
「RDBとグラフDBは使いよう」http://lab.adn-mobasia.net/?p=3817
Query Language
Neo4jの場合はCypherを使っている。