web-dev-qa-db-ja.com

リレーショナルDBに多くの小さめの時系列を格納する方法は？

入力データ

複数のテストベッドは、さまざまな複雑さの測定データを生成します。

メタデータを考慮しない最も基本的な形式では、テストベッドでの1つの測定は、サンプルあたり数十のチャネル/信号/属性を持つ小さな（1-数千のサンプル）時系列になります。

時間とテストベッドでの測定では、同様の信号セットが使用されますが、テストセットアップでセンサーが追加および削除されると常に同じとは限りません。

データ量

現在、データレートは_6 testbeds x 4 test per hour x 12 hours a day x 4000 samples per test == 1,152,000 samples per day x 365 == 420,480,000 samples per year_で推定しています

_ x 48 columns per sample (currently 32 bit floats, mostly) ~~~ 75 GB per year

（この場合の列はチャネル/信号を指します）

テストベッドを追加すると、それに応じてデータ量が増加する場合があります。

データ入力

テストベッドはローカルでデータを生成し、データは非同期でデータベースにインポートされます。 （1秒間に数千のサンプルが生成され、ローカルで確認されてから、スクラッチまたはインポートされます。）

クエリ

クエリは、主に単一の測定の集計に基づいていると想定しています。つまり、すべての測定値（それぞれが4kサンプル）を見つけたい場合、 channel_output_voltageの平均は特定の範囲内です。

データベースのレイアウト？

このためのテーブルを設定する良い方法は何ですか？どのような要素を考慮に入れなければなりませんか？

理論的には、測定ごとに1つのテーブルを使用して、年間100,000テーブルを生成することもできますが、それは良い考えではありません。

または、すべてのチャネルの余地がある1つの大きなテーブル（数百の列を持つ）にすべてを入れて、必要に応じてチャネルを追加することもできます（サンプルごとに1行）。未使用のチャネルはNULLのままです。

_MEASUREMENTS
------------
measurement_id } PK
time_stamp     }
channel_1 (may be NULL for a certain measurement_id ...)
channel_2
...
channel_n(+1)
_

または、サンプル用の1つのテーブル（タイムスタンプ）とすべての値を含む1つのテーブルを用意する方法も考えられます（MEASUREMENTSテーブルのサンプルごとに1行、SAMPLE_VALUESテーブルのサンプルごとにn行）。

_SAMPLES            SAMPLE_VALUES
------------       -------------
measurement_id     sample_id
time_stamp         channel_id (links to a channels table where there is a name etc.)
sample_id          channel_value
_

他にどのようなオプションがありますか？どのオプションを選択すべきかをさらに調査するにはどうすればよいですか？

データベース製品

お客様の制約により、これをMS SQLSまたはOracleに配置したいと考えています。

から 1つの回答 ：

生データは保存せず、集計のみを保存します。真剣に。

これは、どのクエリ顧客が自分のデータに対して実行したいかを事前に決定する意味のある方法があると想定しています。 方法なし :-)

sql-serveroracledatabase-designschemascalability
6
Martin

クエリは毎月/年のデータを収集することになっていますか？

パーティションを使用して、さまざまな物理ファイルに情報を保存できます。特定の期間に関する情報のみが必要な場合、パーティションを使用すると、SELECTステートメントの速度を上げることができます。 http://msdn.Microsoft.com/en-us/library/ms345146%28v=sql.90%29.aspx

Microsoft SQL Serverでパーティション分割されたテーブルを作成するときに、異なる物理的な場所に異なるファイルグループを作成し、それらを個別にバックアップすることもできます。

データベースの設計に関する質問については、正規化についてこちらをご覧ください。 http://en.wikipedia.org/wiki/Database_normalization

3
Ruud van de Beeten

クエリは主に単一の測定値の集計に基づいていると想定しています。それを活用してください。生データは保存せず、集計のみを保存します。真剣に。

OK、集計コードをデバッグする必要があります。そのため、生データをいくつかの簡単なフォルマント（csv？）でディスクファイルに保存します。数日後にそれらを投げることを計画します。

これにより、75 GB /年の要件、20 INSERT /秒の要件などがなくなります。

年間100,000テーブル悪い考え。テーブルを開くと、OSはうなり声を上げます。私はそれが終わったのを見てきましたが、テーブルを開くだけで数秒から数分かかります。

1
Rick James

Re：ビッグテーブルアプローチ

または、すべて（すべてのサンプル）を1つの大きなテーブル（数百の列を持つ）に貼り付けて、すべてのチャネル用のスペースを確保し、必要に応じてチャネルを追加することもできます（サンプルごとに1行）。未使用のチャネルはNULLのままです。

私はこれを Oracleドキュメント で見つけました：

ヌル値の保管

nullは列に値がないことです。ヌルは、欠落、不明、または該当しないデータを示します。

NULLは、データ値を持つ列の間にある場合、データベースに格納されます。これらの場合、列の長さ（ゼロ）を格納するために1バイトが必要です。 行の末尾のnullはストレージを必要としません[強調。追加] 新しい行ヘッダーは、前の行の残りの列がnullであることを通知するためです。たとえば、テーブルの最後の3つの列がnullの場合、これらの列のデータは保存されません。

したがって、これにより、サンプルデータ用の1つのテーブルによるアプローチがかなり魅力的になるように見えます。これは、SAMPLE_VALUESテーブルのスペースに関する多くのオーバーヘッドを節約できるためです。

テーブルごとに最大1000列 があり、2000〜3000チャネルのデータセットがあるので、さらに複雑になりますが、1000列のテーブルをさらに追加できると思います。 （現実的には、かなり長い間、3または4で十分だと思います）。

0
Martin