最近、SQL Server 2005 のユーザーと話をしたところ、データベースが過度に正規化されており、データをレポート サーバーにレプリケートしているとのことでした。データベースはトランザクションとレポートの両方を処理することになっていませんか? 2 台のサーバーに投資して複製する必要があるのはなぜですか?
これは自由回答の主観的な質問であることは承知しています。上記の場合の統計はありませんが、トランザクション レポートを処理するのに十分なデータベースのチューニングではありませんか? データ マイニングのシナリオでは、Analysis Services と非正規化機能を備えた別のサーバーが必要であることは理解できます。しかし、今年の取引では？
ありがとう。
場合によります。
1 年または 1 か月の詳細なデータであっても、レポート用にスキーマが最適化されているデータベースでより適切に処理される可能性は十分にあります。
また、レポートの種類にもよりますが、現在の月の傾向を過去の月と比較する場合、それらを同じデータベースに置く方がはるかに簡単です。また、毎日の移動平均がある場合、データベースの境界を越えてその操作を実行するよりも、単一のデータベースでそれを行う方がはるかに簡単です。
過度に正規化されている限り、それは多くのことを意味します。
アプリケーション (OLTP) とレポート (DW) の負荷は、大規模なアプリケーションでは大きく異なる場合があり、通常は大きく異なります。OLTP トランザクションは、一度に少量のレコードを処理し、頻繁に発生し、選択、挿入、または更新の可能性があります。DW クエリは、より多くのレコードを処理する傾向があり、発生頻度が低く、読み取り専用にする必要があります。
小規模なアプリケーションやデータの履歴がまだない若いアプリケーションでは、パフォーマンスは問題になりません。しかし、アプリケーションが成長し、人気が高まるにつれて、アプリケーション パフォーマンスと分析レポートの両方のビジネス ニーズを満たすために、別個のデータベースと最終的には別個のサーバーが必要になります。
ここでは、2 種類のワークロードの概要を示します。
OLTP クエリは通常、アプリケーションのパフォーマンスに強い関心を持ち、対応しようとしているビジネス機能の種類を正確に把握している開発者によって作成されます。同じクエリが 1 日に何度も実行され、問題が解決されます。ここでは、作業負荷のタイプの例をいくつか示します。
DW クエリは、アドホック レポート用のクエリ ツールによって自動生成される場合もあれば、技術的な経験がほとんどないアナリストやビジネス ユーザーによって直接作成される場合もあります。SAS や Mathematica などの選択したツールに select * を実行することを好む人もいます。これらのタイプのクエリは、ダーティ リードを使用しないと、OLTP アプリケーションのパフォーマンスに大きな影響を与える可能性があります。トレンド分析を実行したり、多数の顧客をパーセンタイルにグループ化したりするために適切に作成されたクエリでも、すべてのデータが必要なため、完全なテーブル スキャンが必要になる場合があります。回答が必要な質問の種類。
プロダクション/トランザクション サーバーとは別のレポート サーバーを用意することは、多くの場合良い考えだと思います。完全に「正規化されていない」データ構造を使用してレポート サーバーをセットアップしましたが、リレーショナルの純粋主義者はうんざりします...しかし、それはレポート サーバーであるため、問題ではありません。
ユーザーは、DBA が邪魔をすることなく「自分の」データにアクセスできることを気に入っています (レポート データベースはもちろん読み取り専用です)。
ユーザーが使用できる情報を可能な限り最速の方法で取得することのみを目的として、運用サーバーからデータを取得し、ロールアップ、要約、クロス集計、クリーンアップを行う一連のルーチン (できれば無人の夜間バッチ プロセス) です。 、非常に多くの場合、良い解決策です。
間違いなく私の場合、「...を表示するレポートを作成してもらえますか」というタイプのリクエストに対して、私の負担を軽減してくれました。ユーザーにデータへのアクセスを許可し、ツールのトレーニングを行い、そのまま使用できるようにします。
レポートを作成するユーザーの知識と、使用しているツールによっては、これが最善の解決策になる場合があります。アドホックな顧客レポートを取得するためだけに8つのテーブルを手動で結合する必要がある場合は、すべての汚い作業を行うビューを備えたレポートサーバーを使用することをお勧めします。
それは実際に使用している環境とアプリケーションに依存します。別のレポート サーバーを用意するのが安全な方法です。高度に正規化されたスキーマを持ち、大量のトランザクションが発生し、レコードのロックが発生する実稼働システムがある場合、これに対して複雑なレポートを実行すると、壊滅的なパフォーマンス ヒットが発生する可能性があります。たとえば、おそらく別の開発者によって作成されたレポート クエリが複雑な結合に (NOLOCK) を含まない場合、ほぼ確実に問題が発生します。正しいクエリ (つまり、間違ったクエリ) を使用すると、データベース全体を停止させることができます。レポートでユーザーが大量のデータを取得できる場合は、それも確認することをお勧めします。ユーザーがそのようなクエリを実行できないようにする必要がある場合があります。このようなレポートは、要求があった場合にのみ作成してください。私見では
通常、過剰に正規化されているということは、レポート ユーザーがデータ モデルを理解していないことを意味します。この種のユーザーは、トランザクション データベースから遠ざける必要があります。複製されたサーバーは、報告ユーザーが複雑な結合を行っているためにトランザクション データベースが応答しない場合と比較すると、非常に安価なソリューションです。
これは、ほとんどが単純な組織的な手段であり、運用ユーザーとレポート ユーザーの間に境界を作成します。