RDBで直面した性能問題、グラフデータベースでなぜ解決できたか?[PR]

2020年10月13日

リレーショナルデータベースの普及とそれに続くNoSQLの登場により、用途によって適切にデータベースを使い分けることの重要性や利点が認識されるようになってきました。

NoSQLデータベースには、キーバリュー型やJSONドキュメント型などさまざまな種類のデータベースが含まれています。なかでも最近注目が高まっているのが「グラフデータベース」です。

注目度高まっているグラフデータベースとは?

グラフデータベースは、例えばFacebookやLinkedInなどのソーシャルメディアが、ユーザー同士の関係性を表すソーシャルグラフを格納するのに使っている例がよく知られています。

fig グラフ型のデータを図として表した例

マイクロソフトもMicrosoft 365の内部でグラフデータベースを用い、ユーザー同士の関係やグループとの関係、ユーザーとカレンダーやメッセージなどとの関係をグラフ構造で表した「Microsoft Graph」を、API経由で提供していることを明らかにしています。

グラフデータベースはこのように、データとデータの関係性をグラフ構造で表したものといえます。

データの関係性を瞬時に処理可能

リレーショナルデータベースの場合、あるデータが別のデータと関係を持つかどうかは、テーブルをジョインして確認する必要があります。

一方、グラフデータベースは関係を示す情報はデータごとに保持されているため、直ちに関係をたどることが可能です。

つまり、データの関係をどんどんたどる処理を行う場合、リレーショナルデータベースではジョインが何度も行われることで処理にかかる時間が急速に増大する一方、グラフデータベースはそうした処理を得意としているため、すぐに処理が終了します。

データの関係を瞬時に検索できるグラフデータベースは、例えば、あるユーザーがクレジットカードで買い物をしようとしているときに、その利用者名、クレジットカード番号、使用店舗などのさまざまな情報が、過去の不正事例に含まれる何らかの情報と関連がないかを瞬時に検索することによる「不正利用の検出」を行う用途で使われています。

あるいは購入履歴から似たユーザーを検索し、そこから関連性の高い商品を選び出して素早く提示する「推奨エンジン」などの用途にも高い能力を発揮しています。

RDBの性能問題をグラフデータベースで解決

データ同士の関連性を高速に示すことができるグラフデータベースの能力を活用することで、リレーショナルデーターベースでは時間がかかりすぎていた処理を劇的に改善させた企業があります。

大手システムインテグレータとして知られる「NTTコムウェア」です。

同社は、大手通信事業者の大規模ネットワーク管理用データベースにグラフデータベースの「Neo4j」を採用。それによって、20分から30分ほどかかっていた処理をわずか数秒にまで短縮しました。

開発を担当した同社杉本氏は次のようにNeo4j採用の経緯を語ります。

figNTTコムウェア株式会社 ネットワーククラウド事業本部 ネットワークソリューション部 リンク-BU スペシャリスト 杉本昌司氏

「私たちが受託したのは、大規模ネットワーク上のある設備に障害が発生したとき、その障害の影響範囲を特定するシステムの開発でした。

これまでのシステムはその影響範囲の特定に数十分もかかることがあり、そこが課題でした。これを解決する手段としてグラフデータベースを利用することで高速化が可能になるのではないかと考えました」

大手通信事業者のビジネスにとってネットワーク障害が発生した際の影響範囲の把握は非常に重要です。その規模と内容をできるだけ早く把握することが、迅速かつ的確な障害対応につながります。

「それまではリレーショナルデータベースで構築しており、残念ながら十分な性能が出ませんでした。例えばあるビルで停電が起きたとき、そのビルの設備を通過しているネットワークがあって、その影響はどこまで広がるのか、その範囲を把握するのにはSQL文で多数のジョインを繰り返していかなければなりません。

お客様からは、この遅さを改善したいという強い要望がありました。そこでたどりついたのがグラフデータベースのNeo4jでした」(杉本氏)

「Neo4j」の高速性とシンプルに記述できるクエリがメリット

Neo4jのメリットは大きく2つあったと、杉本氏は説明します。1つは、今回の目的に対して非常に高い性能を発揮したことです。

fig

杉本氏のチームはベンチマークとして、「1250万件のデータに対して、起点となるビルのみを指定し、そのビルに収容されている2万のネットワークおよびそのネットワークを収容する設備情報を抽出する」という処理にかかる時間を、リレーショナルデータベースのPostgreSQLとグラフデータベースのNeo4jで比較しました。

結果、PostgreSQLではこの処理に80分51秒かかったのに対し、Neo4jではわずか20秒という圧倒的な処理時間の違いが見られ、今回の目的に対してNeo4jが高い性能を発揮できることが検証されました。本番運用時にもこれと同等程度の性能が発揮できています。

2つ目は、問い合わせ文がシンプルになる点です。

SQLでは前述の通り、あるデータに関連するデータを抽出するにはテーブルのジョインが必要となり、これを広範囲に行う場合には多数のジョインをSQL文として記述することになります。このためSQL文は複雑になりバグが入り込みやすくなると杉本氏。

一方、グラフデータベースにはSQLのような標準的なクエリ言語はなく、実装ごとに異なるクエリ言語が用意されています。Neo4jでは「Cypher」と呼ばれるクエリ言語が用意されており、あるデータともう1つのデータを指定すれば自動的にその2つをたどるすべてのデータを抽出してくれるというシンプルな構文を備えています。

Cypherによってクエリの記述がシンプルになり、バグが入り込む余地も小さくなったと杉本氏。

グラフデータベースには無限の可能性を感じている

杉本氏は、「大量のデータから、ある条件に合致するデータを抽出する場合はリレーショナルデータベースの方が高速です。そこを起点に、関連するデータを全部たどっていくという処理はグラフデータベースのNeo4jの方が速い。私たちが開発した新システムは、この2つをうまく組み合わせることでお客様の要望に応えることができるようになりました」と話します。

また、Neo4jを日本国内で扱っているクリエーションラインの李氏は、「Neo4jはレプリケーションやクラスタなどの機能によるディザスタリカバリ対応や複数ノードによるスケーラビリティを実現することができるなど、データベースとしての充実した基本機能を備えています。今後も更なる機能拡張が行われていく予定です」と説明します。

figクリエーションライン株式会社 Data Engineering Team Senior Architect 李 昌桓(Lee Changhwan)氏

そのうえで李氏は「かつてリレーショナルデータベースではリレーションはどこにでもある、『Relations are everywhere」と言っていました。同じように、ネットワーク状のデータもどこにでもある『Graphs are everywhere』といえます」と、グラフデータベースはさまざまな用途に使える可能性があると訴えます。

これには杉本氏も、「これまでデータベースといえば、ほぼリレーショナルデータベース一択でした。しかしこれからは扱うデータの性質、利用用途により、NoSQLのデータベースも選択肢に入れることが必要だと考えています。

なかでもグラフデータベースには無限の可能性を感じています。日本ではまだ黎明期だと考えていますが、この可能性を現実のものとして広げて行きたい」と、グラフデータベースへの期待とともに、今後も活用を続けていくと話しました。

Neo4j - クリエーションライン株式会社
Neo4j導入事例 - NTTコムウェア株式会社様

fig

(本記事はクリエーションライン提供のタイアップ記事です)

このエントリーをはてなブックマークに追加
follow us in feedly




カテゴリ

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed


最新記事10本