17

イベント ソーシング アプリケーションのイベント ストアとして Cassandra を使用して実験したいと考えています。イベント ストアに対する私の要件は非常に単純です。イベント「スキーマ」は次のようになります。

  • id : 集約ルート エンティティの ID
  • data : シリアル化されたイベント データ (JSON など)
  • タイムスタンプ: イベントが発生したとき
  • sequence_number : イベントの一意のバージョン

私は Cassandra にまったく慣れていないので、これから書く内容について無知であることをお許しください。このデータに対して実行したいクエリは 2 つだけです。

  1. 特定の集約ルート ID のすべてのイベントを取得する
  2. シーケンス番号が > x の場合、特定の集約ルートのすべてのイベントを教えてください

私の考えは、次のように CQL で Cassandra テーブルを作成することです。

CREATE TABLE events (
  id uuid,
  seq_num int,
  data text,
  timestamp timestamp,
  PRIMARY KEY  (id, seq_num) );

これは、問題をモデル化するための賢明な方法のように思えますか? そして重要なのは、複合主キーを使用すると、指定したクエリを効率的に実行できるかどうかです。使用例によっては、同じ集約ルート ID に対して (seq_num が異なる) 多数のイベントが発生する可能性があることに注意してください。

私の具体的な懸念は、2番目のクエリが何らかの形で非効率になることです（ここではセカンダリインデックスについて考えています...）

4

6 に答える 6

2

私は非常によく似たシナリオ (行ごとに 10 万列以上) で Cassandra を使用してきましたが、あなたのモデルに近いモデルで終了しました。また、セカンダリ インデックスはおそらくあまり効果がないという emgsilva の意見にも同意します。

イベント ストアの良好なパフォーマンスにとって重要であることが判明した 3 つの点があります。複合列を使用すること、列が適切に並べ替えられるようにすること (Cassandra はデータを列ごとに行で並べ替える)、可能であればコンパクトなストレージを使用することです。

コンパクト ストレージとは、値列を 1 つしか持てないことを意味することに注意してください。したがって、他のすべての列をキーの一部にする必要があります。

あなたにとって、スキーマは次のようになります。

CREATE TABLE events (
    id uuid,
    seq_num int,
    timestamp timestamp,
    data text,
    PRIMARY KEY  (id, seq_num, timestamp))
    WITH COMPACT STORAGE;
于 2015-04-27T09:51:48.917 に答える
-6

柔軟性のために domainevent を保存する必要があります。eventdomain は、application.aggregateroot の状態を変更しても eventstore と一致しない最も細かいデータであり、データ交換または boundedcontext 用であると説明します。ドメインイベントを使用すると、plolygotモデリングを使用してaggregaterootでもデータを再構築できます.クライアントと制約の必要性に応じてモデルを管理できます.つまり、モデルを変更して便利な永続エンジンを使用する機会があるということです。これは、ポリゴット データとポリゴットの永続性の違いです。あなたの戦略では、私は2つの方法を理解しています: イベントソーシングが必要な場合は、domainevent と cassandra データベースをモデルにします。aggregateroot データまたはモデルが必要で、イベントソーシングが必要ない場合は、文書化されたデータベースを使用して、2 つのクエリを取得できます。

ドメイン駆動設計に関する混乱を解消する必要があります。

于 2015-03-05T11:21:42.580 に答える