【要約】読み取りと書き込みでモデルが別！？ - CQRS という概念 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者が、単一のデータモデルで読み書きの両方を処理しようとした際に、システムの成長に伴い深刻な課題に直面する。読み書きの要求が非対称であるため、一つのモデルでは最適化が困難になるからだ。
- ・大量の読み取りクエリが、書き込み処理のパフォーマンスを圧迫する。
- ・読み取り高速化のための非正規化が、書き込み時の更新コストを増大させる。
- ・量、形、変更頻度、鮮度の4軸において、要求が衝突する。
// Approach
開発者は、読み書きの非対称性を解消するために、責務を分離するCQRSを採用する。書き込み用のモデルと、読み取り専用のモデルを独立して設計・運用する手法である。
- ・書き込み（Command）は、状態を変更する操作に専念する。
- ・読み取り（Query）は、表示や集計に最適な非正規化モデルを用いる。
- ・「プロジェクション」により、書き込み時のイベントを読み取りモデルへ反映する。
- ・反映手法として、ストリーミング、バッチ、同期のいずれかを選択する。
// Result
CQRSを導入することで、システムは読み書きそれぞれの特性に最適化された状態を実現できる。これにより、スケーラビリティとパフォーマンスの向上が期待できる。
- ・書き込みモデルは、整合性を保ちながら正確な記録に集中できる。
- ・読み取りモデルは、JOINを排除した高速なデータ取得が可能になる。
- ・ただし、反映の遅延により「結果整合性」を受け入れる必要がある。
Senior Engineer Insight
> CQRSは強力だが、導入コストと複雑性が極めて高い。インデックス追加やリードレプリカ等の「軽い」手段で解決できない場合にのみ検討すべきだ。反映遅延によるUXへの影響を考慮し、技術だけでなくプロダクト設計レベルでの判断が求められる。安易な採用は過剰設計を招く。現場では、非対称性が顕在化するまで待つのが賢明である。