別のレポートデータベースを構築するタイミング
私たちはデータベースを備えたアプリケーションを構築しています（ええ、かなりエキサイティングなハァッ:)。データベースは主にトランザクション対応（アプリをサポートするため）であり、アプリの一部として少し「レポート」を作成しますが、それほど手間がかかりません。
それ以上に、いくつかのレポート要件がありますが、現時点ではかなりあいまいで高レベルです。社内で使用する標準のレポートツールがあり、要件が固まったときに「より重い」レポートを作成するために使用します。
私の質問は、レポート用に別のデータベースが必要な場合、どのようにして知るのですか？
どのような質問をする必要がありますか？別のレポートデータベースが必要だと判断するのはどのようなことですか。
一般に、トランザクションアプリのミッションクリティカル性が高まり、レポート要件が高度になればなるほど、分割が有効になります。
- トランザクションのパフォーマンスが重要な場合。
- トランザクションアプリでメンテナンスウィンドウを取得するのが難しい場合。
- レポートでこのアプリだけでなく他のアプリケーションサイロからの結果を関連付ける必要がある場合。
- レポートが、スタースキーマ/ビジネスインテリジェンス環境に最適なトレンド分析やその他のタイプのレポートをサポートする必要がある場合。
- レポートの実行時間が長い場合。
- トランザクションアプリが高価なハードウェアリソース（クラスター、メインフレームなど）上にある場合
- トランザクションデータに対してデータクレンジング/ extract-transform-load操作を実行する必要がある場合（例：状態名を正規の状態の省略形に変更）。
それは重要な複雑さを追加するので、imo、分割する正当な理由がなければなりません。
通常、最初はトランザクションデータベースからレポートを作成しようとします。
効率的なレポート作成を容易にするために追加するインデックスがすべて頻繁に使用されていることを確認してください。追加するインデックスが多いほど、挿入および（キーを変更した場合）更新のパフォーマンスが低下します。
レポートデータベースに移動する場合、そこに移動する理由はいくつかあることに注意してください。
結局のところ、レポートデータベースに関する最大のことは、OLTPデータベースからロック競合を削除することです。そのため、レポートデータベースが同じデータベースの単純なコピーである場合、単に遅延を使用しています。本番トランザクションに干渉しないスナップショット。
次に、レポートの使用シナリオをサポートするための個別のインデックス作成戦略を作成できます。これらの追加のインデックスは、レポートデータベースで維持しても問題ありませんが、OLTPデータベースで不要なオーバーヘッドが発生します。
これで、上記の両方を同じサーバー（別のデータベースの同じインスタンスでも、別のスキーマでも）で実行でき、それでも利点が得られます。 CPUとIOが完全に固定されている場合、その時点で、完全に別のボックスに置く必要があります（または単一のボックスをアップグレードします）。
最後に、レポートの柔軟性を高めるために、データを非正規化して（通常はディメンションモデルまたはスタースキーマに）、レポートデータベースが別のモデルの同じデータになるようにします。スタースキーマは非常に効率的であるため、ディメンションモデルでは大量のデータ（特に集計）のレポートは非常に高速です。また、ディメンションモデルは予想外の使用パターン（古い「あらゆる方法でスライスしてダイスする」リクエスト）に適しているため、インデックスを変更するために大量の再インデックスや分析を行わなくても、さまざまなクエリで効率的です。これは、データウェアハウジング技術を使用する一種のミニデータウェアハウスであると考えることができますが、必ずしも本格的なデータウェアハウスを実装しているわけではありません。また、スタースキーマはユーザーにとって特に扱いやすく、データディクショナリはスタースキーマからBIツールまたはレポートツール用に構築するのがはるかに簡単で簡単です。前に説明したように、同じボックスまたは別のボックスなどでこれを行うことができます。
この質問には、科学ではなく経験が必要です。
BIアーキテクトとして、クライアントのために各BIソリューションを設計する際に私が取るアプローチは、非常に異なります。チェックリストはチェックしません。それは彼らのシステム、彼らの報告要件、予算と人的資源の一般的な理解を必要とします。
私は個人的には、データベース側でできる限りレポートプロセスを維持することを好みます（BIの世界でのベストプラクティス）。レポートツールは、目的のみを表示するためのものです（最小の計算では最大）。このアプローチは、さまざまなステージングテーブル、トリガーなどを必要とする多くのデータの前処理を必要とします。
あなたが言ったとき：
何億もの行があるプロジェクトに取り組み、リアルタイムでレポートを作成し、同時に何百人ものユーザーが問題なくアプリケーション/データベースにアクセスします。
あなたの声明にはいくつかの誤りがあります。
何億もの行が大量にあります。 Cognos TM1やQlikviewのような今日のインメモリツールでさえ、そのような結果を得るのに苦労します。 （SAPのSAP HANAを見て、業界の巨人がどのように処理するかを理解してください）。
データベースに何億もの行がある場合でも、レポートがそれらすべてのレコードを通過する必要があるとは限りません。おそらく、レポートは数百万ではなく数千で機能しました。おそらくそれはあなたが見たものです。
トランザクションレポートは、ダッシュボードとは大きく異なります。ほとんどのダッシュボードツールは、データを前処理してキャッシュします。
私のポイントは、次の場合を決定するためのすべてが経験になるということです。
- 新しいスキーマを設計する
- セマンティックデータベースを作成する
- 同じトランザクションデータベースで作業する
- またはレポートツールを使用する（Java/JSF/Ajax/jQueryまたはJSPを使用した手書きのダッシュボードがクライアントで正常に機能することがある）
また、レポートデータベースを使用する理由として、CQRSパターン（コマンドクエリの責任の分離）も追加します。
多数のユーザーが少数のデータセットにアクセスして書き込む場合は、このパターンを検討することをお勧めします。基本的に、最も単純な形式では、すべてのコマンド（作成、更新、削除）がトランザクションデータベースにプッシュされます。すべてのクエリ（読み取り）は、レポートデータベースからのものです。これにより、アーキテクチャを自由にコピーして機能をアップグレードできます。
パターンにはそれよりもはるかに多くありますが、レポートデータベースに関する質問のために興味深い点について述べました。
問題を報告するために別のデータベースが必要になる主な理由は、レポートの生成がアプリのトランザクションの責任に干渉する場合です。例えば。レポートが生成するのに20分かかり、CPU /ディスクなどの100％を利用する場合...アクティビティの多い時間に、レポート用に別のデータベースを使用することを考えるかもしれません。
質問に関しては、ここにいくつかの基本的なものがあります：
- ピーク時以外の時間に高輝度レポートを実行できますか？
- システムを使用しているユーザーに干渉しますか？
- 2番が「はい」の場合、干渉のコストと別のデータベースサーバーのコスト、コードのリファクタリングなどはどうなりますか？
基本的に、アプリからのデータベースロードがレポート用のデータベースロードと互換性がなくなったとき。これは次の原因が考えられます：
アプリのDBパフォーマンスに影響を与えるデータベースサーバーリソースの消費量が非常に多いと報告している。
このカテゴリの一部は、ロックによる大幅に遅いレポートクエリを待たなければならないアプリDBの作業ですが、ロックチューニングのようなそれほど思い切っていない方法で解決できる可能性があります。
レポートクエリは、チューニングに関する限り、アプリクエリと非常に互換性がありません（たとえば、インデックスに限定されません）。最も目的のない例は、レポート目的のインデックスのため、アプリの挿入に影響を与えるホットスポットのようなものです。
タイミングの問題。例えば。 （アプリケーションの使用により）DBメンテナンスに利用できる唯一の小さなウィンドウは、大量のレポート作業の時間です
レポートデータの膨大な量（ログ、監査、統計など）は非常に大きいため、プライマリDBサーバーアーキテクチャはそのようなレポートには不適切なソリューションです（Sybase ASEとSybase IQを参照）。ところで、これは実際のシナリオです。このため、パフォーマンスレポートをIQに移動しました。
また、トランザクションデータベースは現在の状態を保持することを目的としており、多くの場合、自己維持するために保持します。トランザクションデータベースが必要な手段を超えて成長することは望ましくありません。ワークフローまたはトランザクションが完了したら、そのデータをレポートデータベースに移動します。レポートデータベースは、履歴データを保持するように設計されています。