PR

 今回は、シリコンバレーのあるスタートアップ企業の、世界最速をうたうグラフデータベース(グラフDB)の性能評価を実施した一件を紹介しよう。グラフDBは、データの関係性を表すデータモデル(グラフ構造)を持つデータベースである。検証は、筆者が推進している高速データ処理技術HTAP(Hybrid Transactional/Analytical Processing)を比較対象とした。

 その会社は、ネット上での膨大な決済サービスにおける不正取引の解析に実績を持つ。決済を支払者と受取者の2点を結ぶ線と捉えると、決済サービスの実体は2者の関係性を表す無数の線の集合体、つまり巨大なグラフ構造となる。

 この問題をRDBMS上でSQLを用いて解こうとすると、性能や柔軟性に関する問題に直面する。グラフ構造をマトリックス(表形式)で管理すると、SQLが入れ子構造になる副問い合わせの繰り返しが必要になるなど、SQLが複雑化するからだ。

 検証したグラフDBは、標準化されたSQLではなく、グラフ構造専用のクエリーで柔軟性を担保する。そしてクエリーに高速に応答するため、インメモリーDBで超並列処理を実行する。

 HTAPとこのグラフDBは、超並列処理を用いて複雑な問題を短時間で処理する点において似ている。しかし、グラフDBがデータベースで処理する部分を、HTAPではアプリケーションで実現している。彼らは「データベースで処理した方が高速」と主張した。

 性能評価には、筆者がCPUの世代間の性能改善効果を測るために使っているHTAPの性能評価モデルを使った。そのモデルは製造業の「部品表」を含み、グラフ構造の一形態であるツリー(木)構造で部品表を管理する。製品を頂点として必要な部品が複数あり、その部品群の下にさらに小さな部品群を定義するツリー構造である。

 ツリーの深さを可変とするためには、再帰的なテーブル設計が必要だ。自分自身への関連を持たせるため、データの親と子の関係と同じテーブルに、子と孫の関係を格納する。グラフDBでこの部品表の管理を表現してみると、論理的な構造はほぼ一致した。つまり、HTAPを実現するために不可欠な高次正規化したデータモデルは、グラフ構造そのものだったのだ。

 ベンチマークでは、ある製品を製造するのに必要な原材料ごとの在庫を計算する時間を測定した。

データの移動とI/O競合を減らす

 グラフDB側から見たの性能面の主張は「HTAPではデータベースからアプリケーションへのデータ転送が遅い」というもの。確かにデータの移動には、遅延と帯域の制約がある。だが、アプリケーションとデータベースを同一の筐体に配置したらどうだろう。

 そうすると、SQLの問い合わせ時に通信遅延は生じない。さらに複数のデータベースを稼働させ、それぞれに専用のCPUコアと物理メモリーをアサインする。メモリーアクセス時のI/O競合を避け、並列性を高めるためだ。そうしたHTAPとの比較で、グラフDBの性能はほぼ同等だった。技術は異なるが、アーキテクチャーを突き詰めれば、同じ性能を達成できるのだ。

 性能比較に加え、開発生産性やテスト容易性についても意見交換した。グラフDBは専用のクエリー言語を提供する。つまりコンパイルがいらないので、試行錯誤を繰り返しながらクエリーを成長させていきやすい。一方で、処理が複雑になるとローカル変数などをスクリプトの中に宣言することになり、実装上の煩雑さが増す。こうした特徴は、手軽さと手堅さのトレードオフといえる。求める要件に応じた技術を見極めることが重要である。

石田 裕三(いしだ ゆうぞう)
野村総合研究所 上級アプリケーションエンジニア
石田 裕三(いしだ ゆうぞう) 1993年、野村総合研究所入社。1999年、ITとビジネスの融合を目指して米カーネギーメロン大学に留学。経営学とソフトウエア工学を学ぶ。2001年の帰国以降は、オープンソースを活用したプロダクトラインの構築に励む。現在は、Hybrid Transactional/Analytical Processing (HTAP)の事例を国内外で構築中。