Graph Database and Amazon Neptune

© 2018, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Graph Database and Amazon Neptune
2018.11.01

自己紹介
五十嵐建平
技術統括本部
ソリューションアーキテクト
好きなサービス
• Amazon Aurora
• Amazon RDS Performance Insights
• Amazon Neptune

内容についての注意点
• 本資料では2018年11月1日時点のサービス内容および価格についてご説明しています。最新の情報
はAWS公式ウェブサイト(http://aws.amazon.com)にてご確認ください。
• 資料作成には十分注意しておりますが、資料内の価格とAWS公式ウェブサイト記載の価格に相違が
あった場合、AWS公式ウェブサイトの価格を優先とさせていただきます。
• 価格は税抜表記となっています。日本居住者のお客様が東京リージョンを使用する場合、別途消費
税をご請求させていただきます。
• AWS does not offer binding price quotes. AWS pricing is publicly available and is subject to
change in accordance with the AWS Customer Agreement available at
http://aws.amazon.com/agreement/. Any pricing information included in this document is
provided only as an estimate of usage charges for AWS services based on certain
information that you have provided. Monthly charges will be based on your actual use of
AWS services, and may vary from the estimates provided.

本セッションの内容
• どのような場面でグラフデータベースを使うべきか
• Amazon Neptuneの特徴
• Gremlinの例
• 開発時のベストプラクティス
• 可視化

どのような場面で
グラフデータベースを
使うべきなのか？

グラフ構造〜ノードとエッジ
ソーシャルグラフ
出身地

自分が開発している
アプリケーションのデータは
グラフ構造なのか？
出身地

データモデリングからの視点
多対多
グラフデータベース
1対1
Key-Value ストア
多対1
RDBMS

請求書では?
すべての関連が
多対1
It's Relational Data 請求書
マスタ
請求書
明細
顧客
https://images-fe.ssl-images-amazon.com/images/G/09/help/others/b2b_invoice_sample.png

ソーシャルグラフでは？
すべての関連が多対多
It's Graph

Many
Many-to-Many

SQLからの視点
使用するSQL文に
再帰With句や
Connect By (Oracle)
を使う必要がある
with tab(ID,PID,Lv,Path) as(
select ID,PID,1
from Data
where PID is null
union all
select d.ID,d.PID,t.Lv+1
from tab t, Data d
where t.ID = d.PID)
select * from tab;
グラフ探索はクエリの複雑性が高くなりやすい

グラフデータのユースケース
ソーシャル
グラフ
ライフサイエンスネットワーク/IT運用不正検出
レコメンデーションナレッジグラフ

RDBによるグラフデータ(高度に連結したデータ)での課題
SQL
グラフ処理
に不向き
厳格なスキーマ

グラフデータベース
グラフ構造のために最適化された
効率的なストレージと
探索エンジン

グラフ処理の分類
Traversal Analytics

Amazon Neptuneの特徴

従来のグラフデータベースの課題にアプローチ
可用性スケール I/F価格

クエリ性能
• Traversalワークロードにおいて
毎秒100,000件のクエリをサポートするよう設計
• 最大15個のリードレプリカ
• 専用に設計されたクラウドネイティブなストレージサービス
• 最適化されたインメモリアーキテクチャ
• クエリの最適化
• 索引を作成する必要がない
• Neptune側で自動的に最適なI/Oパスを実行

リージョン
• 米国東部 (バージニア北部)
• 米国東部 (オハイオ)
• 米国西部 (オレゴン)
• 欧州 (アイルランド)
• 欧州 (ロンドン)
順次拡大予定

Gremlinの例(基礎)

2つのグラフモデルとフレームワーク
Apache TinkerPop™ (OSS)
Gremlin Traversal Language
W3C標準
SPARQL Query Language
RDFプロパティグラフ
https://docs.aws.amazon.com/ja_jp/neptune/latest/userguide/access-graph-gremlin-differences.html

プロパティグラフ
• 頂点(Vertex)はエンティティ/ドメイン
• 辺(Edge)は頂点間の関係
name:
Bill
name:
Sarah
UserUser
FRIEND
strength: 1

プロパティグラフの作成
g.addV('User').property('name','Bill');
g.addV('User').property('name','Sarah');
g.V().has('name','Sarah').as('a').
V().has('name','Bill').
addE('FRIEND').to('a').property('strength',1);
g.V().has('name','Bill').out('FRIEND')
name:
Sarah
User
name:
Bill
User
2つの頂点を追加
FRIEND
strength: 1
エッジで接続
BillからFRIEND
をたどって
Sarahを得る

Gremlin
• グラフ構造を渡り歩くための専用言語
• Domain-specific Language
• オブジェクトを探索する小人のイメージ
• 順序よくステップを踏んでいく
• エッジに行って…
ラベルやプロパティを見て…
必要であれば計算処理もして…

トラバーサルの例
g.V().has("name", "Sue").
in("WORKS_FOR").
in("WORKS_FOR").
count()
name:
Sue
name:
Ed
name:
Helen
WORKS_FOR WORKS_FOR
name:
Bill
name:
Mary
WORKS_FOR WORKS_FOR
name:
Terry
WORKS_FOR

探索ソース
in("WORKS_FOR").
in("WORKS_FOR").
count()
name:
Sue
name:
Ed
name:
Helen
WORKS_FOR WORKS_FOR
name:
Bill
name:
Mary
WORKS_FOR WORKS_FOR
name:
Terry
WORKS_FOR
g

探索の生成
in("WORKS_FOR").
in("WORKS_FOR").
count()
name:
Sue
name:
Ed
name:
Helen
WORKS_FOR WORKS_FOR
name:
Bill
name:
Mary
WORKS_FOR WORKS_FOR
name:
Terry
WORKS_FOR
T
開始ノードを
探索

IN側の WORKS_FOR エッジをフォロー
in("WORKS_FOR").
in("WORKS_FOR").
count()
name:
Sue
name:
Ed
name:
Helen
WORKS_FOR WORKS_FOR
name:
Bill
name:
Mary
WORKS_FOR WORKS_FOR
name:
Terry
WORKS_FOR
TT
Incoming
エッジ
探索されるのは
頂点

さらにIN側のWORKS_FORエッジをフォロー
in("WORKS_FOR").
in("WORKS_FOR").
count()
name:
Sue
name:
Ed
name:
Helen
WORKS_FOR WORKS_FOR
name:
Bill
name:
Mary
WORKS_FOR
name:
Terry
WORKS_FORWORKS_FOR
TT T

ノードのカウント
in("WORKS_FOR").
in("WORKS_FOR").
count()
name:
Sue
name:
Ed
name:
Helen
WORKS_FOR WORKS_FOR
name:
Bill
name:
Mary
WORKS_FOR WORKS_FOR
name:
Terry
WORKS_FOR
3

Gremlinの例
(Social Networkにおける
レコメンデーション)

三角閉路を作る
FRIEND
太郎
花子

FRIEND
FRIEND
雲海
太郎
花子

FRIEND
FRIEND
雲海
太郎
花子
FRIEND

いいところ
• 似たもの同士を結びつける
• 類は友を呼ぶ
• 友だちの友だちは友だちだろう
• オンラインレコメンデーション
• "雲海"にバインド
• 周りのグラフから友だちではない"友だちの友だち"を探索
• 新たなエッジをレコメンデーション

新たなエッジをレコメンデーション
雲海

既に存在する友だち関係
FRIEND
雲海
太郎

見つけた！
FRIEND
FRIEND
雲海
太郎
花子

レコメンデーション
FRIEND
FRIEND
雲海
太郎
花子

サンプルデータ

新たな友だちをレコメンドする
g.V().has('name','Terry').as('user').
both('FRIEND').aggregate('friends').
both('FRIEND').
where(neq('user')).where(without('friends')).
groupCount().by('name').
order(local).by(values, decr)

Terryを探す
both('FRIEND').
ユーザ

Terryの友だちを探索
both('FRIEND').
ユーザ
友だち
方向は無視
探索集合をくくって
名前付け

友だちの友だち・・・
both('FRIEND').
ユーザ
友だち
友だちの
友だち
FRIEND
FRIEND

…だけどTerryの友だちではない
both('FRIEND').
ユーザ
友だち
友だちの
友だち
X
FRIEND
FRIEND
自分以外
名前付けされた
探索集合でもない

名前ごとにグループ化してカウント
both('FRIEND').
nameごとに
グループ化して
カウントした値を
valuesに追加

共通の友だちの数でソート
both('FRIEND').

結果
[Henry:3,
Emily:2,
Colin:2,
Kate:1,
Sarah:1,
Chloe:1]

クエリ性能
• Traversalワークロードにおいて
毎秒100,000件のクエリをサポートするよう設計
both('FRIEND').

開発時のベストプラクティス

RDBMSからの移行 (TinkerPop)
データベース S3バケット
バルクロードCSV作成/配置
SQL発行+整形を
EC2やコンテナで実施
フォルダ指定して
実行
スキーマ
ユーザ商品
ノード
ユーザ-商品
エッジ
ユーザ-ユーザ
フォルダ

EC2やLambdaからのアクセス
Neptune はVPC内に配置される
• Public IP は付与されない
• Lambdaを使うならVPC内に
https://docs.aws.amazon.com/ja_jp/neptune/latest/userguide/access-graph-launch-ec2-instance.html
VPC
インターネットEC2
Lambda
S3バケット

バルクロード
• トランザクションとはならない
• 追加のみ
• 1ファイルずつマルチスレッド実行される
 大きなgzip圧縮されたファイルを用いるのが良い
• インスタンスタイプによりほぼ線形に速度が変わる
 バルクロード時だけ r4.8xlarge を使用して終わったら
通常クエリ用のインスタンスタイプにする

SQL文の移行
• SQLの実行計画をヒントにトラバーサルを組み立てる
PK検索
 NESTED LOOPS
 FILTER
 NESTED LOOPS
g.V().has(…).
both(…).
where(…).
both(…)

デバッグ
path(), simplePath(),
cyclicPath() を使ってトラバー
サルを把握する
gremlin> g.V(1).both().both()
==>v[1]
==>v[4]
==>v[6]
==>v[1]
==>v[5]
==>v[3]
==>v[1]
gremlin> g.V(1).both().both().simplePath()
==>v[4]
==>v[6]
==>v[5]
==>v[3]
gremlin> g.V(1).both().both().simplePath().path()
==>[v[1], v[3], v[4]]
==>[v[1], v[3], v[6]]
==>[v[1], v[4], v[5]]
==>[v[1], v[4], v[3]]
gremlin> g.V(1).both().both().cyclicPath()
==>v[1]
==>v[1]
==>v[1]
gremlin> g.V(1).both().both().cyclicPath().path()
==>[v[1], v[3], v[1]]
==>[v[1], v[2], v[1]]
==>[v[1], v[4], v[1]]

インターフェイス一覧
Tinkerpop/Gremlin RDF/SPARQL バルクロード Neptuneの管理
コンソール Gremlin Console RDF4J Console
RDF4J Workbench
- AWS CLI
Java Gremlin Driver RDF4J - AWS SDK for Java
Python Gremlin-Python Driver - - boto3
.NET Gremlin.NET - - AWS SDK for .NET
HTTP REST HTTP REST (Gremlin) HTTP REST (SPARQL) Neptune Loader API Health Status
REST以外の
HTTP
Gremlin HTTP
WebSocket API
SPARQL HTTP - -

返り値はjson
pythonの例
graph = Graph()
g = graph.traversal().withRemote(
DriverRemoteConnection(
'ws://your-neptune-endpoint:8182/gremlin','g'))
print(g.V().limit(2).toList())
WebSocket APIの結果
がパススルーされる

更新処理
• 1リクエスト = 1トランザクションとなる (READ COMMITTED)
• よくある悩み: 大量一括更新
スループットを最適化するためには・・・
• アプリ側で並列化  並列度 = 2 x vCPU数からスタートして調整
• ただし並列化するとトランザクションも分割される
• 並列化時の更新競合が発生しないようにする
• 粒度を大きくする  1リクエストの最大サイズは150MB
• deleteはリクエストサイズが小さい
• r4.8xlarge で数億件一括削除も可能
• スループットを上げるのなら並列化する
• ロングラン時には neptune_query_timeout を調整する
• デフォルト2分

インメモリ最適化
• Neptuneはインメモリ処理に最適化している
• ホットデータがインスタンスにキャッシュされておくようにする
• メモリ量はインスタンスタイプに依存する
• リードレプリカを活用する
• 更新と読み取りの分離
• アプリケーション側でグラフ領域によってエンドポイントを変える
• 定常時にストレージ読み込みがないことが望ましい
• CloudWatchメトリックの ReadThroughput が低いことを確認する

マルチテナンシー
• Gremlin
• 単一グラフのみをサポート
• 複数グラフを扱う際はアプリケーション側でカバーすればOK
• ラベルやプロパティを重複しないようにすれば良い
• SPARQL
• 名前付きグラフをサポート
• データローダーは NQuads またはトリプルでの名前付きグラフ
指定をサポート

可視化

何のための可視化か？
全体を見るための
可視化
一部を見るための
可視化
大規模グラフのOLTP用途では
こちらが中心となる
視覚的に全体的な構造を把握
クラスタリングの仮説を立てる
ドリルダウン
視覚的にターゲット周辺の構造を把握
トラバーサルの仮説を立てる
大規模グラフではすべてのデータを
描画しても情報過多となる

オープンなインターフェイスの活用
GremlinまたはRDF/SPARQLに対応した可視化ツールを使用
※ Neptune自体は可視化機能を提供しない
可視化ツールの例カテゴリインターフェイス
Graphexp オープンソース Gremlin
Tom Sawyer Software 商用 Gremlin
RDF/SPARQL
Metaphactory 商用 Gremlin
RDF/SPARQL
Cambridge Intelligence / Keylines 商用 RDF/SPARQL

Graphexp
JavaScriptベースのシンプルな
可視化ツール
簡単な設定でNeptuneに対応
Webブラウザから直接Neptune
エンドポイントにアクセス
できる必要がある
https://github.com/bricaud/graphexp

可視化の使用例
クエリのデバッグの補助

まとめ
• どのような場面でグラフデータベースを使うべきか
• Amazon Neptuneの特徴
• Gremlinの例
• 開発時のベストプラクティス
• 可視化

さいごに
Amazon Neptune についてもっと知りたい方はこちら
• 公式ページ
https://aws.amazon.com/jp/neptune/
• ドキュメントやチュートリアルなどのリソース
https://aws.amazon.com/jp/neptune/developer-resources/
• Amazon Neptune Forum
https://forums.aws.amazon.com/forum.jspa?forumID=253
• [AWS Black Belt Online Seminar] Amazon Neptune
https://aws.amazon.com/jp/blogs/news/webinar-bb-neptune-20180703/
Amazon Neptune で
スケーラブルで堅牢なグラフデータベースを
実現しましょう！

ご参加ありがとうございました

Graph Database and Amazon Neptune

More Related Content

What's hot (20)

Similar to Graph Database and Amazon Neptune (20)

More from Amazon Web Services Japan (20)

Recently uploaded (7)

Graph Database and Amazon Neptune