(レポート) DAT203: AWS上でグラフデータベースを構築
こんにちは。オペ部の半瀬です。
はじめに
AWS re:Invent 2015 盛り上がっていますね。弊社ブログではアドバンスト以上のセッションレベルでの記事が(現時点で)多くあげられていますが、セッションレベル初級 (200) で導入編を取り扱うセッションもあります。 （コチラでレベルごとのセッション一覧をひっぱれます。）
今回は、グラフデータベースについて、特徴/利点をまとめているセッションのご紹介です。
タイトルと次
タイトル：(DAT203) Building Graph Databases on AWS (弊社訳：AWS上でグラフデータベースを構築) 目次：（なし） このセッションの要点： ・グラフデータベースの概観を知る ・グラフデータベースのAWS構築例を知る ・Dynamo DB をストレージバックエンドとした Titan
グラフデータベースをAWSで構築(Slide 3-/32)
（※ 以下、スライドの要約）
グラフ型データとは？グラフデータベースとは
前提として、グラフ型データについての話から入っています。
・グラフ型データ ・構成３要素 ・頂点（：vertex あるいは、交点：node) ・有向エッジ（関係性：node間の関連を表す） ・プロパティ（属性） ・ツリー構造の集合体をなす ・グラフデータベース ・データモデルとしてグラフ型データを採用し、クエリ言語をもつ
グラフ型データのモデリング
グラフ型データはどのように考えられるべきか、という要点の話
・NoSQLデータモデル ・ユースケースを出発点に、データモデルを構築する ・例えば ・自分が学生だとして、ある学科について知っているクラスメイトを知りたい、というユースケース ・グラフ型データモデルの構築「Student KNOWS Subject , Student BELONGS_TO Class」
グラフデータベース vs リレーショナルデータベース
そもそもなぜリレーショナルデータベースじゃだめなの？というところのお話
・グラフデータベース ・グラフトラバース：Join を使用しない ・クエリはそれぞれで起点をもつ「MATCH ON x」 ・(?)フィルタリングが効くように正規化されている ・ダイナミックスキーマ
・リレーショナルデータベース ・カラム分析 ・パフォーマンスに正規化されていないテーブル ・クラスターと障害管理 ・クエリオプティマイザーによる再帰クエリのサポート
Titanとは : 分散型グラフデータベース
グラフDB Titanの特徴や利点について
・分散型グラフデータ ・ストレージレイヤでプラグインをもつ ・ネイティブなTinkerPopの実装 ・Lucene, SOLR, Elasticsearch による全文検索 ・Cassandra cluster ・DynamoDB によるスケーラビリティ
neo4j
グラフDB neo4j の特徴や利点について
・SN(shared nothing architecture), シングルマスター(書き込み), マルチレプリケーション(読み込み), JVMを使用して組み込み可能 ・Paxosアルゴリズム ・RAMへのロード回数を多くし、ディスク書き込みを効率的にする ・主要なクエリ言語はCypherでGremlinをサポートしている ・AWS上でのNeo4j
グラフデータベースでの分析
各種分析フレームワークなどの紹介と説明が続きます。
・OLAP:オンライン分析処理 (OLTP:オンライントランザクション処理ではない) ・Hadoop：MapReduceフレームワーク ・GraphX：Sparkによるメモリ上での高速分析（関数ライクな宣言型プログラミングモデル） ・Giraph：HDFSを利用したグラフデータベース（手続き型、vertex-centricプログラミングモデル） ・Aggregation型のクエリ ・TinkerPop ・Apache Tinkerpop：Apacheのインキュベーターフレームワーク：OLAPとOLTPの両方をサポート ・Gremlin：グラフトラバーサルのためのクエリ言語(developed by Apache Tinkerpop) ・Gremlinが構成するAPIがバックエンドのグラフエンジンのインタフェースとなる。
ユースケース
たとえば
例） ・「この商品を買った人はこんな商品も買っている」 ・「最近見たもので更新されたもの」 ・フルフィルメント（発送管理・入金管理・在庫管理・物流管理・顧客管理） ・及び、フルフィルメントのデータ上の問題分析
回析アプローチ
回析手法として、どういったアプローチがあるか。。
- 手動での回析 ・全てのツールはイベントを発行する ・人がそれらをトレース ・検索空間の増大するにつれ、追跡が難しくなる ・クエリによる回析実行に時間がかかるようになる
- ユニーク識別子 ・全てのアイテムはユニーク識別子を持つ ・全ての関連イベント間を抽出することが簡単 ・高コストである ・いくつかのアイテムについて、非現実的
- Inventory Notification graph: data model
なぜリレーショナルデータベースや、NoSQLデータベースを使用しないのか？
- リレーショナルデータベース ・データボリュームが巨大でかつ増大し続けるケース ・垂直スケールをしたくないケース ・テーブルJOINが高コストになりすぎるケース ・ハイアベイラビリティを求められるケース （に、ふさわしくないと考えられた
- NoSQL Store ・Tinkerpopグラフフレームワークに含まれないが、同じ解決策となる
なぜグラフデータベースなのか？
・ちょうど必要なイベントに対してだけ、indexを使用する方法がなかった為 ・収容データからの検索が有用であった為・また、その逆もありえた。（言い換えると、データ検索にたくさんのhopが必要） ・順不同でメッセージを処理する必要があった為 ・グラフデータは単純なメンタルモデルを提供する為
なぜTitanなのか
1. Cassandra
・高い可用性 ・Titanの実装を有する ・EC2Snitch：シングルリージョンにおけるシンプルなクラスターデプロイ(参考：http://docs.datastax.com/en/cassandra/2.0/cassandra/architecture/architectureSnitchEC2_t.html) ・レプリケーション ・RandomPartitoner(参考：https://wiki.apache.org/cassandra/RandomPartitioner) ・Cassandra: Titan での教訓 ・Cassandraクラスターの設定管理について、チームメンバーが初心者であった ・クラスター管理をする必要が発生した ・手動でEC2に置き換える必要があった ・時系列データをうまく扱うことができなかった ・効率的に古いデータをドロップするために、２つのkeyspaceに対して、2つのproducerを走らせる必要があった
2. Dynamo
・大規模なスケール性 ・チューニングとホスト管理からの解放 ・チームメンバーがすでにDynamoDBに慣れていた ・Titanに実装がないことがリスクとしてあった ・どのようにスケールさせるか？ ・1000億の近くのノード（vertex） ・数TBのデータ ・（を、）待ち時間の増加を意識せず（スケールさせる必要がある） ・Titanでの教訓 ・大規模なグラフデータでのパーティショニング ・複数の時系列データを横断したパーティショニング ・（に、対して）スケール時の安定したパフォーマンスを達成
さいごに
グラフDB とは、というところからAWSへの連携までざっくり学ぶことができるセッションでした。少し意訳に自信がないところもありますので、詳細はセッション動画などからご確認いただければと思います。
ご参考までに、このレポートを書くにあたって参考とさせていただいたサイトを挙げておきます。
・Wikipedia - グラフ理論 ・Wikipedia - グラフ (データ構造) ・グラフデータベースはどんな用途に向いている？ ・グラフ構造のデータを高速検索するグラフ型データベース「Neo4j」の勘所 ・グラフDB「Titan」について ・グラフデータベース、NOSQL、Neo4j ・Henry Robinsonによる優しいPaxosの解説 ・Spark を活用する:ビッグデータアプリケーション用の高速インメモリコンピューティング
それではー。
