1

正規化されたデータベースがあり、複数のテーブル間の結合を含むWebベースのレポートを頻繁に作成する必要があります。これらのクエリには時間がかかりすぎるため、ページをすばやく読み込むことができるように、結果を計算したままにしておきたいと思います。私が要約しているテーブルは頻繁に更新されており、これまでのすべての更新を反映するために要約が必要です。

すべてのテーブルには自動インクリメントの主整数キーがあり、ほとんどの場合、新しい行を追加して、計算結果をクリアするように調整できます。

テーブルの各行を反復処理し、イテレータの状態と見られた最高のプライマリキーン（つまり「ハイウォーター」）を追跡することで、単一のテーブルの要約が必要な同様の問題に取り組みました。これは単一のテーブルの場合は問題ありませんが、複数のテーブルの場合、テーブルごとに1つの高水位値を維持することになり、それは複雑に感じます。または、1つのテーブルに非正規化することもできます（アプリケーションをかなり大幅に変更します）。これは一歩後退したように感じ、データベースのサイズを約5GBから約20GBに変更する可能性があります。

（現在、sqlite3を使用していますが、MySQLもオプションです）。

4

5 に答える 5

2

私は2つのアプローチを見ています：

  1. データを別のデータベースに移動し、非正規化して事前計算を行い、迅速なアクセスとレポート作成のために最適化します (小さなデータ ウェアハウスのように聞こえます)。これは、ソースから宛先にデータをコピーして変換するいくつかのジョブ (スクリプト、別のアプリケーションなど) を考える必要があることを意味します。コピーを実行する方法 (完全/増分)、コピーの頻度、およびデータ モデルの複雑さ (コピー元とコピー先の両方) によっては、プロセスの実装と最適化に時間がかかる場合があります。ソースデータベースをそのままにしておくという利点があります。

  2. 現在のデータベースを保持しますが、非正規化します。あなたが言ったように、これはアプリケーションのロジックの変更を意味するかもしれません（しかし、データベースを使用してロジックへの影響を最小限に抑える方法を見つけるかもしれません.あなたは私よりも状況をよく知っています:)）。

于 2009-06-04T10:30:29.030 に答える
1

トリガーを作成できます。

計算値の1つが変更されるとすぐに、次のいずれかを実行できます。

  • 計算フィールドを更新します（推奨）
  • サマリーテーブルを再計算します
  • 再計算が必要であることを示すフラグを格納します。次に計算値が必要になったときは、最初にこのフラグを確認し、必要に応じて再計算を行ってください

例：

CREATE TRIGGER update_summary_table UPDATE OF order_value ON orders 
BEGIN
  UPDATE summary 
    SET total_order_value = total_order_value 
                          - old.order_value 
                          + new.order_value 
    // OR: Do a complete recalculation
    // OR: Store a flag
END;

SQLiteトリガーの詳細：http ：//www.sqlite.org/lang_createtrigger.html

于 2009-06-04T10:39:52.037 に答える
1

レポートを段階的に更新できますか?それとも、レポートを作り直すために完全に再計算する必要がありますか? 完全な再計算が必要な場合は、基本的に、次の更新が必要になるまで結果セットをキャッシュするだけです。レポート出力を含むいくつかのテーブル (および利用可能なレポート出力バージョンを定義するメタデータ テーブル) を作成できますが、ほとんどの場合、これはやり過ぎであり、クエリ結果をファイルまたは他のキャッシュ ストアに保存することをお勧めします。 .

インクリメンタル リフレッシュの場合は、PK 範囲を操作する必要があるため、ハイ ウォーター マーク データのようなものが必要になります (ただし、最小/最大ペアを保存する必要がある場合を除きます)。

于 2009-06-04T13:27:04.040 に答える
0

最終的に、単一のプログラム インスタンスがすべてのデータベースの更新を行い、集計をそのヒープに保持するようにしました。つまり、データベースにはまったく保持しませんでした。この場合、これは非常にうまく機能しますが、データベースの更新を行うプログラムが複数ある場合は不適切です。

于 2009-06-08T15:43:55.257 に答える
0

インデックス戦略については何も言っていません。最初にそれを見て、インデックスがカバーされていることを確認します。

次に、説明したトリガー オプションも非常に優れた戦略だと思います。

もう 1 つの可能性は、ハイ パフォーマンス レポートに適したモデル (キンボール モデルなど) を使用してデータ ウェアハウスを定期的に作成することです。

于 2009-06-08T15:54:45.163 に答える