イベントをソースとするCQRS(Command Query Responsibility Segregation/コマンドクエリ責務分離)システムの開発において,リレーショナルデータベースへのイベントの保存と数値の順次増加によるグローバルにユニークなイベントIDの生成は,ある意味で極めて重要な決定になる – Kontad Garus氏は,自身が最近のプロジェクトで経験したことを,3つのブログ記事に著した。記事の中で氏は,一貫性の実現方法,イベントストリームを参照する読み込みモデル実装の方法,およびモデルで使用する永続性技術に注目している。
Garus氏はこのシステムについて,100ないし1,000のユーザによる企業内利用を目的とした,比較的小規模で非常にシンプルな実装だと説明している。スケーラビリティの面で制限はあるが,毎分数百程度のイベントは問題なく処理できるシステムだ。
シーケンシャルなイベントモデルを採用する場合の読み込みモデルは,最後に処理されたイベントを開始点として認識して,イベントストアを定期的にポーリングすることでアップデートできる。イベントのバッチをストアから読み込んだら,単一スレッドで順次処理していけばよいのだ。このモデルでは,読み込みモデル自身が状態管理の責務を持ち,インフラストラクチャやサーバ側への依存性が排除された形となる。
このモデルのメリットとしてGarus氏が指摘するのは,イベントが常に生成順に処理されることにより,数秒ないしそれ以上の遅延があった場合にも,常に読み込みモデルの一貫性が確保されるという点だ。最後に処理されたイベントのIDと現時点での最大値を比較すれば,処理遅延の程度を計算から知ることもできる。
さらにGarus氏は,このモデルが,クライアント側から見た結果整合性(eventually consistency)問題の軽減を可能にする点も指摘している。コマンドを実行して作成されてストアに書き込まれた最後のイベントIDを返せば,クライアントはこれを使って,同じイベントが処理された結果が反映されて,読み込みモデルが更新されるのを待つことができる。
Garus氏は,私たちがユーザの身近にある要件に対して,複雑過ぎるツールを使う傾向があると考えている。氏自身のプロジェクトでの経験から,CQRSを採用することによって,よりシンプルな実装で問題を解決できる場合もある,というのが氏の考えだ。
最初のブログ記事を発端としたRedditでの議論では,リレーショナルデータベースを利用することの価値は何か,理想のストリームは追加専用のイベントログのようなストリームだ,といった疑問が交わされている。リレーショナルモデルに代わるイベントソーシングのメリットとデメリットについても同じような議論がある。
Vaugh Vernon氏も2014年後半のブログ記事で,ACIDトランザクショナルやJSONをサポートするリレーショナルデータベースのPostgreSQLを,シリアライズされたDDD集約の格納手段として用いる方法を提案した。
今年初めにはVladimir Khorikov氏が,CQRSの3タイプを比較した記事を公開している。