[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

http://creationline.com/neo4j

2

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


デジタルデータ量の増加予測

3

（出典）総務省「ICTコトづくり検討会議」報告書, 米国の市場調査会社(International Data Corporation)


ビッグデータの構成データと流通量の計量対象データ

4

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


企業等におけるデータ活用の実態

5

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


データ利用によって得られる効果（全体像）

6

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


所属部門の業務におけるデータ利用の深度

7

（出典）総務省「データの高度な利活用による業務・サービス革新が我が国経済および社会に与える波及

効果に係る調査研究」（平成26年）


データ利用における課題

8

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

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 • グラフデータを抽象化した形状のこと。最小単位は1ノード(丸1個）

• データ 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 20140905081933-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 o7 o6 o1 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ユーザー

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⇒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文で金額範囲毎のユーザー数にカウントする MATCH (y:Year {year:2014})-->(m:Month {month:9})-->(d)-->(h)-->(o)<-[:PLACED]-(u) 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 >=50000 AND total <100000 THEN count(uuid) END AS lt100000, CASE WHEN total >=100000 AND total <150000 THEN count(uuid) END AS lt150000, CASE WHEN total >=150000 THEN count(uuid) END AS gt150000 //②①の結果をリストにまとめる WITH collect(lt10000) AS lt10000, collect(lt50000) AS lt50000, collect(lt100000) AS lt100000, collect(lt150000) AS lt150000, collect(gt150000) AS gt150000 //③結果をリストから取り出す RETURN head(lt10000) AS 金額1万以下, head(lt50000) AS 金額5万以下, head(lt100000) AS 金額10万以下, head(lt150000) AS 金額15万以下, 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://qiita/awk256/itmes

64

http://neo4j.com/docs/

http://neo4j.com/docs/











Neo4jユーザーグループ

• ホームページ http://jp-neo4j-usersgroup.connpass.com/

https://sites.google.com/site/japanneo4jusergroup/

https://www.facebook.com/neo4jusersgroup

@Neo4jUsersGroup

• 活動無料セミナー, 執筆

65

http://jp-neo4j-usersgroup.connpass.com/







https://twitter.com/Neo4jUsersGroup

[db tech showcase Tokyo 2015] E27: Neo4jグラフデータベース by...

Technology

Transcript of [db tech showcase Tokyo 2015] E27: Neo4jグラフデータベース by...