0

MySQL 5.6 で時系列データを整理する方法についてご意見をお聞かせください。さまざまなセンサーからのデータを保存する必要があるプロジェクトに取り組んでいます。明確にするために、私たちはいくつかの産業施設を監視しています。それぞれは、プロセスに最も関連する情報をローカルに保存する PLC デバイス (またはステーション) によって制御されます。各センサーは plc のタグにマッピングされ、plc は定期的にこの情報を CSV 形式で FTP サーバーに送信します。ストレージ エンジンとして innoDB を選択しました。次のテーブルが用意されています。

  • tbl_stations (id,name)
  • tbl_tags (station_id, tag_id, name ... ) with (station_id, name) being the PK
  • tbl_data (station_id, tag_id, time, value) with PK (stations_id, tag_id, time)

PKinテーブルは、フォームのtbl_data高速範囲クエリを可能にすることです

SELECT * FROM tbl_data WHERE station=x and tag_id=y and time BETWEEN date1 AND date2

また、一部のタグは非常に高速にサンプリングされるため、テーブルtbl_dataは非常に急速に大きくなります。より適切に管理するために、また、通常は最新の情報にアクセスしているため、列 (タイムスタンプ)tbl_dataの範囲でパーティション分割しました。"time"特に、年間 4 つのパーティションを使用しています。パーティショニングが有効になっている場合でも、ステーションの数が増えると、1 つのパーティションが大きくなる可能性があります。そこで、各サブパーティションにいくつかのステーションのデータのみが含まれるように、station_id でサブパーティション化することにしました。特に、この目的のために HASH パーティショニングを使用しました。

今のところ、すべてうまくいっていますが、まだ改善の余地がある場合に備えて、ご連絡をお待ちしております. 時系列データを扱うのはこれが初めてなので、何か重要なものを見逃している可能性があります。

各ステーションから次の形式でデータを受信することを忘れていました。

TAG_ID1
TIME, VALUE
TIME, VALUE
.
.

TAG_ID2
TIME, VALUE
TIME, VALUE
.
.
.

等々。このようにして、挿入はどういうわけかPK順番に行われます。これは、私の知る限り、挿入率を高速化するのに適しています。

4

2 に答える 2

0

SQL に関する質問にはまだ答えていませんが、「改善の余地」に関する質問には答えています。

独自の要件に基づいてデータを手動で圧縮することをお勧めします。前述の RRD は固定サイズのデータ​​ ファイルには適していますが、不特定の期間データを保持する場合や、SQL サーバーの機能を使用してデータをアーカイブする場合には適していません。

私たちが行ったのは、最大デルタ アルゴリズムを使用することです。これにより、各トレンド (温度、電圧など) に独自の dv (値の変化) と dt (時間の変化) が各トレンドのメタデータに保存されますmeasured dv < required dv。新しいサンプルを保存しませんでしたmeasured dt < required dt。

これにより、圧縮率と柔軟性が大幅に向上しました。これは、通常、温度の読み取り値にあまりばらつきがないためです (dv=0.5 および dt=30s に設定)。一方、電圧には高解像度が必要です（dv = 0.01およびdt = 0に設定）など。

この方法の欠点は、傾向分析と分析にありました。このために独自のツールを作成したため、克服するのが最も困難なものは次のとおりです。

  1. x 秒間変化していない 2 点間の曲線を、点間の直線としてどのように表現しますか? これは、値が線形であることを意味します。最終的にはステップ ラインを使用したため、新しい値が受信されるまで値は同じままでした。
  2. オフライン期間や通信の問題をどのように検出しますか? ポーリングごとに 1 つのサンプルの暗黙的なハートビートがなくなるため、値が一定時間変化していなくてもデータが有効であること、または同様にデータが無効であることを示す別のメタデータ トレンドを導入する必要がありました。特定のセクション。

最終的な結果として、ポーリング レートが高かったにもかかわらず、小さなストレージ サイズで何年にもわたっていくつかの傾向を記録することができました。

于 2014-01-09T02:13:57.163 に答える
0

次の 3 点を確認することをお勧めします。

  1. 高解像度の履歴データが必要ですか? そうでない場合は、古いデータを集約するか、独自にデータ集約を実装する RRD タイプのデータベースを調べる必要があります (たとえば、volkszaehler.org プロジェクトには、vzcompress時系列データでそれを行うためのツールがあります)。.
  2. 集計された時系列データ (1 日あたりの合計など) を頻繁に取得する必要がありますか? はいの場合、たとえばvolkszaehler.orgプロジェクトが実装しているような別の集計テーブルが役立つ場合があります。
  3. 選択度が最も高いインデックスは、ステーションやタグではなく、おそらくタイムスタンプです。インデックスの順序を再構築するとうまくいくかもしれませんが、よくわかりませんので、パフォーマンス (=負荷) テストをお勧めします。
于 2013-10-29T10:54:04.320 に答える