なぜ書き込みDBと 読み取りDBを分けるのか？

CQRS/ESアーキテクチャにおいて、「なぜ書き込みDBと読み取りDBを分けるのか？」という根本的な問いに答えるための解説資料です 。

本資料では、書き込みと読み取りのDBが依存している状態では、CQRS/ESの真のメリットを受けられないと解説しています 。書き込みDBは「イベント」を時系列に追記するだけのシンプルな構造にすることで高いスループットを維持します 。一方、読み取りDBは、そのイベントを「プロジェクティング」することで、ユースケースに最適化されたデータを柔軟に作成できます 。

この分離によって、「システムの完全な履歴追跡」「高トラフィックへの対応力」「柔軟なデータ表示」といった強力な利点がもたらされる仕組みを、図解を交えて分かりやすく説明します 。

Transcript

1. CQRS/ESはなぜ書き込みDBと 読み取りDBを分けるのか？ 鈴木まー　 イベントソーシング・CQRS勉強会 #3
2. 自己紹介 RailsWay を守りつつ DDD／モジュラーモノリス クリーンアーキテクチャを実践中 さらなる設計スキルアップとして CQRS／ES をフルスクラッチ で組みながら勉強中 鈴木まー マイブーム ChatGPTを使って９人の生成AI キャラクターを使って、ラノベ風 の物語のテキストとイラストを生 成している それをNoteBookLMで 深読み考察をしたを聞いている
3. 質問 CQRS/ESはクラスとかの ソースコードレベル で実装を意識していたら CQRS/ESのメリットを 受けることができるのか？
4. 自分の中の答え DBが書き込みDBと読み取りDBが依存し ているとCQRS/ESのもっているメリット はうけれないという考えを持っている あくまでも鈴木の場合は
5. このLTで伝えたいこと CQRS/ESにおいてなぜ 書き込みDBと読み込みDBを わけるとよいのか
6. DBが依存している場合の良くあるコード
7. 問題となってしまっているところ 書き込みDB 読み込みDB
8. 問題となってしまっているところ 書き込みDB シンプルさと再現性を もたせることができない 読み込みDB
9. 問題となってしまっているところ 書き込みDB シンプルさと再現性を もたせることができない 読み込みDB 拡張性が持ちづらく柔軟にできない
10. CQRS/ESの書き込みDBの特徴 “出来事” を追記するだけなので
 いつ・何が起きたかを 時系列で正確にさかのぼれる。
 追記だけのシンプル構造 なので従来のDB設計よりか 高トラフィックでも高スループットを保てる。
11. CQRS/ESの読み込みDBの特徴 画面やレポート用に “そのまま使える形” で保持 だから、ユースケースごとに 自由なリードモデルをいくつでも増やせる データは自己完結なので ほかのテーブルに依存しない
12. 書き込みDBと 読み込みDBが依存している とさきほどの メリットを受けられない
13. DBが依存していること の問題点の詳細例
14. DBが依存されている場合の良くあるコード
15. CQRS/ESがもつ3つのメリット 9 システムで実行した履歴をおえG 9 ハイトラフィックな書き込みへの対応がし やす` 9 ユースケースに特化した表示用データが簡 単に作成できる
16. p 追記のみのイベントの蓄積データなので 「いつ・誰が・何を」実行したかを残せ" p ログをリプレイすれば 当時の挙動をそのまま再 演 でき" p いつでも読み込みデータを作成でき" p （任意時点の Read Model を即生成） システムで実行した履歴をおえる 本来できること
17. H 状態を上書き保存する構造のため、イベントが 残らな H 「最新の状態だけが真実」という前提に縛ら れ、過去履歴は捨てられる システムで実行した履歴をおえる 受けられなくなってしまう理由
18. CQRS/ES なら、データが “どこで”“いつ”“どう” 変 わったかをイベントから即座に追跡できる システムで実行した履歴をおえる
19. CQRS/ES なら、データが “どこで”“いつ”“どう” 変 わったかをイベントから即座に追跡できる 依存をしていると、上書き保存の構造では変更箇所 が DB に残らず、あとから “ログを調べるしかない” （そもそも「ログが残っていれば」という運任せ） システムで実行した履歴をおえる
20. 本来の姿 ハイトラフィックな処理への対応がしやすい 書き込みDBは最小限のデータ追記だけで済むので、 高速に処理できる パフォーマンスを上げたいときは、書き込み用DBを 調整するだけで速くなる
21. U 書き込みと読み込みを同じテーブルで連続実行し ているから書き込み処理が遅くな% U 書き込み用と読み込み用が同じ DB にあるため、
 読み取り側の負荷も考えながらチューニングし ないといけない ハイトラフィックな処理への対応がしやすい しずらくなってしまう理由
22. 本来 (CQRS/ES) イベント追記のコードだけ 調整すれば OK ハイトラフィックな処理への対応がしやすい
23. 本来 (CQRS/ES) イベント追記のコードだけ 調整すれば OK 現状 (さっきのコード) イベント追記とは関係ないところが原因 で遅くなっている可能性があるので チューニングが難しい可能性もありえる ハイトラフィックな処理への対応がしやすい
24. 本来の姿 ユースケースに特化した表示用データが簡単に作成できる i ユースケースに合わせて、表示用データ（Read Model） を好きな形で作れる
 ─ 余計な JOIN や正規化を気にしないでいG i 画面を変えても UI が変わっても、コマンドをイベントに 書き込むロジックはそのまま ── 画面に引っ張られない 設計ができる

25. イベントが更新方式だと履歴が残らず、過去の流れ をたどって新しいRead Modelを再構築することがで きなくなる 読み取り用のテーブルを追加するたびに、書き込み DBのスキーマ変更が必要になり、影響範囲が広くて 気軽に増やせなくなる しずらくなってしまう理由 ユースケースに特化した表示用データが簡単に作成できる
26. 本来 (CQRS/ES) 必要になった段階で表示用のデータをシンプルに作れる ユースケースに特化した表示用データが簡単に作成できる
27. 本来 (CQRS/ES) 必要になった段階で表示用のデータをシンプルに作れる 現状 (さっきのコード) CQRS/ESの良さを活かせないで、 普通のDB設計になり事前にDBを作成 している必要があるテーブル同士が独立 していないので、たくさんの複雑なSQLを作成する 必要がある ユースケースに特化した表示用データが簡単に作成できる
28. どういう設計を するとよいのか
29. コマンドが実行されたのが確定してして イベントが発行されたときに 書き込みDBにイベントを追記する 書き込みDBをいつ書き込むか
30. コマンドが実行されたのが確定してして イベントが発行されたときに 書き込みDBにイベントを追記する 気をつけること 更新はしてはいけない イベントを書き込むだけを考えて 表示側のことは一切考えない 書き込みDBをいつ書き込むか
31. イベントが発行されたのをコマンド側から 受け取ってそれを プロジェクティングして、読み込みDBを更新する 読み込みDBのリードモデルは、 書き込みDBを参照して 必要になったタイミングで いつでも作成できる 読み込みDBをいつ書き込むか
32. イベントは何が起きたのかという 事実の記録 イベントは表示側の都合を 考えないで書き込みDBに追記する そのイベントを表示用に整形して、 読み込みDBに書き込む処理 プロジェクティングとは
33. コマンドを実行 イベント発行 書き込み用DBに追記 イベント 書き込みDB CQRS/ESのDBの流れ
34. コマンドを実行 イベント発行 書き込み用DBに追記 表示用データの取得 リード モデル イベント 書き込みDB プロジェクティング 読み込みDB CQRS/ESのDBの流れ
35. CQRS/ESのDB設計を 始めてみた人が思いそうなこと 回りくどくない？ なんで“イベント”を使うの？ DBが2つあるの？冗長じゃない？ わざわざ整形するって手間じゃない？ 複雑でうちの規模だと必要なさそう
36. DBを分けることに 複雑なシステムに対応することができる ハイトラフィックなサービス 業務向けサービスやSaaS などの複雑なサービス
37. CQRSESがもつ3つのメリット 8 システムで実行した履歴をおえF 8 ハイトラフィックな書き込みへの対応がし やすY 8 ユースケースに特化した表示用データが簡 単に作成できる
38. ご清聴ありがとう ございました