データ管理こんにちは、プロダクト開発本部の小堺です。〜」のレポートをお届けします。セッション概要データベースといえばRDB。データは属性の集まりをカラム列としてテーブルに格納。それが当たり前と思っていませんか。同じことはグラフDBでも可能です。グラフDBはエンティティの関連を直接に扱えるので、たとえばホワイトボードに描いた概念モデルを自然にシステムに落としこむことができます。ようにスキーマもサポートしたグラフDBであれば、ER図で表現される属性や関係をそのまま実装することも可能です。グラフDBは、不正検知などのニッチなユースケースが取り上げられることが多いですが、実際は汎用的なDBとして一般的なアプリケーション開発に用いることができるのです。本セッションでは、従来RDBで作られてきた簡単なアプリを例にとって、RDBとグラフDBを対比する形でアプリが扱うデータのモデリングを行い、データをグラフDBに自然な形で格納して操作できることを示します。showcaseに来場されるような方々は「当然だろう」とお答えになると思います。ちなみに自分は「よくわかりません」と答える少数派になります。グラフ構造を備えたデータベース?ノード間の関係性を表現できる?なるほど、まあわかるようなわからんような。そのようにRDBしか触ってこなかった私は、「RDBMSからの脱却」と言われてもピンと来なかった訳ですね。graphの魅力を教えてくれました。graphならば概念モデルをそのまま実装できるので、ER図なんていらないのだとか!通常RDBを設計する際のモデル定義では概念モデルを洗練させながらER図に起こしていきます。概念モデルがそのままER図になる訳ではないため、両者の目的や表現方法の差異によってこの段階で既にギャップが生じてしまっていることも多いでしょう。住所という値オブジェクトを複数のカラムで表現することがあったり、多対多関係を解消して中間テーブルを導入したりする必要があるためです。graphならば、オブジェクト指向プログラミングにおけるクラスのように(ドメインモデルというらしい)、概念モデルをそのままの形で実装することができるため、面倒な工程を省略することができます。実際にオブジェクト間の関連を辿る際も、複雑になりがちなJOINなどではなく、メソッドで書いて辿ることが可能であり、逆に関連先から元に向かって辿ることもできるそうです。グラフDBも汎用DBとして使える!セッション内では、簡易的なショッピングサイトの実装を例にして、RDBとグラフDBでの実装の違いを比較していました。RDBでは顧客情報の関連を辿るためにJOINのネストを用いることでN+1問題を回避していました。JOINを用いているのでインデックス次第で実行速度が早くなりますが、どうしてもSQLが複雑になってしまうことは否めません。graphの場合はグラフDBであることもあり、各オブジェクトをグラフで管理しているため関連を簡単かつ効率的に取得できます。実装画面の内容はクラスとメソッドの定義そのものといった形であり、プログラマーである私としても扱いやすく感じました。余計な複雑性は取っ払おうセッション内で特に強調して話されていたのは、「対象業務の複雑性に集中できるように」という言葉でした。たしかに、概念モデルを時間をかけてER図に直さなくとも、概念モデルの構成そのままをデータベースとして実装することが出来れば、より重要な部分に注力する余裕が生まれます。graphをデータベースとして採用していってほしい。いった熱い思いがヒシヒシと伝わってきました。graphは概念モデルそのままを実装できたり、メソッドで記述して関連を辿れるなど、非常に便利なデータベースだとわかりました。簡単なショッピングサイトの実装を例にして、グラフDBの良いところや、実際の使用感を知ることができた点が非常に良かったです。本当に大事なのはグラフDBを採用することそのものではなく、それによって本当に注力すべき業務に集中できるという点になります。そのためにも「使い慣れているのだからRDBで良い」と思考停止することなく、グラフDBも含めて検討してみることが大切だと思います。graphの違いが分かりづらかったところもありましたが、今まで何となくでしか知らなかったグラフDBについての理解が深まったことで、これまでRDB一択だった自分にグラフDBはどうだろうか?と考える選択肢ができました。