大量のデータセットに対して平均化計算を実行することが望まれます。データはかなり頻繁にデバイスから取得され、最終日の平均、先週の平均、先月の平均、および昨年の平均を取得したいと考えています。
残念ながら、昨年のデータの平均を取るには数分かかります。私は SQL の基本的な知識しか持っていませんが、ここで物事をスピードアップするための良い情報があることを願っています。
このテーブルには、タイムスタンプ、データが属するデバイスを識別する ID、および浮動小数点データ値があります。
私が使用してきたクエリは、次の一般的な例に従います。
select avg(value)
from table
where id in(1,2,3,4) timestamp > last_year
編集：これらの平均を定期的に計算するように要求していることも明確にする必要があります。「年初来」の平均のように。単純に膨大な量の結果が原因で、妥協しなければならない場合があることを認識しています.
この種の問題については、次の解決策をいつでも試すことができます: 1) クエリを最適化: クエリ プランを確認し、いくつかのインデックスを作成し、既存のインデックスをデフラグし、サーバーが空いているときにクエリを実行します。2) キャッシュ テーブルを作成します。 . キャッシュ テーブルにデータを入力するには、次のいずれかの戦略を選択します。1) 結果に影響を与えるテーブルでトリガーを使用し、キャッシュ テーブルを挿入、更新、削除して更新します。トリガーは非常に、非常に、非常に高速に実行する必要があります。他の条件は、レコードをブロックしないことです (そうしないと、サーバーがビジー状態の場合にデッドロックに陥ります) 2) 1 日/1 時間/などに 1 回、キャッシュ テーブルにジョブを入力します 3) 私が気に入っている 1 つの解決策は、結果が必要なときに SP によってキャッシュします (例:
統計キャッシュ用のキャッシング テーブルを作成できます。次のような構造になっている必要があります。
year | reads_sum | total_reads | avg
=====|============|=============|=====
2009 | 6817896234 | 564345 |
年末に、avg (平均) フィールドに、すぐに計算できるようになった値を入力します。
タイムスタンプにクラスター化インデックスを作成することを検討することをお勧めします。通常、クラスター化されたインデックスは id で無駄になります。これに関する 1 つの注意点は、明示的な並べ替えがない場合、他の SQL ステートメントの出力の並べ替え順序が変わる可能性があることです。