J Oliver EventStore V2.0に関する質問

Question

私はCQRSを使用してプロジェクトを実装しており、J Oliver EventStore V2.0をイベントの永続エンジンとして使用するつもりです。

1）ドキュメントでは、ExampleUsage.csは "BuildSerializer"で3つのシリアライザを使用しています。これは、デシリアライゼーションプロセスの柔軟性を示すことに過ぎないと思いますか？

2）一部のイベントがディスパッチされなかった「失敗後の再起動」の場合、GetUndispatchedCommits（）を起動してからそれらをディスパッチするスタートアップコードが必要だと思いますか？

3） "ExampleUseage.cs"では、 "TakeSnapshot"がイベントストアに3番目のイベントを追加してから、 "LoadFromSnapShotForward"が最新のスナップショットを取得するだけでなく、スナップショットの投稿イベント集約の再構築をシミュレートします。

4）私は古いスナップショットを保持するのを見るのに失敗しています。あなたは便利なユースケースを教えてください。

5）コマンドの受け取りとイベントの生成を処理するサービスがある場合、特定の集約の最後のスナップショット以降のイベントの数を追跡するための推奨戦略は何ですか？私は確かに "GetStreamsToSnapshot"をあまりにも頻繁に呼びたくはありません。 SqlPersistence.SqlDialectsで

6）SQL文の名前を名前空間は "GetStreamsRequiringSnaphots" ではなく "GetStreamsRequiringSnapShots" である

Answer 1

1）があり、いくつかの "ベース" のシリアライザ - などのバイナリ、JSON、およびBSONなどシリアライザ。この例の他の2つ - GZip/CompressionおよびEncryptionシリアライザはシリアライザをラッピングしており、すでにシリアル化されているものをバイトストリームに変更することのみを目的としています。この例では、柔軟性を示しています。あなたがしたくない場合は、暗号化する必要はありません。実際、すべてがテキストなので、デバッグが非常に簡単になるシンプルなJSONを使用して、プロダクションを実行しているものがあります。

2）SynchronousDispatcherとAsychronousDispatcherの実装はどちらも、ディスパッチされていないコミットをクエリして検出するように設定されています。特別なことをする必要はありません。

3）Greg Youngはメインイベントストリームで彼のスナップショットをどのように「インライン」していたかについて話しましたが、ハイパフォーマンスシステムでは楽観的な並行性と競合状態がいくつかありました。彼はそれゆえ彼らを「バンド外」に動かすことに決めた。私は同じ理由の多くのためにこの決定に従った。

さらに、極端に低いSLAがある場合、スナップショットはパフォーマンス上の考慮事項になります。数千のイベントが発生したストリームがあり、SLAが低い場合は、システムに複雑さを追加するのではなく、パフォーマンスの低下を最小限に抑えるだけではいかがですか。つまり、スナップショットは「付随的」な概念です。彼らはEventStore APIに入っていますが、特定のユースケースで考慮する必要があるオプションの概念です。

4）数千万件のイベントが集計されていて、最新のスナップショットの前から「何か」シナリオを実行するとします。別のスナップショットから先に行くのはずっと安いです。セカンダリコンセプトのスナップショットについて本当にうれしいことは、古いスナップショットを削除したい場合、可能であれば、システムにまったく影響しないということです。

5）GetStreamsRequiringSnapshotsというIPersistStreamの各実装にメソッドがあります。たとえば、最後のスナップショット以降に50以上のイベントを持つすべてのストリームを検出する、しきい値を50に設定します。これは、通常の処理とは非同期で行うことができます（おそらくそうすべきです）。

6）「スナップショット」は、その単語の正しい文字列です。 「ウェブサイト」は「ウェブサイト」だったが、一般的な使用法のため「ウェブサイト」となった。