1

さまざまな時間スケールでさまざまなデータをログに記録できるSQLサーバーデータベースを設計する必要があります。

基本的に私が記録しなければならないのは、いつでもたくさんのバッテリーからのバッテリーセルからのデータです。

これがデータベースの基本モデルです。画像のデータ型は私が使用しているものではありません。

私はそれらのほとんどにtinyIntを使用しています（2バイト）

  • 時間は3バイトです
  • 日付は2バイトです

データベース基本モデル

想像してみてください：

24時間ごとに1つのセルレポートファイルが発行されます。しかし：

セルの各属性は、同じ頻度で更新されません。

例えば ​​：

  • 時間属性は毎秒更新されます
  • アンペア属性は毎秒更新されます
  • Temp1属性は毎分更新されます
  • 毎日更新日

そしてそのセルは何年にもわたって24時間年中無休で報告しています。

データベースにリンクされている世界中のバッテリーが1000個あり、各バッテリーに20個のセルがあるとします。

24時間年中無休で報告する20000セル

だからここに問題があります：

属性が1つだけ変更された場合、行全体を再保存したくありません。もしそうなら、20000セルの場合、私は1〜1年必要です。（これは、更新されていない値の代わりにNullが保存されている場合です）。

説明が十分に明確であることを願っています。さらに情報を求めることを躊躇しないでください

いつものように私は私の英語をお詫びします：/

ありがとうございました。

4

2 に答える 2

1

KeyおそらくとValue列を持つ単純なテーブル。

例えば。

RowID  BattID  Dt                   Key   Value
1      1       07/02/2013 10:00:01  Amps  1.852
2      1       07/02/2013 10:00:02  Amps  1.809
3      1       07/02/2013 10:00:03  Amps  1.758
4      1       07/02/2013 10:00:03  Tmp1  18.4
5      1       07/02/2013 10:00:04  Amps  1.725

キーのデータ型は、スペースを節約するためにtinyintにすることができます。

このデータを取得したら、インデックスが正しい限り、PIVOTクエリを使用して、必要な方法でデータを再構築できます。

于 2013-02-07T10:05:06.797 に答える
1

1秒あたり20kの挿入が必要です。これは確かに実行可能ですが、これがどれだけのデータであるかを示しています。そのレートで一括挿入してもまったく問題ありませんが、しばらくの間データを保持する必要もあります。それは多くの行とTBになるでしょう。

これをカスタム形式で保存することを検討します。バッテリーごとおよび1時間ごとに1つのバイナリブロブを保存できます。そのblobでは、変更を自由にエンコードできます。変更されない列は、まったく保存しないことで非常に効率的に保存できます。保存する前にblobを圧縮することもできます。

このスキームでも、バッテリーと時間のインデックスを作成できます。時間分解能が1時間に減少しました。アプリはBLOBをデコードし、そこから必要なデータを抽出する必要があります。

データは非常に冗長であるため、簡単に圧縮できます。圧縮には、LZO、LZ4、QuickLZなどの非常に高速なスキームがあります。7zのようなものでより多くの圧縮を得ることができます。

于 2013-02-07T10:46:39.727 に答える