db tech showcase

dbtsブログ

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

【dbts2024 レポート】グラフDB: 新たな時代の幕開け モデルグラフDB truncus graph 〜 RDBMSからの脱却 〜

データ分析 データ管理
【dbts2024 レポート】グラフDB: 新たな時代の幕開け モデルグラフDB truncus graph 〜 RDBMSからの脱却 〜

こんにちは、プロダクト開発本部の小堺です。
db tech showcase 2024 1日目のC2のセッションである「グラフDB: 新たな時代の幕開け モデルグラフDB truncus graph 〜 RDBMSからの脱却 〜」のレポートをお届けします。

セッション概要

データベースといえばRDB。データは属性の集まりをカラム列としてテーブルに格納。それが当たり前と思っていませんか。

同じことはグラフDBでも可能です。グラフDBはエンティティの関連を直接に扱えるので、たとえばホワイトボードに描いた概念モデルを自然にシステムに落としこむことができます。さらに弊社製品の trunus graph のようにスキーマもサポートしたグラフDBであれば、ER図で表現される属性や関係をそのまま実装することも可能です。

グラフDBは、不正検知などのニッチなユースケースが取り上げられることが多いですが、実際は汎用的なDBとして一般的なアプリケーション開発に用いることができるのです。

本セッションでは、従来RDBで作られてきた簡単なアプリを例にとって、RDBとグラフDBを対比する形でアプリが扱うデータのモデリングを行い、データをグラフDBに自然な形で格納して操作できることを示します。

スピーカー名:株式会社Jurabi


研究開発部
システムアナリスト
森下 卓哉 様

研究開発部
技術顧問
岡 俊行 様

研究開発部
アーキテクト
鍬田 力 様

はじめに

皆さんはグラフDBというものをご存知でしょうか?おそらくdb tech showcaseに来場されるような方々は「当然だろう」とお答えになると思います。ちなみに自分は「よくわかりません」と答える少数派になります。
グラフ構造を備えたデータベース?ノード間の関係性を表現できる?なるほど、まあわかるようなわからんような。そのようにRDBしか触ってこなかった私は、「RDBMSからの脱却」と言われてもピンと来なかった訳ですね。
本セッションはそんな私のような人間にグラフDBの、延いてはtruncus graphの魅力を教えてくれました。

ER図はいらない⁉

なんでもtruncus graphならば概念モデルをそのまま実装できるので、ER図なんていらないのだとか!
通常RDBを設計する際のモデル定義では概念モデルを洗練させながらER図に起こしていきます。しかしながら概念モデルがそのままER図になる訳ではないため、両者の目的や表現方法の差異によってこの段階で既にギャップが生じてしまっていることも多いでしょう。例えば住所という値オブジェクトを複数のカラムで表現することがあったり、多対多関係を解消して中間テーブルを導入したりする必要があるためです。
truncus graphならば、オブジェクト指向プログラミングにおけるクラスのように(ドメインモデルというらしい)、概念モデルをそのままの形で実装することができるため、面倒な工程を省略することができます。また実際にオブジェクト間の関連を辿る際も、複雑になりがちなJOINなどではなく、メソッドで書いて辿ることが可能であり、逆に関連先から元に向かって辿ることもできるそうです。

グラフDBも汎用DBとして使える!

セッション内では、簡易的なショッピングサイトの実装を例にして、RDBとグラフDBでの実装の違いを比較していました。RDBでは顧客情報の関連を辿るためにJOINのネストを用いることでN+1問題を回避していました。JOINを用いているのでインデックス次第で実行速度が早くなりますが、どうしてもSQLが複雑になってしまうことは否めません。一方のtruncus graphの場合はグラフDBであることもあり、各オブジェクトをグラフで管理しているため関連を簡単かつ効率的に取得できます。実装画面の内容はクラスとメソッドの定義そのものといった形であり、プログラマーである私としても扱いやすく感じました。

余計な複雑性は取っ払おう

セッション内で特に強調して話されていたのは、「対象業務の複雑性に集中できるように」という言葉でした。なるほどたしかに、概念モデルを時間をかけてER図に直さなくとも、概念モデルの構成そのままをデータベースとして実装することが出来れば、より重要な部分に注力する余裕が生まれます。「RDBの採用はライブラリやプラットフォームなどに起因する余計な複雑性を持ち込んでいる」とも言っており、だからこそ対象業務の複雑性に集中するためにグラフDBを、truncus graphをデータベースとして採用していってほしい。といった熱い思いがヒシヒシと伝わってきました。

まとめ

  1. truncus graph ならば概念モデルを書くだけで良く、ER図はいらない
  2. グラフDBをRDBの代わりにデータベースとして使用できる
  3. truncus graphを用いることで余計な複雑性を除き、より本質的な業務に注力できる

聴講した感想

このセッションでtruncus graphは概念モデルそのままを実装できたり、メソッドで記述して関連を辿れるなど、非常に便利なデータベースだとわかりました。簡単なショッピングサイトの実装を例にして、グラフDBの良いところや、実際の使用感を知ることができた点が非常に良かったです。しかしながら、本当に大事なのはグラフDBを採用することそのものではなく、それによって本当に注力すべき業務に集中できるという点になります。そのためにも「使い慣れているのだからRDBで良い」と思考停止することなく、グラフDBも含めて検討してみることが大切だと思います。RDBとの違いはともかく従来の?グラフDBとtruncus graphの違いが分かりづらかったところもありましたが、今まで何となくでしか知らなかったグラフDBについての理解が深まったことで、これまでRDB一択だった自分にグラフDBはどうだろうか?と考える選択肢ができました。

一覧に戻る