1. ホーム
  2. cqrs

[解決済み] RDBMSをイベントソーシングのストレージとして利用する

2022-07-16 07:10:03

質問

RDBMS (例: SQL Server) を使用してイベント ソーシング データを保存する場合、スキーマはどのようになりますか。

抽象的な意味でいくつかのバリエーションが語られているのを見たことがありますが、具体的なものはありません。

たとえば、1 つに "Product"エンティティがあり、その製品への変更は次のような形で来る可能性があるとします。価格、コスト、および説明です。私は、自分がそうするかどうかについて混乱しています。

  1. 製品のすべてのフィールドを持つ、quot;ProductEvent" テーブルがあり、各変更はそのテーブルの新しいレコードを意味し、さらに必要に応じて、quot;who、what、where、why、when および how" (WWWWWH) が追加されます。コスト、価格、または説明が変更されると、製品を表すためにまったく新しい行が追加されます。
  2. 製品のコスト、価格、説明を、Product テーブルに外部キー関係で結合された別のテーブルに格納します。これらのプロパティに変更が発生した場合、必要に応じてWWWWHで新しい行を書き込みます。
  3. WWWWWH とイベントを表すシリアライズされたオブジェクトを "ProductEvent"テーブルに格納します。つまり、与えられた Product のアプリケーション状態を再構築するために、イベント自体をアプリケーション コードにロード、シリアライズ解除、再プレイする必要があるのです。

特に、私は上記のオプション 2 について心配しています。極端な話、製品テーブルは 1 つのプロパティにつきほぼ 1 つのテーブルとなり、任意の製品のアプリケーション状態を読み込むには、各製品イベント テーブルからその製品のすべてのイベントを読み込む必要があります。このテーブルの爆発は、私には間違っているように思えます。

私は、何が許容され、何がまったく許容されないかについて、感触を得ようとしています。イベントは集約ルートに対して保存され、オブジェクトを再構築するためのイベントを取得するためにデータベースへの単一のリクエストのみを意味する、NoSQLがここで役立つことも知っています。

どのように解決するのですか?

イベントストアは、イベントの特定のフィールドまたはプロパティについて知る必要はありません。そうでなければ、モデルを変更するたびにデータベースを移行しなければならなくなります (昔ながらの状態ベースの永続性と同じです)。したがって、私はオプション1および2をまったくお勧めしません。

で使用されているスキーマは以下のとおりです。 Ncqrs . ご覧の通り、テーブル "Events" は CLOB (すなわち JSON または XML) として関連データを保存します。これは、あなたのオプション3(汎用的な "Events" テーブルが1つだけ必要なので、 "ProductEvents" テーブルがないことのみ)に相当します。Ncqrs では、Aggregate Roots へのマッピングは "EventSources" テーブルを通じて行われ、各 EventSource は実際の Aggregate Root に対応します)。

Table Events:
    Id [uniqueidentifier] NOT NULL,
    TimeStamp [datetime] NOT NULL,

    Name [varchar](max) NOT NULL,
    Version [varchar](max) NOT NULL,

    EventSourceId [uniqueidentifier] NOT NULL,
    Sequence [bigint], 

    Data [nvarchar](max) NOT NULL

Table EventSources:
    Id [uniqueidentifier] NOT NULL, 
    Type [nvarchar](255) NOT NULL, 
    Version [int] NOT NULL

のSQL永続化機構は Jonathan Oliver のイベントストア実装 は基本的に、BLOB フィールド "Payload" を持つ "Commits" という 1 つのテーブルで構成されています。これは Ncqrs とほとんど同じですが、イベントのプロパティをバイナリ形式でシリアライズしています (たとえば、暗号化のサポートが追加されています)。

Greg Young は、次のような同様のアプローチを推奨しています。 として、同様のアプローチを推奨しており、Greg の Web サイトで広範囲に文書化されています。 .

彼のプロトタイプのquot;Events"テーブルのスキーマは次のようになっています。

Table Events
    AggregateId [Guid],
    Data [Blob],
    SequenceNumber [Long],
    Version [Int]