5

最小/最大/平均のクエリを実行している場合、集計テーブルを使用するのと、単純に生のテーブルの行の範囲に対してクエリを実行するのとではどちらが好みですか?

これは明らかに非常に自由回答形式の質問であり、正解は 1 つではありません。そのため、人々の一般的な提案を探しているだけです。生データ テーブルが、タイムスタンプ、数値外部キー (ユーザー ID など)、および 10 進数値 (購入金額など) で構成されているとします。さらに、テーブルに何百万もの行があるとします。

私は両方をやりましたが、引き裂かれています。一方では、集計テーブルによってクエリが大幅に高速化されましたが、追加のテーブルが急増しました。集計範囲の現在の値を表示するには、元のデータ テーブルに完全に戻すか、より詳細な集計を組み合わせる必要があります。どの集計テーブルを照会するかをアプリケーション コードで追跡するのは、思った以上の作業であり、元の集計範囲では常に十分ではないため、スキーマの変更が必要になることがわかりました ("しかし、過去 3 回の支払い期間の売り上げです!」)。

一方、生データからのクエリは非常に遅くなる可能性がありますが、データ範囲について非常に柔軟に対応できます。範囲の境界が変更された場合、集計テーブルを再構築するのではなく、クエリを変更するだけです。同様に、アプリケーション コードの更新も少なくて済みます。インデックス作成についてもっと賢くなれば (つまり、常に適切なインデックスをカバーしていれば)、生データから選択する際のペナルティを減らすことができると思いますが、それは決して万能薬ではありません。

両方の長所を活かす方法はありますか?

4

3 に答える 3

3

同じ問題があり、あなたが遭遇したのと同じ問題に遭遇しました. 最終的にレポートを Analysis Services に切り替えました。MDX と分析サービス自体には学習曲線がありますが、それは素晴らしいことです。私たちが見つけた利点のいくつかは次のとおりです。

  1. 任意の方法でクエリを実行できる柔軟性があります。以前は特定の集計を作成する必要がありましたが、今では 1 つのキューブですべての質問に答えることができます。
  2. キューブ内のストレージは、詳細データよりもはるかに小さいです。
  3. キューブの構築と処理にかかる時間は短く、集計よりもデータベース サーバーにかかる負荷は少なくなります。

いくつかの短所：

  1. キューブの構築と MDX の学習には学習曲線があります。
  2. キューブの操作を自動化するために、いくつかのツールを作成する必要がありました。

更新: MySql を使用しているため、MySql をサポートするオープン ソース OLAP ソリューションであるPentaho Mondrianを参照できます。私は使ったことがないので、あなたに合うかどうかはわかりません。それがあなたのために働くかどうかを知りたいと思うでしょう。

于 2009-12-23T23:36:21.063 に答える
0

私は常に生データに傾倒しています。一度集計すると、元に戻すことはできません。
削除とは何の関係もありません-最も単純な集約データセットがない限り、データを正確に元に戻したり、生に戻したりすることはできません。

理想的には、マテリアライズドビューを使用します（データが制約内に収まると仮定して）。これは事実上テーブルであるためです。ただし、MySQLはそれらをサポートしていないため、次の考慮事項は、計算列を含むビュー、または実際のテーブルを更新するトリガーです。

于 2009-12-24T00:42:44.693 に答える
0

適切な主キー ([user_id、used_date、used_time]) を選択すると役立ちます。一定の user_id の場合、used_date で範囲条件を実行するのは非常に高速です。

ただし、テーブルが大きくなるにつれて、[user_id, used_date] のようなテーブルに集約することで、テーブルのサイズを減らすことができます。時刻が問題にならないすべての範囲で、そのテーブルを使用できます。テーブルサイズを縮小するもう 1 つの方法は、クエリを実行 (許可) していない古いデータをアーカイブすることです。

于 2009-12-24T10:36:00.417 に答える