5

そのため、現在、EventStore の「パターン」とともに CQRS アーキテクチャを掘り下げています。

これにより、アプリケーションのスケーラビリティと柔軟性、およびテストの新しい次元が開かれます。

ただし、データ移行を適切に処理する方法にまだこだわっています。

具体的なユースケースは次のとおりです。

記事とコメントでブログを管理したいとしましょう。

書き込み側では MySQL を使用し、読み取り側では ElasticSearch を使用しています。コマンドを処理するたびに、書き込み側でデータを永続化し、イベントをディスパッチして読み取り側でデータを永続化します。

ArticleSummaryここで、id とタイトルを含むある種の ViewModel を呼び出したとします。

に記事タグを含めるための新しい機能のリクエストがArticleSummaryあります。モデルに辞書を追加して、タグを含めます。

タグが書き込みレイヤーに既に存在していた場合、新しく含まれたデータを適切に使用するには、新しい「テーブル」を更新または使用する必要があります。

すべてのイベントを再生してすべての ViewModel を「更新」する EventLog Replay 戦略を知っていますが、真剣に、何十億行もある場合に実行可能ですか?

実績のある戦略はありますか？フィードバックはありますか？

4

2 に答える 2

5

すべてのイベントを再生してすべての ViewModel を「更新」する EventLog Replay 戦略を知っていますが、真剣に、何十億行もある場合に実行可能ですか?

私は「はい」と言うでしょう:)

とにかくクエリ側を更新する新しい集計機能のハンドラーを作成します。だから、あなたはすでにコードを持っています。特別な 1 回限りの移行コードを作成しても、それほど多くは得られない場合があります。たとえば、一度データ変換が必要な新しいシステムの初期更新を行う必要がある場合は、移行コードを使用しますが、この場合、インフラストラクチャは存在します。

関連するイベントのみを新しいハンドラーに送信する必要があるため、すべてを再生する必要もありません。

いずれにせよ、10億行のデータがある場合、サーバーはおそらく負荷を処理できるでしょう:)

于 2013-09-11T04:34:53.863 に答える