web-dev-qa-db-ja.com

1つのSQLiteテーブルにある複数のソースの時系列データまたは複数ですか？ファイルサイズへの影響は？

ここに状況があります：

  • ソースの非常に限られたセットからの大量の時系列データは、SQLiteデータベースファイルに保持されます。
  • 時系列ソースは、10文字の長い文字列で識別されます。ソースの数は非常に少なく、動的ではありません。
  • 時系列ソース間の相関分析をすぐに行う必要はありません。

おそらく、従来は、すべての時系列データを、各データポイントのソースを識別するテキストフィールドを持つ単一のテーブルにダンプしていました。

しかし、時系列データのソースごとに個別のテーブルを作成する方が効率的かどうか疑問に思っていますか？ SQLiteデータベースのファイルサイズは、繰り返しテキストフィールドを排除することにより、最終的にははるかに小さくなりますか？クエリははるかに速く実行されますか？

または、各ソースのテーブルを作成することを完全に控える必要がありますか？その理由は何ですか？

データベースは巨大ではないため、MySQLでのSQLiteの使用が必要になる場合があります。整数のタイムスタンプとは別に、さらに4つの整数フィールドがあります。測定は3分ごとに行われますが、1年以上は簡単に実行できます。設計の一部が、非常に限られた量のフラッシュメモリ（64Mビット）を備えた組み込みデバイスになってしまう可能性があるため、SQLiteに最初に興味を持った。しかし、私は他の提案を受け入れます。

schemasqlitetime-series-database
4
Serge Stroobandt

個人的に、私は潜在的に有用なデータを捨てることを嫌います。ソースのテーブルを作成し、ソーステーブルへの外部キーとしてsource_idを時系列テーブルに含めます。これにより、必要なスペースは少なくなりますが、ソース情報は保持されます（同一の複数のテーブルを必要としない）。

私は短い例をまとめました。これを見てください db-fiddle link 。

これが私の例のコードです：

CREATE TABLE source
     ( source_id INTEGER PRIMARY KEY ASC
      ,name varchar(10)
     );

CREATE TABLE time_series
     ( series_id INTEGER PRIMARY KEY ASC
      ,timestamp INTEGER
      ,value1 INTEGER
      ,value2 INTEGER
      ,value3 INTEGER
      ,source_id INT
      ,FOREIGN KEY (source_id) REFERENCES source(source_id)
     );

INSERT INTO source (name)
VALUES ('AAAA'), ('BBBB'), ('QZQZ');

INSERT INTO time_series (timestamp, value1, value2, value3, source_id)
VALUES (12345678, 100, 105, 110, 1)
      ,(12345681, 105, 105, 105, 1)
      ,(12345684, 110, 105, 100, 1)
      ,(12345678, 9, 27, 81, 3)
      ,(12345681, 27, 81, 243, 3)
      ,(12345684, 81, 243, 729, 3)
;



SELECT * FROM source;

SELECT s.name as source, timestamp, value1, value2, value3
  FROM source s INNER JOIN time_series ts ON (s.source_id = ts.source_id)
 ORDER BY source, timestamp
;

通常、SQLiteは使用しません。私の元のコメントに対するあなたの返答で述べたように、SQLiteはデフォルトですべてのテーブルに64ビット整数の行ID列を維持します。この例のテーブルは、その行IDの値を各テーブルの主キーとして使用するように設定しています。ドキュメントを正しく読んだ場合、外部キー列は主キーの値を保持するのに十分な大きさである必要があります。巨大なsource_idを手動で挿入しないと仮定すると、source_idテーブルのtime_seriesは1バイトだけで十分だと思います。

UNIQUEインデックスをsource_idとtimestampに配置することをお勧めします（ほとんどの場合、何らかのインデックスが必要です）。おそらく、同じソースと同じ時刻に2つのエントリが存在することはありません。 Serge Stroobandtが指摘したように、これは主キーになることさえあります。ただし、SQLiteはとにかく一意の行ID値を作成するので、それをキーとして残す傾向があります。 source_idとtimestampを主キーとして本当に使用したい場合は、テーブルWITHOUT ROWIDの作成を検討してください。

5
RDFozz