はじめに
現在、株式会社サイバーエージェントでは、いくつかのケースでHBaseを使用しています。その中の一つがグラフDBです。
簡単に経緯を説明します。株式会社サイバーエージェントでは、2012年6月にスマートフォン向けプラットフォームをリリースしました。
このプラットフォームでは、「デカグラフ」構想というものを掲げています。「デカグラフ」構想とは、各サービスのユーザー層を「ミニグラフ」と名付け、ユーザーに共通のIDで自由に回遊してもらうことで1つの巨大なスマートフォン向けサービスを構築するというものです。
そこで、必要になったのがグラフ構造を保持するデータベースでした。当然、データが大量になるのでスケールする必要があります。また、オンラインで用いられるので低レスポンスタイムで高スループットが求められます。
そこで私達は、HBaseを用いてグラフDB（プロジェクト名「Hornet」）を開発することにしました（※1）。
今回は、私達がグラフ構造をHBaseでどう表現したか、そして開発するにあたって用いたテクニックなどを紹介していきたいと思います。ただし、今回紹介するものは、説明のために実際のものと比べて簡易なものとなっていますのでご了承ください。
対象読者
- HBaseを使ってみたいけど、どう使ったらよいか分からない方
- MySQLなどのRDB以外のデータベースを使ってみたい方
要件定義
まずは、要件定義からです。データモデルとしては、プロパティグラフを想定しています。
プロパティグラフとは、以下のようなものです。
プロパティグラフでは、ノードとそれの関係性を表すリレーションシップが存在します。ノードはノードIDを持ちます。リレーションシップには方向とタイプがあります。
また、各ノードと各リレーションシップは、プロパティを持ちます。プロパティは、名前とそれに対する値というkey-valueの構造になっています。
そしてプロパティグラフに対し、以下の操作が可能なグラフDBを想定しています。
- ノードの作成・削除
- ノードのプロパティの取得
- ノードのプロパティの追加・更新・削除
- リレーションシップの作成・削除
- リレーションシップのプロパティの取得
- リレーションシップのプロパティの追加・更新・削除
- あるノードの隣接リレーションシップを最新順で取得（方向を指定できる）
論理設計
今回対象とするグラフDBのER図は、以下のようになります。
