[db tech showcase Tokyo 2015] E27: Neo4jグラフデータベース by クリエーションライン株式会社李昌桓

Copyright ⓒ2015 CREATIONLINE, INC. All Rights Reserved
DB史上最強の頭脳
Neo4j Graph DataBase
Creationline, inc
2015-06-11
C.Lee

自己紹介
• 名前
李昌桓(LEE CHANGHWAN)
• 所属社
 クリエーションライン株式会社
http://creationline.com/neo4j
• 事業内容
 クラウドインテグレーション、ソリューション事業(Neo4j,MongoDB,Chef,Docker,その他)
• 著書
 Amazon Cloudテクニカルガイド,インプレス
 Amazon Elastic MapReduceテクニカルガイド,インプレス
• 所属団体
 AWSユーザー会
 SoftLayerユーザー会
 Neo4jユーザー会(http://jp-neo4j-usersgroup.connpass.com/)
1

2
データ・データ処理とは
今、一度、原点に戻って考えてみよう

デジタルデータ量の増加予測
3
（出典）総務省「ICTコトづくり検討会議」報告書, 米国の市場調査会社(International Data Corporation)

ビッグデータの構成データと
流通量の計量対象データ
4
（出典）総務省「ビッグデータ時代における情報量の計測に係る調査研究」（平成26年）

企業等におけるデータ活用の実態
5
（出典)総務省「データの高度な利活用による業務・サービス革新が我が国経済および社会に与える波及効果に係る
調査研究」（平成26年）

データ利用によって得られる効果
（全体像）
6
（出典）総務省「データの高度な利活用による業務・サービス革新が我が国経済および社会に与える波及効果に係る

所属部門の業務における
データ利用の深度
7
（出典）総務省「データの高度な利活用による業務・サービス革新が我が国経済および社会に与える波及
効果に係る調査研究」（平成26年）

データ利用における課題
8
（出典）総務省「データの高度な利活用による業務・サービス革新が我が国経済および社会に与える波及効果に係る
10年前のDWH導入における我が国の課題
○○と殆ど変わってないじゃないか！？

• データの量、種類、発生源、処理手段…
• データの価値…既知 < 未知
• データの関係性…複雑になっていく一方
9
あなたはどこに注目していますか
（出典）情報通信審議会ICT基本戦略ボード「ビッグデータの活用に関するアドホックグループ」資料

データ・データ処理とは
• 人間は、世界における自分の居場所のモデルを構築してから、大ま
かな予測をして未来に向けてのシミュレートをする。
人間は時間という意識を持っている動物である。
『フューチャー・オブ・マインド』、ミチオ・カク(理論物理学者、ニューヨーク市立大学)、NHK出版
• データとは、自分を取り巻く環境との関係性を理解するための材料で
ある
洞窟の壁画、石版、羊の革、紙、デジタル化
洞窟の壁画は、データのお手本…人間が食べる動物、人間を食べる動物が絵かれている。
• データ処理とは、自分(個人・組織)取り巻く、環境や事象との関係性を理
解する事であり、その究極的な価値は、未来の予測可能性にある
様々な道具(算盤…コンピューター)利用し、様々な表現(数字、文字、チャート、グラフ、統計）を取り入れて
いる
洞窟の壁画は、データ処理のお手本…自分達と環境との関係性が適格に理解できるし、未来の予測にも繋がる。
10

11
グラフデータベースの座標
3桁を超えるデータベース種の爆発の時代

データ処理の道具
• アーキテクチャー
マスター型/P2P型/イネーブラ型
• データモデル
関係型/カラム指向型/キー・バリュー型/ドキュメント指向型/グラフ型
• SQL/NoSQL（関係型DB/その他）
ANSI・ISO規格/独自のAPI又はQuery言語
• オペレーションDB/レポーティングDB
異なるデータ構想
• インテグレーションDB/アプケーションDB
多言語による実装（RESTful)
12

データベースの進化
13
出典：Learning Neo4j、Rik Van Bruggen
コッドさんが、リレーショナルデータベースに関する最初の論文を発表したのが1969年、SQLが登場
したのが1976年で、Oracle が登場したのか1983年ですが、この数十年はデータベースにおいても大
変動の時代でした。
究極的な関係化

グラフ型データベースの座標
14
デ
ー
タ
の
サ
イ
ズ
データ処理の複雑性(＝関係性)弱強
強
キー・バリュー型
関係型
グラフ型

グラフ型
関係型
弱い関係性と強い関係性
15
弱強集計処理ジョイン
統計処理
パターンマッチング
仕分け
キー・バリュー型
カラム指向型
ドキュメント指向型
専用ツール・API
専門知識が必要

16
グラフデータ処理
DB史上最強の頭脳

グラフとは
17
チャートグラフ
約3世紀ぐらい続く数学理論

グラフの3大の構成要素
• ラベル
テーブルのようなもの。ノードのグループ名称。例）User
• ノード
レコードのようなもの。キー・バリューの属性を持つ。例）U00001
• 関係性
ノードとノードの関係を示す(-->,<--)。キー・バリューの属性を持つ。例）(User)-[:注文した]->(販売履歴)
• 属性
カラムのようなもの（キー：バリュー）。ノードと関係性の両方に存在。
例）(:User {uid:”U00001”, born:1963, gender:”man”})
18

データの論理構成
19
キー：バリュー
ノード
• ノードストア
属性1
キー：バリューキー：バリューキー：バリュー
属性2 属性3 属性n
キー：バリュー
タイプ(関係性の名称)
• 関係性ストア
属性1
キー：バリューキー：バリューキー：バリュー
属性2 属性3 属性n
ラベル(ドメイン)

パターン
 様々なグラフの形状
 グラフは、どのような事象でも抽象化できる
20
A
A B
A’
Learning Neo4j、Rik Van Bruggen
在りのまま

データモデル(雛形)
21
ユーザー販売履歴
注文した
• データモデル
ER図と似ていますが、正規化の観点からみると、データのドメイン(エンティティ）を認識する程度の緩いもの
であり、在りのまま…ドメイン間の関係性の認識を重視しています
:ラベル
:ラベル
:関係性

グラフ化
22• グラフ
• データ
CSV, JSON
uid U000001
born 1949
gender man
oid 20140905081933-U001343
number 5
price 9359
datetime 2014-09-05 08:19:33
date 2014-09-05
U000001
20140905
081933-
U001343
:注文した
• グラフ
最小単位は1ノード(丸1個）

関係型DBのデータ処理
23
顧客Aの名称、商品名、購入金額を出力する
基本的にインデックスを利用し、データ間の関係性を紐解きながらデータ処理を行う

SQL
24
SELECT 顧客.顧客名, 商品.商品名, 販売履歴.数量 *販売履歴.単価 AS 金額
FROM 顧客, 販売履歴, 商品
WHERE 顧客.顧客ID = 販売履歴.顧客ID
AND 顧客.顧客名="A"
AND 販売履歴.商品ID = 商品.商品ID
顧客.顧客名商品.商品名金額
A c ¥4,500
 関係性をSQLの中に指定してもらう
 データの大半は関係性を紐解くことである

グラフDBのデータ処理
25
顧客Aの名称、商品名、購入金額を計算する
関係性の永続化関係性の永続化
 関係性が永続化されている
 永続化された関係性の上で、パターンマッ
チングを行う
 とても複雑なSQL処理、SQLでは不可能な関
係性の処理に対応可能である

Cypher Query(Neo4j)
26
MATCH (顧客 {顧客名: "A"})-->(販売履歴)-->(商品)
RETRUN 顧客.顧客名, 商品.商品名, 販売履歴.数量 * 販売履歴.単価 AS 金額
顧客.顧客名商品.商品名金額
A b ¥4,500
 既定の関係性を利用するので、関係性は記号(-->, <--, --)で表現する
 関係性を紐解く必要がないため、その余力を強い関係性の処理に当てる

トラバーサル処理
27
2014
9m 10m
4d 5d
21h
o2
22h
o4 o7o6o1 o3
 既に永続化されている関係性を辿って走査
する事をトラバーサルという
 インデックス・スキャンは、開始ノードの
検索に使う
注文番号

パターンマッチング
28
 グラフ構造に抽象化したデータの処理を行う
 最終結果は、CSV、JSON、SVG、PNGなどで出力する
CSV JSON

Cypher構文の階層構造は
パイプ
29
• SQLは階層間で繋がっている一連のデータ処理
• Cyhperは階層間で独立しているパイプ処理(バケツ・リレー)

販売履歴モデル
30
http://www.creationline.com/lab/neo4j
• 売上集計
• クロス集計
• レコメンデーション
:ラベル
:関係性

品質管理モデル
31
部品2
部品1
工程1 工程2 工程3 工程4
部品3
部品4
完成品
• 異常を起こしたパーツの工程を追跡
• 工程別、パーツ別の異常頻度の調査や原因調査
• 再発防止策

Tokyo Metro Subway
System
32
http://graphgist.neo4j.com/#!/gists/all

Product Hierarchy
33

Credit Card Fraud
Detection
34
 限度額ぎりぎりまでを引き出している
 支払期限の違反が標準偏差の2倍
 アカウントに複数のユーザー情報が存在する

データモデルの事例
35
Asset
Management,Automobile,Banking,Bi
oinformatics,Biomedical,Business,Bu
siness
Intelligence,Classification,Cloud
Computing,Competitive
Sports,Content
Management,Corporate
Training,Cost Optimization,Data
Science,Data Visualization,Drug
Portfolio,Ecology,Education,Electroni
cs,Entertainment,Environment,Fashio
n,Finance,Food & Beverage...

36
唯一無二のグラフデータベース
Neo4j

Neo4jとは
• グラフ理論をデータ処理エンジンとして搭載しているDBMS
ネオテクノロージ社のデータベース製品(http://neo4j.com)
• SQLより強い関係性の処理に向いているデータベース
関係性の永続化、パターンマッチング
• Cypher Query(サイファー・クエリ）
SQLライク宣言型のQuery言語、パターンマッチング(SQLで不可能な複雑な関係をも紐解く）
• OLTPエンジン
トランザクション処理OK、分離レベル(Commited Read)、マルチスレッド対応
• インターフェース
Webインテーフェース、Neo4jShell、 RESTfule API, CORE API
• オープンソース版(GPL)と商用版
Community版/Enterprise版(保守、HA、バックアップ、キャッシュ）
37

システム構成
38
Cypher Query
RESTful API(JSON)
Neo4j-
WebInterface
FireFox/ IE
バッチ処理
CSV
RESTful API(JSON)
HTTP/HTTPS
スタンドアロン
CPU/メモリ/IOPS
…食いしん坊

バックアップ
39
物理バックアップ
スナップショット
Neo4jBackup
(Online backu, full or
incremental)
DRBD
(Distributed Replicated
Block Device)

HA構成
40
• マスター型(水平分散はできない)
• スレーブをリードレプリカとして利用可能

セキュリティ
• HTTPSを標準実装
クライアントとサーバー間の通信
• DBアクセスはベーシック認証(ユーザID, パスワード)
Webインターフェース、Neo4jShell、REST API
• Hosted scripting
サーバーからアクセス元を制限(IP, URLなど）
41

データ数の制限
42
Neo4j 2.X
ノード数： 340億
関係性数： 340億
属性数：2,740億
関係性のタイプ：32,000

43
DB史上最強の頭脳を支える
Cypher Query

Cyhper Query
• グラフ構造のデータ処理のために開発された宣言型Query言語
永続化された関係性の下で、とても短い構文で複雑なデータ処理を可能にする
• パタンマッチング
SQLのジョインを超える複雑な関係性の処理
• スキーマレス
アプリケーションデータベース
• シンプルなデータタイプ
文字列/小数/16進数8進数/整数/ブーリン型
• インデックス
一意性の保障、グラフの開始ノードの検索
• 実行計画
RULE BASE, COST BASE
44

Cyper Queryの構文
45
Cypher SQL
MATCH ...RETURN SELECT + JOIN
WHERE WHERE
WITH…パイプ WITH…テンプレート
CREATE CREATE
MERGE CREATE or UPDATE
DELETE DELETE
CREATR INDEX CREATR INDEX
EXPLAIN/PROFILE EXPLAIN PLAN
 Cypherは、パターンマッチング(多次元的なジョインが可能)
現実世界のデータは、殆どが多次元的な構造
 パターンマッチングの概念に慣れると…その後はSQLよりも遥かに簡単に書ける

データ作成・更新・削除
• 作成(CREATE)
CREATE (u:User { uid:“U00001”,born:1963})
• 更新(MATCH ...MERGE)
MATCH (u:User { uid:“U00001”)
MERGE SET u.born=1973
• 削除(MATCH ...DELETE)
MATCH (u:User { uid:“U00001”)
DELETE u
46
アプリケーション-->RESTful APIをラッピングし、データはJSONで
やり取りする。

BULK DATA(LOAD CSV)
• ソースデータはヘッダ付きのCSV
uid,born,gender
U000001,1949,man
U000002,1979,woman
…
• 登録(LOAD CSV…CREATE)
LOAD CSV WITH HEADERS FROM "file:///C:/Temp/data/user.csv" AS line
CREATE (u:User { uid:line.uid, born:toInt(line.born) })
・更新/削除
LOAD CSV...MATCH...MERGE...
LOAD CSV...MATCH...DELETE
47

関係性の作成
• MATCH...CREATE
48
U00001
20140905
222502-
U000724
PLACED
{関係性ID: ユーザノードID:販売履歴ノードID:方向}
MATCH
(user:User { uid:“U00001}),
(order:Order { oid:”20140905222502-U000724”)
CREATE
(user)-[:PLACED]->(order)

トランザクション処理
49
:POST http://localhost:7474/db/data/transaction
{
"statements" : [ {
"statement" : "CREATE (nser:User {props}) RETURN user",
"parameters" : {
"props" : {
"name" : “U00001"
}
}
} ]
}
"commit": "http://localhost:7474/db/data/transaction/5/commit”
:POST http://localhost:7474/db/data/transaction/5/commit
• トークン(URI)が返ってくる
• REST APIを実行す
る
• 空の構文(URI)を実行する

デモ1:売上集計:グラフ表現
50
MATCH
(y:Year {year:2014})-->(m:Month {month:9})-->(d:Day
{day:5})-->(h:Hour {hour:22})-->(o)-[:CONTAINS]->(g)
RETURN *
販売履歴
商品
日付
月
日
年

デモ2:売上集計:データ表現
51
MATCH
(y:Year {year:2014})-->(m:Month {month:9})-->(d:Day {day:5})--
>(h:Hour {hour:22})-->(o)-[:CONTAINS]->(g)
RETURN g.gid AS 商品, o.number*o.price AS 価格 LIMIT 5
商品価格
G0038 10,336
G0192 4,288
G0038 15,508
G0175 2,992
G0070 6,098

デモ3:レコメンデーション
52
//①売上トップ10のユーザーと金額
MATCH (y:Year {year:2014})-->(m:Month {month:9})-->(d)-->(h)-->(o)<-[:PLACED]-(u)
WITH u, sum(o.number * o.price) AS total
ORDER BY total DESC
LIMIT 10
//②売上トップ10のユーザーが購入した商品一覧
MATCH (u)-->(o)-[:CONTAINS]->(g), (y:Year {year:2014})-->(m:Month {month:9})-->(d)-->(h)-
->(o)
WITH distinct g
//③売上トップ10のユーザーが購入した商品のなかで売れ筋トップ10
MATCH (y:Year {year:2014})-->(m:Month {month:9})-->(d)-->(h)-->(o)-[:CONTAINS]->(g)
RETURN *
LIMIT 10

デモ4：レコメンデーション
53
//①売上トップ10ユーザー
WITH u, sum(o.number * o.price) AS total
ORDER BY total DESC
LIMIT 10
//②売上トップ10ユーザーが購入している商品
MATCH (u)-->(o)-[:CONTAINS]->(g), (y:Year {year:2014})-->(m:Month {month:9})-->(d)-->(h)-->(o)
WITH distinct g
//③売上トップ10ユーザーが購入している商品で売れ筋トップ10⇒ABC
MATCH (y:Year {year:2014})-->(m:Month {month:9})-->(d)-->(h)-->(o)-[:CONTAINS]->(g)
WITH g.gid AS ggid, sum( o.number * o.price) AS total
ORDER BY total DESC
LIMIT 10
//④ABCのどれらかを購入しているユーザーと商品一覧⇒abc
WITH collect(ggid) AS cggid UNWIND cggid AS gx
MATCH (u)-->(o)-[:CONTAINS]->(g:Goods { gid:gx}), (y:Year {year:2014})-->(m:Month {month:9})-->(d)-->(h)-->(o)
WITH cggid AS list1, u.uid AS uuid, collect(g.gid) AS list2
ORDER BY uuid
//LIMIT 10
//⑤ABCとabcを比較し、購入していないABCを薦める
RETURN uuid AS ユーザID, filter( x IN list1 WHERE NOT ( x IN list2)) AS 推薦商品一覧
LIMIT 10

デモ5:クロス集計
54
//①ユーザー毎の売上金額の計算し、CASE文で金額範囲毎のユーザー数にカウントする
WITH u.uid AS uuid, sum(o.number * o.price) AS total
WITH
CASE WHEN total <10000 THEN count(uuid) END AS lt10000,
CASE WHEN total >=10000 AND total <50000 THEN count(uuid) END AS lt50000,
CASE WHEN total >=150000 THEN count(uuid) END AS gt150000
//②①の結果をリストにまとめる
WITH collect(lt10000) AS lt10000,
collect(lt50000) AS lt50000,
collect(gt150000) AS gt150000
//③結果をリストから取り出す
RETURN
head(lt10000) AS 金額1万以下,
head(gt150000) AS 金額15万上

デモ6:経理探し
55

デモ7:最短経路
56
MATCH
(startLeaf:Alphabet { name:"A" }),
(endLeaf:Alphabet { name:"Z" }),
valuePath= shortestPath((startLeaf)-[:NEXT*]->(endLeaf))
RETURN
extract( n IN nodes(valuePath) | n.name ) AS 経路,
length(valuePath) AS 区間数,
reduce(totalCost=0, n IN relationships(valuePath) | totalCost + n.charge)
AS 料金
経路区間数料金
[A, U, V, W, X, Y, Z] 6 60

デモ8:最多経路
57
MATCH
(startLeaf:Alphabet { name:"A" }),
(endLeaf:Alphabet { name:"Z" }),
valuePath=(startLeaf)-[:NEXT*]->(endLeaf)
RETURN
extract( n IN nodes(valuePath) | n.name ) AS 経路,
length(valuePath) AS 区間数,
reduce(totalCost=0, n IN relationships(valuePath) | totalCost + n.charge) AS
料金
経路区間数料金
[A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z] 25 250
[A, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z] 22 220
[A, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z] 18 180
[A, B, C, D, E, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z] 22 220
[A, E, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z] 19 190
[A, O, P, Q, R, S, T, U, V, W, X, Y, Z] 12 120
[A, B, C, D, E, F, G, H, I, O, P, Q, R, S, T, U, V, W, X, Y, Z] 20 200
[A, E, F, G, H, I, O, P, Q, R, S, T, U, V, W, X, Y, Z] 17 170
[A, I, O, P, Q, R, S, T, U, V, W, X, Y, Z] 13 130
[A, B, C, D, E, I, O, P, Q, R, S, T, U, V, W, X, Y, Z] 17 170
[A, E, I, O, P, Q, R, S, T, U, V, W, X, Y, Z] 14 140
[A, U, V, W, X, Y, Z] 6 60
[A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, U, V, W, X, Y, Z] 20 200
[A, E, F, G, H, I, J, K, L, M, N, O, U, V, W, X, Y, Z] 17 170
[A, I, J, K, L, M, N, O, U, V, W, X, Y, Z] 13 130
[A, B, C, D, E, I, J, K, L, M, N, O, U, V, W, X, Y, Z] 17 170
[A, E, I, J, K, L, M, N, O, U, V, W, X, Y, Z] 14 140
[A, O, U, V, W, X, Y, Z] 7 70
[A, B, C, D, E, F, G, H, I, O, U, V, W, X, Y, Z] 15 150
[A, E, F, G, H, I, O, U, V, W, X, Y, Z] 12 120
[A, I, O, U, V, W, X, Y, Z] 8 80
[A, B, C, D, E, I, O, U, V, W, X, Y, Z] 12 120
[A, E, I, O, U, V, W, X, Y, Z] 9 90

可視化の意義①
• グラフの正確さを検証する
グラフは、殆どが多次元表現であるために関係性が正しく作られているのかどうかは、サンプルを出力してみな
いと検証が困難である
58
Learning Neo4j、Rik Van Bruggen

可視化の意義②
• パターンマッチンがイメージできる
グラフのパターンから構文を検証しなら最終結果に辿りつく。特に複雑なパターンマッチングの構文作成では、
不可欠である。
59

可視化の意義③
• グラフ自身がレポートである
60

61
強い関係性の処理は至るどころにある
Graphs Are Everywhere

顧客分布スナップショット
62
http://www.creationline.com/neo4j/customers.html

Neo4jに向いている用途
• 様々強い関係性のデータ処理
パターンマッチング（様々な多次元的な関係表現）、とても深い階層関係など
• SQLでは表現できないデータ表現
経路(路線、流通、SCM)や製造工程などフローを伴うデータ処理
• 統計処理に不向きの因果関係のデータ表現
より小規模で個別的な繋がり、人の直観との共同作業で関係を紐解く
• 試行錯誤的なアプローチ
仮説→検証→仮説…Cypher
• 普通の集計処理をするとどうなるの？
処理できますが…「コスト < 価値」をどのように引き出すか？
63

Neo4j関連情報
参考資料
http://neo4j.com/docs/
http://www.creationline.com/neo4j
関連記事
http://www.creationline.com/lab/neo4j
http://qiita/awk256/itmes
64

Neo4jユーザーグループ
• ホームページ
http://jp-neo4j-usersgroup.connpass.com/
https://sites.google.com/site/japanneo4jusergroup/
https://www.facebook.com/neo4jusersgroup
@Neo4jUsersGroup
• 活動
無料セミナー, 執筆
65

[db tech showcase Tokyo 2015] E27: Neo4jグラフデータベース by クリエーションライン株式会社 李昌桓

More Related Content

What's hot

Viewers also liked

Similar to [db tech showcase Tokyo 2015] E27: Neo4jグラフデータベース by クリエーションライン株式会社 李昌桓

More from Insight Technology, Inc.