イベントストアの各集約の最新バージョンのスナップショットを保持

Question

現在、SQLバックアップされたイベントストア（一般的な2テーブル実装）を使用しています。チーム内の一部の人々は、イベントストアを書き込み専用に使用すると、状況が少し遅くなる可能性があるため、ここでスナップショットを追加する代わりに、各アグリゲートの完全な整合性のある（イベントストリームの）スナップショットを実際に維持するための提案が行われましたJSON形式の最新の状態です。システム上のすべてのクエリは、ES（書き込み）側から最終的な整合性の方法で更新される典型的なSQLデータベースを使用して、読み取り側で実行されます。

このようなシステムを設置することで、パフォーマンスストアの問題をすべて取り除きつつ、イベントストアを利用するメリットを享受することができます。私たちは現在、「時間旅行」の機能を利用していませんが、遅かれ早かれそのようになるでしょう。

これは良いアプローチですか？私の中には不快なものがあります。たとえば、ある種の時間移動機能が必要な場合、各集約のイベントストリームにスナップショットを配置しないとパフォーマンスが低下することがあります。もちろん、集約インスタンスごとの最新のスナップショットと、イベントストリーム全体のスナップショットの両方を持つことができます。

このルートを終了する場合は、特定の集約のスナップショット更新を、同じ集約のイベント更新に対してトランザクションにするか、イベントを更新するだけで最終的に一貫性のある方法で更新する必要がありますスナップショット？

このアプローチの弱点は何ですか？誰かが種類の何かを試したことがありますか？

Answer 1

不要な複雑さをシステムに追加する前に、独自のベンチマークを実行してください。イベントストリームから集計を再構築するために何千ものイベントを照会して適用する必要がある場合、JSONからオブジェクトの直列化に至るまでのパフォーマンス上のボトルネックが発生した場合、パフォーマンス上の問題が発生しています。集計ごとにわずかなイベントしかない場合（例：< 100）、実際には大きな違いは見られません。

ほとんどのイベントストアは、nイベント/コミットごとにスナップショットを記録し、50-100イベントごとに最新のスナップショットをクエリし、最後のスナップショット以降に欠落したイベントを適用します。スナップショットデータベースにすべての古いスナップショットを保存すると、移動時間の機能は通常のクエリと同じくらい速くなり、現在は安価な永続スペースがわずかに必要になります。

スナップショットは、最後のスナップショットがなくてもビジネストランザクションが失敗しないようにするために重要ではないため、元のトランザクションから常に書き出される必要があります（別のスレッドで生成することもできます）スナップショット書き込みトランザクションのエラーが原因です。

通常のシステムの稼働時間とデータサイズによっては、スナップショットをメモリや分散キャッシュ/グラッド、または別のデータベース（非SQL）に保持するのが有効かもしれません。