SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

オラクル技術エキスパートが紹介する 開発者のためのデータベース完全ガイド

グラフ・データベースとは何か? なぜあまり使われてこなかったのか、そしてその展望とは

オラクル技術エキスパートが紹介する 開発者のためのデータベース完全ガイド 第9回

  • X ポスト
  • このエントリーをはてなブックマークに追加

 この連載では、開発者の皆様がシステム・アーキテクチャやアプリケーション・コードをより洗練させるのに役立つデータベース・マネジメント・システム(DBMS)の基本を振り返り、実装に合った技術の組み合わせを解説します。今回は、表やJSONとも異なるデータモデルとして注目されているグラフに着目し、その特徴とユースケース、DBMSにおける扱い方を議論します。

  • X ポスト
  • このエントリーをはてなブックマークに追加

はじめに

 この連載は、第1回に紹介したDBMSの3階層構造における「アーキテクチャと実装」についての技術の紹介から始まり、前回は中間の階層である「データ・モデルとデータ型」を起点にJSONをDBMSで扱う方法を議論しました。今回は、JSONと同様、表以外のデータモデルのひとつとして語られることの多いグラフを題材に、DBMSの3階層構造によるインターフェイスと実装の分離という指針がどのように適用できるか考えてみます。前回までの連載をまだお読みでない方は、第1回をご一読いただくことで今回の議論がわかりやすくなるかと思います。

 なお、本連載で例として挙げるデータベースはオラクルが提供しているものが多いですが、オラクル製品を使っていない方にも参考にしていただけるように解説します。

対象読者

 この連載では以下の読者を想定しています。

  • データ資産を活用する、新しいアプリケーションの構想や設計を担われる方
  • データ基盤の運用を担われている方や、今後検討される方
  • 新たに開発するアプリケーションの、最適なデータベースをお探しの方
  • 目的別データベースから、価値ある情報を素早く引き出す検討をされている方

グラフというデータモデルの特徴を再考する

 グラフ・データベースと呼ばれるDBMS(これを正確に表現するため以降では「グラフDBMS」と表記することにします)は10年以上前から市場に存在しており、今では多くの開発者がその概要、たとえばグラフという直感的なモデルや「辿る」処理の性能メリット、について見聞きしたことがあるかと思います。その一方で、実際のシステム、とりわけ可用性や安定性が求められるビジネス・クリティカルなシステムでグラフDBMSが採用されている例は今のところ非常に稀です。

 これはなぜでしょうか。グラフというデータモデルはDBMSで扱うビジネス価値がないのでしょうか。または、長らく注目されているグラフのユースケース(金融の不正検知、製造のトレーサビリティ分析、犯罪や税の不正の調査など)には障壁があるのでしょうか。これらの疑問について、特定のグラフDBMSの実装に関する議論にならないよう、まずはグラフというデータモデルについてその特徴を再考してみます。

グラフというデータモデル

 グラフDBMSが扱うデータモデルには、一般にRDF(Resource Description Framework)とプロパティ・グラフの2種類があります。これらはどちらもグラフと呼ばれることがある一方で、データモデルが異なるだけでなく、APIも実装も異なっていることが多く、同時に議論することが難しいです。そこで、今回はプロパティ・グラフのみに着目することにして、多少正確さには欠けますが、これを「グラフ」と呼ぶことにします。

 例えばOracle Graph(Oracle Databaseの一機能)やAmazon Neptuneは上記2種類のグラフの両方を扱うために、それぞれに対する別々の実装を持っています。

 グラフは以下の図にあるようにノードとエッジに加えてそれぞれのプロパティ(Key-Valueペア)で構成されていて、グラフを利用した通常のモデリング手法では、ノードがエンティティ(=物や人など、一意の対象物としてみなされるもの)、エッジがエンティティ間の関係性を表現するように割り当てます。ノードが「自分の情報」のみを持っているのに対して、エッジは始点と終点の情報(ノードID)も持っているという構造の違いがあるわけです。

グラフというデータモデル
グラフというデータモデル

表とグラフとの違い

 それでは、表を用いたモデル(=リレーショナルモデル)と対比してみます。ひとつのノードとそのプロパティについては、次の図のperson表やdog表のように、表の一行に格納できることは容易に理解できます。ではエッジはどうなるかというと、実はこれもリレーショナルモデルでは表に格納されることになります。そうすることで、次の図のhas_dog表のように1対多(さらに多対多)の関係が表現できます。このように、リレーショナルモデルではエンティティも関係性も表に格納しているのに対して、グラフモデルではノードとエッジという2種類の構造を使い分けることで、より直感的なモデリングを可能にしていることがわかります。

表とグラフの違い
表とグラフの違い

会員登録無料すると、続きをお読みいただけます

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

次のページ
グラフDBMSとは

この記事は参考になりましたか?

  • X ポスト
  • このエントリーをはてなブックマークに追加
オラクル技術エキスパートが紹介する 開発者のためのデータベース完全ガイド連載記事一覧

もっと読む

この記事の著者

山中 遼太(日本オラクル株式会社)(ヤマナカ リョウタ)

 Oracle Database開発部門のプロダクトマネージャー。主にAPAC地域のユーザーとともにグラフ機能と地理空間機能の先進的な活用に取り組んでいる。 Qiita

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

  • X ポスト
  • このエントリーをはてなブックマークに追加
CodeZine(コードジン)
https://codezine.jp/article/detail/16539 2022/09/29 11:00

おすすめ

アクセスランキング

アクセスランキング

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング