web-dev-qa-db-ja.com

InfluxDB:単一または複数の測​​定

私はinfluxDBの初心者であり、 Schema design のドキュメントを読んだ後、疑問が残ります。

複数のフィールドで1つの測定を使用するか、単一のフィールドで複数の測定を使用するかを決定する方法は?

毎分データ(温度、湿度、圧力)を送信する複数のIoTデバイスがあります。このすべてのデータのタイムスタンプはまったく同じです。

だから私はdがこのように1つの測定を作成するかどうか疑問に思っていました:

    timestamp,iotid,temperature,humidity,pressure
-------------------------------------------------
    1501230195,iot1,70,         45,      850

または、3つの測定値(値ごとに1つ)で、タグは同じですが、フィールドは1つだけですか?

timestamp,iotid,temperature
----------------------------
    1501230195,iot1,70

timestamp,iotid,humidity
-------------------------
    1501230195,iot1,45

timestamp,iotid,pressure
-------------------------
    1501230195,iot1,850

クエリに関しては、1つの値だけを取得することも、3つも同時に取得することもできました。

16
grunk

どちらのスキーマ設計でも正しいか間違っているかはありませんが、1つの測定で1つのフィールド値を使用するのがより適切なアプローチです。

なぜ?

複数のフィールド値をmeasurementに格納することは、非常にリレーショナルなデータベースです。つまり、measurementは非常に異なるものであるため、database tableと見なすべきではありません。

測定は、温度やCPU使用率などのデータのタイプを説明するために明示的に予約する必要があります。

measurementごとにone field valueを使用してスキーマを設計すると、データを実際の英語で記述できます。

あるpointの時点で、気温はmeasuredとしてdata value=30になります。ここで使用されている用語pointdataおよびmeasurementに注目してください。

一方、複数のfield valuesを特定のmeasurementに入れると、dataを実際の英語で提示することが難しくなります。

influxdbは時系列データベースなので、time-seriesの方法で実行する必要があることは明らかです。

また、時系列データの一部は、実際にはマイクロ秒の精度レベルまで測定されます。このような細かいタイミングでは、millisecondsであっても、データのセットが同じタイミングを共有することはほとんどありません。したがって、データポイントのシーケンスを含む1つの測定として設計することは、常により良い選択です。

8
Samuel Toh

少し古い質問ですが、これはおそらくTSDBで作業している人に関係があります。

私が最初に始めたとき、私のアプローチは、すべてのデータポイントが単一のフィールド測定に入るというものでした。後で、SQLステートメントで必要なデータを組み合わせると想定していました。ただし、influxのようなTSDBを使用している人は誰でも、TSDBの実装に使用される設計上の選択により、データの取得にはいくつかの重大な制限があることを知っています。

私がプロジェクトを進めてきたので、私が開発した経験則は次のとおりです。

測定には、意味をなすために必要なすべての寸法が含まれている必要がありますが、それ以上は含まれていません。

例:3つの信号を提供するガス流量計を想像してください:

  • 体積流量
  • 温度
  • 総流量

このシナリオでは、体積流量と温度は1つの測定の2つのフィールドである必要があり、総流量は独自の測定である必要があります。

(読者がこの例を好まない場合は、アンペアとボルト、およびkwとpfを出力する家庭用電気メーターを考えてください)。

体積と温度を異なるシリーズで保存するのはなぜ悪いのでしょうか?

  1. タイミング:これら2つの測定値を異なるシリーズで保存すると、それらは異なるインデックス値(タイムスタンプ)を持ちます。タイムスタンプが明示的に指定されていることを確認するように注意しない限り、タイムスタンプがわずかにオフサンプリングされるリスクがあります。データに体系的な測定バイアスを導入している可能性があるため、これは最終的には悪いこと(tm)になる可能性があります。それが悪いことではなくても、後でこのデータを再利用したい場合(たとえば、csvファイルにダンプする場合)は、非常に煩わしくなります。

  2. ユーティリティ:体積流量を推定する場合は、正しい値を取得するためにconstant * temp * volumeを取得する必要があります。たとえば、influxdbは操作をサポートしていないため、2つの別々の測定でこれを行うことは悪夢になります。ただし、そうした場合でも、いずれかのフィールドの欠損値が正しく処理されていないこと、およびグループ化と集計が正しく行われていることを確認する必要があります。

3つすべてを1回の測定で保存するのが悪いのはなぜですか?

常に3つの値すべてを監査したいユースケースがあるかもしれませんが、そうではない可能性があり、希望するのと同じ種類の頻度で合計ボリュームを測定する必要はありません流れ自体を測定します。

すべてのフィールドを1回の測定に入れると、特定のフィールドにnullを入れるか、ほとんど変化しない変数を常にログに記録するように強制されます。いずれにしても、効率的ではありません。

重要な洞察は、多次元エンティティがすべての次元を同時に必要とするということですtimeを理解するために。

6
MB.

これはおそらくデータに依存します。両方を試して、ストレージ要件を確認してください。たとえば、湿度があまり変化しない場合は、湿度を分離することが理にかなっています。しかし、いくつかの変数が同様の時間間隔で変化する場合は、それらを組み合わせることが理にかなっています。また、クエリパターンによって異なる場合もあります。

3
denfromufa

私は有効な3番目のオプションがあることを言及しようと思いました:

timestamp,iotid,measure,value
----------------------------
1501230195, iot1, temperare, 70
1501230195, iot1, humidity, 45
1501230195, iot1, pressure, 850
2
Francesco Meli