0

ここに画像の説明を入力してください

このデータモデルを取得しました。限られたツリーの深さを知っているので、現在のテーブルはモデルに対して1：1であり、親ノードへの外部キーがあります。Channelto Station、Measurementto Channel、。Station_ クエリの90％は次のとおりです。

select value from measurements where
fk_station=X and fk_channel=Y and timestamp>=A and timestamp<=B
order by timestamp asc

残りの10％は、他のタイムスタンプ付きテーブルと同様ですが、が欠落しているために単純になっていfk_channelます。

私たちが直面している問題：テーブルには何億ものユニークな[station,channel,timestamp]行がMeasurementあり、成長しています。タイムスタンプインデックスはすでに非常に大きく、順序付け句が非常に遅いため、ステーションIDごとに分割を開始する必要がありました。したがって、テーブルがMeasurement_<Station Id>あり、Station外部キーは省略されています。これは非常に役立ちましたが、それでも一部のテーブルには数千万行が含まれていました。負荷のピーク時には、約80000クエリ/分が発生し、これらの大きなテーブルでのクエリは明らかに遅延します。派手な最適化ハックなしで、1つのMySQL/ISAMインスタンスから実行します。ファイルシステムで約150GB。

  1. そのようなデータモデルを保存するための大幅に異なる/より良い方法はありますか？
  2. 現在の構造では、このサイズ/負荷でこの種のパフォーマンスの一時的な中断が発生するのは正常ですか？マシンは今日の平均的なハードウェアであり、埋め込まれた原子も8+コアの獣もありません
  3. テーブルの分割はMeasurement正しいことでしたか？私たちはSQLの達人ではありませんが、クエリと必要なインデックスは非常に明白であるため、「最適化」することすら考えていませんでした。分割は大いに役立ちましたが、他の何かもそうかもしれません
  4. インデックスを高速化する他の方法はありますか？同じインデックスを何度も繰り返して、同じ結果のサブセットを取得する必要があるのは、ちょっとばかげています。他のインデックスを使用することはなく、に変更することもありませんdesc。非常に特殊なアプライアンスです。インデックスがどういうわけか「ネイティブオーダー」であればいいでしょう:-)
  5. Measurement分割されたテーブルを分散/シャーディングするのに役立ちますか？私が言ったように、いくつかのテーブルはまだ巨大であり、問​​題は分散が役に立たないインデックスサイズにあると感じているので、おそらくクエリの負荷を下げるだけです...
4

2 に答える 2

1

mysqlのようなリレーショナルデータベースで考える簡単なルール：

  1. あまりにも多くのデータをフェッチすることは決して速くありません。それを集約することができます。-サンプルクエリは何も集約していません。アプリケーションでこれらの値を処理して集約するかどうか疑問に思います。ヒント：列ストアエンジンを使用して集計します。infinidbは、クエリ実行でも並列処理をサポートしていますが、innodbはサポートしていません。
  2. 大量のデータの並べ替えは決して速くはありません-クエリが100Kレコードを返す場合、クランチジョブ/フロントエンドグリッドなどはどれくらい消費しますか？Webユーザーは画面上で100Kのデータを消費できますか？そうではありません、それからそれを制限してください。さらに、タイムスタンプの代わりに自動インクリメントIDで並べ替えます。リレーショナルデータベースエンジンは、大量のデータを並べ替えるのには適していません。すぐに上限に達します。
于 2012-10-01T09:06:20.967 に答える
0

測定データを複数のテーブルに分割すると、サイズを小さくできる可能性はありますか？クエリの90％が過去24時間のタイムスタンプを超えている場合は、そのデータを微調整し、残りを別のテーブルまたはデータベースに保存することをお勧めします。測定には、PKとしてのIDのみを持つチャネルへのFKと、ステーションへのFKが必要であると思います。

于 2012-09-29T22:07:06.000 に答える