RDBの世界をぬりかえていくモデルグラフDB〜truncus graphによるモデルファースト開発〜

ビープラウド社主催の勉強会・BPStudy#205での発表資料となります。概念モデルとDB構造をシームレスに繋ぐ「モデルファースト開発」の説明とそれを実現するモデルグラフDB「truncus graph」の紹介です。以下内容です。

• グラフDBとは何か
• モデルグラフDB truncus graphとは？
• アーキテクチャ
• 事例
• truncus graphによるモデルファースト開発
• ベンチマーク
• GPTsによるモデル自動生成
• TO BE CONT'D …
• コアな話

Transcript

1. 株式会社Jurabi RDBの世界をぬりかえていくモデルグラフDB truncus graphによるモデルファースト開発 2024年9月30日 株式会社JURABI
2. モデルグラフDB truncus graphは グラフDBとしての選択肢だけでなく データベースの選択肢である
3. 会社紹介 3 テクノロジーカンパニー ⚫ 自然言語処理、情報検索、機械学習のエ キスパートチーム ⚫ モデルグラフDB truncus graphを開発 現実社会を表象するシステム開発をする ⚫ 社会やビジネスをモデル化しそれをシス テムで表象 ⚫ 変化に強いシステム開発 ⚫ 社会のつながり(関係)を表現する 常に最先端技術を追求する ⚫ 科学技術に目を向け、現実社会を紐ほど く チ ンジによる技術 truncus graph 2010 グラフ 構想 初期 2012 2018 中期
4. 発表内容 • グラフDBとは何か • モデルグラフDB truncus graphとは？ • アーキテクチ • 事例 • truncus graphによるモデルファースト開発 • ベンチマーク • TO BE CONT’D … • コアな話
5. 発表内容 • グラフDBとは何か • モデルグラフDB truncus graphとは？ • アーキテクチ • 事例 • truncus graphによるモデルファースト開発 • ベンチマーク • TO BE CONT’D … • コアな話
6. グラフDBとは何か(1/2) • データ要素をノードとして、その 関連性をエッジとして表現する データベースシステム。 • 関連性の強調： ノード のエッ ジにより、関連性が直接的に表現 される。 • 柔軟性： 新しいデータや関連性 の追加が容易。 • パフォーマンス： 大量の接続 データを効率的に扱う。 表形式 グラフ
7. グラフDBとは何か(1/2) • 一般的なプラットフォーム • Neo4j • ArrangoDB • Amazon Neptune • etc • 従来の用途 • ソーシャルネットワーキング、レコメンドシステム、不正 知、ネット ワーク管 、MDM
8. 発表内容 • グラフDBとは何か • モデルグラフDB truncus graphとは？ • アーキテクチ • 事例 • truncus graphによるモデルファースト開発 • ベンチマーク • TO BE CONT’D … • コアな話
9. テスラ車の購入サイトを作るとしたら • あなたはRDBからスタートしますか？ • テーブルありきでアプリの設計をしていませんか？ • ER図を描いてSQLでがんばっていますか？ • ORマッパーを使うこともありますか？ • でも使いづらくありませんか？
10. テスラ車の購入サイトを作るとしたら • あなたはRDBからスタートしますか？ • テーブルありきでアプリの設計をしていませんか？ • ER図を描いてSQLでがんばっていますか？ • ORマッパーを使うこともありますか？ • でも使いづらくありませんか？ 私たちはどれも使いません 私たちが使うのは、グラフDBの進化形である モデルグラフDB truncus graph です。
11. なぜモデルグラフDB "truncus graph"？ RDBではなくモデルグラフDBを使う理由： • アプリケーション開発の重要項目=モデリング • 私たちはモデルファーストの立場 • モデリング結果をできるだけそのまま扱いたい！
12. なぜモデルグラフDB "truncus graph"？ しかし一般的なグラフDBには難点がある： • スキーマ スで型の制約がない • グラフとアプリケーション型のマッパーが必要になる
13. なぜモデルグラフDB "truncus graph"？ しかし一般的なグラフDBには難点がある： • スキーマ スで型の制約がない • グラフとアプリケーション型のマッパーが必要になる ⇒モデリングに特化した モデルグラフDB “truncus graph” で克服！
14. モデルグラフDB truncus graph とは ? • スキーマをサポートしたグラフDB • モデルを書くだけでOK ⇒ ER図不要！ • モデルとストアが直結、自然かつ効率的につながる ⇒ ORM/OGMなどは不要、InProcess • エンティティ の関連はすべてインデックス付けされている
15. 発表内容 • グラフDBとは何か • モデルグラフDB truncus graphとは？ • アーキテクチ • 事例 • truncus graphによるモデルファースト開発 • ベンチマーク • TO BE CONT’D … • コアな話
16. truncus graphのアーキテクチ イヤードアーキテクチ
17. 例) truncus graphで作ったECアプリの構 Usecase層(Application層) Domain層 例) truncus graphで作ったECアプリの構 Domain Model Domain Service Usecacse(更新系) Usecase Model Usecacse(読込系) イヤードアーキテクチ
18. 発表内容 • グラフDBとは何か • モデルグラフDB truncus graphとは？ • アーキテクチ • 事例 • truncus graphによるモデルファースト開発 • ベンチマーク • TO BE CONT’D … • コアな話
19. 事例 大手出版社の サービスで利用する コンテンツデータベースと意味 プラントエンジニアリングDXに向けた 統合BOMとデータAPI基盤 プラント 部品 部品 部品 部品 部品 部品 部品
20. 発表内容 • グラフDBとは何か • モデルグラフDB truncus graphとは？ • アーキテクチ • 事例 • truncus graphによるモデルファースト開発 • ベンチマーク • TO BE CONT’D … • コアな話
21. truncus graphによるモデルファースト開発 お題: 簡易的なショッピングサイトを作 • モデル定義 • RDB • truncus graph • サービス実装 • RDB • truncus graph 顧客、注文、注文明細、商品 ある顧客の買った商品の一覧を取得するサービス
22. 概念モデル ホワイトボード に書いてみた • 丸はエンティティ • 四角は値オブジェクト • 「住所」も値オブジェクト ・郵便番号 ・都道府県 ・市区町村 …
23. truncus graphによるモデルファースト開発 お題: 簡易的なショッピングサイトを作 • モデル定義 • RDB • truncus graph • サービス実装 • RDB • truncus graph 顧客、注文、注文明細、商品
24. RDBのモデリング手順 • 概念モデルに対してテーブルを設計する • この 、多重度などを考慮したER図を 作 する事が多い • この段階でギ ップが生じることがある
25. 値オブジェクトの埋め込み：複数カラム展開
26. 値オブジェクトのList：別テーブルとの関連
27. 概念モデル⇔テーブル定義のギ ップ • 概念モデルがそのままER図になるわけではない • 階層構造をもったオブジェクトの表現 • 値オブジェクトへの一対多の対応 • 多対多の関連の場合、中 テーブルが必要 • O/Rマッパーでギ ップを埋められるか？ • O/Rマッパーを用いたモデル定義をする事も多い • 概念モデルをある程度そのまま反映可能な事もある
28. O/Rマッパー（JPA）を使ったモデル定義例 @Entity @Table(name = “orders”) public class Order { @Id private Long id; @Embedded private Address shippingAdress;//配送先住所 @OneToMany(mappedBy = "orders") private List<OrderDetail> orderDetails; @ManyToOne private Customer customer; } @Entity public class Customer { @Id private Long id; private String name; @Embedded private Address address; // 現住所 @OneToMany @JoinColumn(mappedBy = "customer") private List<Order> orders; } 住所はモデル通りに表現 注文明細はリスト として表現
29. truncus graphによるモデルファースト開発 お題: 簡易的なショッピングサイトを作 • モデル定義 • RDB • truncus graph • サービス実装 • RDB • truncus graph 顧客、注文、注文明細、商品
30. truncus graph でのモデル定義 // 注文 public interface Order extends Entity { Relation<Customer> customer(); Attribute<Address> shippingAddress(); Sequence<Attribute<OrderDetail>> orderDetails(); } // 顧客 public interface Customer extends Entity { Attribute<String> name(); Attribute<Address> address(); } ① ② ③ ④ ⑤ 概念モデルをそのままの形で実装できる（ER図不要！） ① ② ③ ④ ⑤
31. 関連先（注文→顧客）の取得 var customer = order.customer().target(); 関連元（顧客→注文）の取得 var orders = customer.getReverseRelation(Order.class, ”customer”); truncus graph でのモデル定義 逆関連 ① ① ② ②
32. truncus graphによるモデルファースト開発 お題: 簡易的なショッピングサイトを作 • モデル定義 • RDB • truncus graph • サービス実装 • RDB • truncus graph ある顧客の買った商品の一覧を取得するサービス
33. N+1問題：注文×注文明細分のSQLが発行される // 顧客の注文(orders)を取得 List<Order> orders = orderRepository.findByCustomerID(customerId); // 注文(orders)の数分、クエリ発行 return orders.stream() .flatMap(order -> order.getOrderDetails().stream()) .map(od -> { // 注文明細(OrderDetails)の数分、クエリ発行 Product product = productRepository.findById( od.getProduct().getProductID()); return new PurchasedProductResponse(...); }).collect(Collectors.toList()); ある顧客が購入した商品と数量の一覧 直観的だが発行されるクエリの回数 を制御できない ループによる単純な実装例:
34. N+1問題：JOINのネストでN+1問題を回避 @Query("SELECT new ec.app.api.PurchasedProductResponse( od.product.productId, od.quantity, od.purchasePrice, p.productName) " + "FROM OrderDetail od " + "JOIN od.orders o " + "JOIN Product p ON od.product.productId = p.productId " + "WHERE o.customer.customerId = :customerId") List<PurchasedProductResponse> findPurchasedProductsByCustomerId( @Param("customerId") String customerId); • JOINを用いているのでインデックス次第 で速くなる • SQLライクではあるがJPQLの知識が必要 • SQLも書けるが抽象化は破れる ある顧客が購入した商品と数量の一覧 JPQLでメソッドを定義する例:
35. truncus graphによるモデルファースト開発 お題: 簡易的なショッピングサイトを作 • モデル定義 • RDB • truncus graph • サービス実装 • RDB • truncus graph ある顧客の買った商品の一覧を取得するサービス
36. truncus graphでのサービス実装 var customer = repository.get(customerId, Customer.class); var orders = customer.getReverseRelation(Order.class, "customer"); orders.forEach((id, rel) -> { var order = rel.target(); order.orderDetail().forEach(attr -> { var orderDetail = attr.value(); var product = orderDetail.product().target(); ... }); }); ①IDをキーにして顧客を取得 ① ある顧客が購入した商品と数量の一覧
37. truncus graphでのサービス実装 var customer = repository.get(customerId, Customer.class); var orders = customer.getReverseRelation(Order.class, "customer"); orders.forEach((id, rel) -> { var order = rel.target(); order.orderDetail().forEach(attr -> { var orderDetail = attr.value(); var product = orderDetail.product().target(); ... }); }); 逆 関 連 ②注文→顧客の逆向きの関連を たどって注文を取得 ② ある顧客が購入した商品と数量の一覧
38. truncus graphでのサービス実装 var customer = repository.get(customerId, Customer.class); var orders = customer.getReverseRelation(Order.class, "customer"); orders.forEach((id, rel) -> { var order = rel.target(); order.orderDetail().forEach(attr -> { var orderDetail = attr.value(); var product = orderDetail.product().target(); ... }); }); ③注文に紐づく注文明細を取得する ③ ある顧客が購入した商品と数量の一覧
39. truncus graphでのサービス実装 var customer = repository.get(customerId, Customer.class); var orders = customer.getReverseRelation(Order.class, "customer"); orders.forEach((id, rel) -> { var order = rel.target(); order.orderDetail().forEach(attr -> { var orderDetail = attr.value(); var product = orderDetail.product().target(); ... }); }); ④注文明細→商品の関連をたどって 商品を取得する ④ ある顧客が購入した商品と数量の一覧
40. truncus graphでのサービス実装 var customer = repository.get(customerId, Customer.class); var orders = customer.getReverseRelation(Order.class, "customer"); orders.forEach((id, rel) -> { var order = rel.target(); order.orderDetail().forEach(attr -> { var orderDetail = attr.value(); var product = orderDetail.product().target(); ... }); }); グラフデータベースなので、関連を"簡単に効率的に"取得できる！ （JPAだと効率的にするための工夫が必要になる） クエリ不要！ ある顧客が購入した商品と数量の一覧
41. 発表内容 • グラフDBとは何か • モデルグラフDB truncus graphとは？ • アーキテクチ • 事例 • truncus graphによるモデルファースト開発 • ベンチマーク • TO BE CONT’D … • コアな話
42. ベンチマーク 1. 顧客の注文した商品の一覧を取得する （100顧客 ） 100万 10万 1億 2億 truncus graph RDB 5回の平均 12.02秒 47.6秒 チューニング前
43. ベンチマーク 100万 10万 1億 2億 truncus graph RDB 5回の平均 12.02秒 → 2.36秒 47.6秒 → 0.74秒 チューニング後 チューニング ・truncus graph: キャッシュサイズ変更 ・RDB: index作成、クエリ最適化、パラメータ変更 1. 顧客の注文した商品の一覧を取得する （100顧客 ）
44. ベンチマーク 100万 10万 1億 2億 truncus graph RDB 1回目 10.9秒 2.4秒 2〜5回目平均 0.21秒 0.33秒 5回の平均 2.36秒 0.74秒 チューニング後 チューニング ・truncus graph: キャッシュサイズ変更 ・RDB: index作成、クエリ最適化、パラメータ変更 1. 顧客の注文した商品の一覧を取得する （100顧客 ）
45. ベンチマーク 2. Wikidataの関連をたどって 「鳥山明」→「夏目漱石」の最短経路を探す 鳥山明 夏目漱石
46. ベンチマーク 2. Wikidataの関連をたどって 「鳥山明」→「夏目漱石」の最短経路を探す WITH RECURSIVE edge_path AS ( SELECT edge_id, src_id, tgt_id FROM wikidata WHERE src_id = '鳥山明のID' UNION ALL SELECT w.edge_id, w.src_id, w.tgt_id FROM wikidata w INNER JOIN edge_path ep ON ep.tgt_id = w.src_id ) SELECT edge_id FROM edge_path WHERE tgt_id = '夏目漱石のID'; RDBでのクエリ（1）：”WITH RECURSIVE”で再起的に探
47. ベンチマーク 2. Wikidataの関連をたどって 「鳥山明」→「夏目漱石」の最短経路を探す @Query(value = "SELECT * FROM wikidata w WHERE w.src_id IN (:srcIds)" , nativeQuery = true) List<Wikidata> findChainBySrcIds(@Param("srcIds") List<String> srcIds); RDBでのクエリ（2）：ホップごとにクエリを発行
48. ベンチマーク 2. Wikipediaのリンクをたどって 「鳥山明」→「夏目漱石」の最短経路を探す truncus graph RDB 平均 57.96秒 156.9秒 結果 [鳥山明] → [パラダイス文書] → [パンドラ文書] → [ペドロ・パブロ・クチンスキー] → [ジャン＝リュック・ゴダール] → [金獅子賞] → [黒澤明] → [羅生門] → [芥川龍之介] → [夏目漱石]
49. 発表内容 • グラフDBとは何か • モデルグラフDB truncus graphとは？ • アーキテクチ • 事例 • truncus graphによるモデルファースト開発 • ベンチマーク • TO BE CONT’D … • コアな話
50. TO BE CONT'D... • AIとの協調 • モデル・スキーマ・クエリ生 • モデルマーケットプ イス構想 • NewSQL的な並列書き込みクラスターの実装 • truncus graph as a Service • パフォーマンスの強化
51. GPTsによるモデルの生
53. GPTsによるモデルの生 生 されたモデル（抜粋） 生 されたクエリ static Stream<Order> findByCustomerName(GraphQueryExecutor queryExecutor, String customerName) { var result = queryExecutor.execute( "MATCH (c:`test:Customer`{name:'" + customerName + "'})- [:customer]->(o:`test:Order`) RETURN o"); return result.map(record -> { var de = (DomainEntity) record.get("o"); var entity = de.narrow(Order.class); return entity; }); }
54. 発表内容 • グラフDBとは何か • モデルグラフDB truncus graphとは？ • アーキテクチ • 事例 • truncus graphによるモデルファースト開発 • ベンチマーク • TO BE CONT’D … • コアな話
55. コアな話 truncus graphに至る背景 truncus graphの理論基盤： イフィケーションとProxy
56. truncus graphに至る背景(1) • 何故グラフDBに注目したか？ • 出版社の案件において、複雑なグラフネットワーク構造が必須となった。 • 文章をパラグラフ単位で分割、パラグラフ同士の関連やパラグラフのメタ情 報を管理・検索する。 • これに対応するにはグラフ構造が最適だった。
57. truncus graphに至る背景(2) • 開発においてモデリングを重視する方向性になっていた • 何故グラフDBとモデリングが結びつけられたか？ • オブジェクトのフィールド=プロパティグラフのノードにおけるプロパティ ではないのか？ • Neo4Jなどはプロパティに制限があるが、理屈の上では無制限で良いはず • 型付けができた方が整合性の観点で好ましい • エンティティからエンティティの参照はグラフのエッジでしかない
58. truncus graphに至る背景(3) • 我々が必要としていたものは何か？ • 実装言語とシーム スに繋がるグラフDB • 実装言語の型+DBスキーマ • グラフDBならではの関連の扱い（関連検索、逆関連など）
59. truncus graphの基盤となる理論・技術
60. truncus graphの理論基盤： イフィケーション • グラフに現れるのは具体的なデータであって型ではない。 • が、型情報もまたデータなので結局はグラフになる。 • 型の世界をデータの世界に引っ張り込む= イフィケーション。 • 何故これが必要なのか？ • モデルがグラフで表現できる事 • モデルが型で表現できる事 • これらを繋ぎ、型をグラフで表現できる
61. イフィケーションのイメージ(1) // 型の世界 type X { a: string; b: integer; c: boolean; y: Y; } type Y { p: string; q: integer; } type Z extends Y { r: boolean; } // データの世界 x = { : ”aaa” b: 0; c: true; y: y; } y: Y = { : ” 1”; q: 1; } z: Z = { : ” 2”; q: 2; r: true; }
62. イフィケーションのイメージ(2) // 型の世界 // あるいはソースの世界 type X { a: string; b: integer; c: boolean; y: Y; } type Y { p: string; q: integer; } type Z extends Y { r: boolean; } // データの世界(インスタンス) // あるいはランタイムの世界 x = { : ”aaa” b: 0; c: true; y: y; } y: Y = { : ” 1”; q: 1; } z: Z = { : ” 2”; q: 2; r: true; } // データの世界(型オブジェクト) // あるいはランタイムの世界 Type<X> = { a: Type<string> b: Type<integer>; c: Type<boolean>; y: Type<Y>; } Type<Y> = { p: Type<string>; q: Type<integer>; } Type<Z> = Type<Y> + { r: Type<boolean> }
63. イフィケーションのイメージ(3) Type<X> = { a: Type<string> b: Type<integer>; c: Type<boolean>; y: Type<Y>; } Type<Y> = { p: Type<string>; q: Type<string>; } Type<Z> = Type<Y> + { r: Type<boolean> } type X a: string; b: integer; c: boolean; type Y p: string; q: integer; type Z r: boolean; relation y extends
64. イフィケーションのイメージ(4) type X a: string; b: integer; c: boolean; type Y p: string; q: integer; relation y x0 : “aaa” b: 0 c: true y0 : “ 1” q: 1
65. イフィケーションのイメージ(5) 実装言語 truncus graph 一般的なグラフDB RDB 型=集合 型=集合 型なし、ノードはラ ベルやプロパティで 頑張って識別 テーブル=関係の 集合 プロパティの型は 由 プロパティの型は 由 プロパティの型に制 限あり 属性の型に制限 あり エンティティ=ノード エンティティ=ノード エンティティ=ノード エンティティ=述 値オブジェクト=プロパ ティ 値オブジェクト=プロパ ティ 値オブジェクト=プロ パティ、あるいは独 立したノード 値オブジェクト= 関係あるいは述 関連=写像(メソッド) 関連=型付けされたエッジ 関連=エッジ、ただし 厳密な型付けはない 関連=関係比較演 算子
66. イフィケーションとProxyによるデータ操作（1）
67. イフィケーションとProxyによるデータ操作（2） モデルの世界 GraphDBの世界 ランタイムの世界 interface Entity1 Entity2 Entity3 Node1 Node1 Node3 Proxy Proxy Proxy Proxy Proxy Proxy 3つの世界を繋ぐのが イフィケーションのアイディア RTTI
68. 続 コアな話 今回紹介しきれなかった ・truncus graphの中身 ・さまざまなベンチマーク ・… 後日、connpass上の弊社勉強会ページにて紹介します。 https://findout.connpass.com/
69. まとめ：対象業務の複雑性に集中するために • 私たちが注力すべきは対象業務が持つ「本質的な複雑性」 • ライブラリやプラットフォームなどに起因する複雑性ではない • RDBの採用は、まさに余計な複雑性を持ち込んでいる truncus graph で 本質的な複雑性に立ち向かおう
70. END モデルグラフDB truncus graphは グラフDBとしての選択肢だけでなく データベースの選択肢である
71. Thank you 株式会社JURABI