リレーショナルデータからイベントへの移行

 (event-driven.io)
2 ポイント 投稿者 GN⁺ 2023-12-18 | 1件のコメント | WhatsAppで共有

リレーショナルデータからイベントへの移行ガイド

  • イベントソーシングの世界では、ビジネスデータを失わずにイベントとして保存する。
  • イベントは発生した事実を表し、各操作の後に保存される。
  • イベントストリームは記録されたすべてのイベントの一覧であり、不変で、過去のミスは新しいイベントを追加することで修正できる。

1. 状態カラムを見つける

  • 状態カラムの値は、データのライフサイクル段階を反映している可能性がある。
  • たとえば、注文は開始され、発送され、支払い済みになることがある。
  • これらの状態は、Order Initiated、Order Shipped、Order Paid のようなイベントに変換できる。

2. 日付カラムを確認する

  • 日付カラムは、プロセスにおける重要な出来事に関する情報を提供してくれることがある。
  • ShipmentDate、DeliveryDate、OrderPlacementDate などは、ビジネス用語を示し、新しいイベントを導入する助けになる可能性がある。

3. カラムの選択性を分析する

  • Nullable なカラムは、後から提供されるか、任意項目である可能性がある。
  • 必須カラムは、最初の Order Initiated イベントで提供されるべきである。

4. 1対多の関係が最も多いテーブルを探す

  • イベントソーシングでは、ビジネスプロセスを中心にデータをグループ化し、効率的な処理を目指す。
  • 1対多の関係が多いテーブルは、ストリームタイプの候補になり得る。

5. 明示的なイベントを導入する

  • リレーショナルデータをイベントへ移行する際、新たに見つけたイベントをインポート中に再利用するのではなく、Order Imported イベントを明示的に用意するべきである。

6. 実験と検証

  • 安全な環境でプロトタイプを試し、結果を予想と比較し、焦らずに反復するべきである。

GN⁺の見解

  • この記事で最も重要なのは、リレーショナルデータベースからイベントソーシングへ移行する過程において、ビジネスデータを保持する新しいアプローチの重要性である。
  • この記事が興味深い理由は、従来のデータ管理のやり方から一歩進み、データのライフサイクルをより深く理解し活用できる方法を提示している点にある。
  • イベントソーシングは、技術的な観点だけでなく、ビジネスチームと技術チームの間で共通理解を築くのにも役立つ可能性がある。

関連記事

1件のコメント

 
GN⁺ 2023-12-18
Hacker Newsの意見

  • PostgreSQL と FOSS レポーティングツールの利用を推奨

    • アプリケーションですでに PostgreSQL を使っているなら、イベントデータを PostgreSQL に保存し、FOSS のレポーティングツール（Apache Superset、Metabase など）を使うことを勧める。
    • データが約 2TB に達するまでは PostgreSQL を使い、その後は 2TB のデータをオンラインで必要とするのか、それとも日次・時間次の要約だけが必要なのかを判断する。
    • あるクライアント事例では、10TB を超えるデータと毎秒 1500 件のイベントを処理しており、詳細データは 2 日間オンラインに保持し、残りは要約して S3 に移し、Athena SQL 経由でクエリできるようにしている。
    • AWS RDS Multi-AZ を使って自動フェイルオーバーをサポートしており、1 人のエンジニアが月 5 時間未満ですべてを保守している。
    • PostgreSQL は、データを 1 か所に保管し、学習し、管理し、拡張できる単一のシステムを提供する。
    • 非技術職の人でも Metabase や Preset のようなシステムで簡単にチャートを作成できる。
    • PostgreSQL は毎年進化しており、必要であれば PostgreSQL 互換システム（Aurora、TimescaleDB、CitusDB など）を通じてさらにスケールできる。

  • イベント駆動アーキテクチャを適切に使うタイミング

    • 顧客が特定の行動をして応答を期待する場合、それはイベント駆動ではなくリクエスト/レスポンスのパターンである。
    • イベント駆動とは、予期していない状況で発生するものを指す。たとえば、GitHub にコードを push するとビルドがトリガーされるようなケースである。

  • イベントソーシングに懐疑的だった経験の共有

    • あるチームはイベントソーシングを検討したが、明確な利点が見えず、新しいものを試すリスクもあったため、最終的に採用しないことにした。
    • 学習機会を逃したことへの後悔はなく、必要のない状況で複雑な問題に飛び込まなかったことを前向きに評価している。

  • ドメインイベントモデリングの有用性

    • ドメインイベントモデリングは、解決しようとしている問題領域のドメインエキスパートとコミュニケーションするうえで有用である。
    • 長期間にわたるステートマシンの監査証跡を提供するシステムを実装する場合は、Temporal.io/durable functions のようなツールを使うほうがよい。
    • これらのツールは内部的にイベントソーシングを使っており、重複排除と冪等性を考慮したコードを書くことを強制する。

  • イベントソーシングの実装に関する疑問

    • イベントストリームから現在の状態を効率よく再構築する方法や、データベース内でイベントストリームをどうモデリングするかについての説明が不足している。

  • ボトムアップ対トップダウン、カスタム対汎用

    • トップダウンのアプローチはビジネスドメインから始め、利用可能な技術、ツール、ベンダーに合わせて実装をマッピングする。
    • ボトムアップのアプローチは利用可能な技術、ツール、ベンダーから始め、動作するソリューションを組み合わせる。
    • カスタムなアプローチには、DDD、CQRS/ES、Sagas、TBUI、GraphQL、代数的データ型などが含まれる。
    • 汎用的なアプローチには、RDBMS、CRUD、REST、ACID トランザクション、CDC、汎用管理 UI、ノーコード/ローコード、制限付き/汎用型などが含まれる。

  • イベントベースアーキテクチャへの支持と批判

    • イベントベースアーキテクチャを支持する立場ではあるが、その記事は主張を明確に伝えることに失敗している。
    • データの関係性とビジネス上の振る舞いの違いに焦点を当てると、運用中のリレーショナルデータストアから離れる理由がより明確になる。

  • イベントソーシングと関係性の必要性

    • イベントソーシングには多くの利点があるにもかかわらず、依然として関係性は必要である。
    • 関係性がアプリケーション層のコードにすべて暗黙的に埋め込まれているなら、それは受け入れられない。
    • 関係性をクエリしたり、関係ビューを最新の状態に保つ方法が必要である。

  • リレーショナルデータへの支持

    • 複雑さを避け、従来のリレーショナルデータに忠実でいることに決めた。

  • イベント駆動設計に対する新たな認識

    • 最近イベント駆動設計を知り、AI が支配する世界で最適なデータ構造を考える中で、似たような結論にたどり着いた。
    • イベント駆動設計が複雑さを管理し、データを実際に活用できるようにするなら、価値があるはずだと考えている。
    • 今後数年で、AI があらゆるビジネスイベントに関する知識を持ってクエリできるようになるにつれ、イベント駆動設計は一般化していくと予想している。