レポーティングデータベース

ほとんどのエンタープライズアプリケーションは、永続データをデータベースに格納します。このデータベースは、アプリケーションの状態の運用上の更新と、意思決定支援および分析に使用されるさまざまなレポートをサポートします。しかし、運用上のニーズとレポートのニーズは、スキーマとデータアクセスパターンの要件が異なり、多くの場合まったく異なります。このような場合は、運用データの本質的なコピーを取得するものの、異なるスキーマで表現するレポーティングデータベースに、レポートのニーズを分離することをお勧めします。

このようなレポーティングデータベースは、運用データベースとはまったく異なるデータベースです。ポリグロットパーシステンスを使用して、まったく異なるデータベース製品である可能性があります。レポートのニーズに合わせて設計する必要があります。

レポーティングデータベースには、多くの利点があります。

• レポーティングデータベースの構造は、レポートを簡単に作成できるように設計できます。
• レポーティングデータベースは読み取り専用であるため、正規化する必要はありません。クエリとレポート作成を容易にするために、必要に応じてデータを自由に複製してください。
• 開発チームは、レポーティングデータベースを変更することなく、運用データベースをリファクタリングできます。
• レポーティングデータベースに対して実行されるクエリは、運用データベースの負荷に追加されません。
• データベースに派生データを格納することにより、別の派生ロジックセットを導入することなく、派生データを使用するレポートを簡単に作成できます。
• レポートのニーズに応じて、複数のレポーティングデータベースを用意できます。

レポーティングデータベースの欠点は、そのデータを最新の状態に保つ必要があることです。最も簡単なケースは、夜間実行を使用してレポーティングデータベースにデータを入力する場合などです。多くのレポートニーズは昨日のデータで完全にうまく機能するため、これは多くの場合非常にうまく機能します。よりタイムリーなデータが必要な場合は、メッセージングシステムを使用すると、運用データベースへの変更がレポーティングデータベースに転送されます。これはより複雑ですが、データの鮮度を保つことができます。多くの場合、ほとんどのレポートではわずかに古いデータを使用でき、この秒のデータ[1]を本当に必要とするものに対して特別なケースレポートを作成できます。

このバリエーションは、ビューを使用することです。これにより、運用データがカプセル化され、非正規化が可能になります。運用負荷とレポート負荷を分離するには、読み取り用にビューを他のノードに複製する必要があります。主な制限は、メモリ内プログラミング環境から得られるものよりもデータを取得する柔軟性が低いことです。

レポーティングデータベースは、ドメインモデルまたはその他のメモリ内コードに多くのドメインロジックがある場合に適しています。ドメインロジックを使用して、運用データの更新を処理するだけでなく、レポーティングデータベースを強化するための派生データを計算することもできます。