AI エージェント向け: ドキュメントインデックスは https://www.mongodb.com/ja-jp/docs/llms.txt で利用できます。すべてのページの markdown バージョンは、いずれかの URL パスに .md を追加することで利用できます。

IoT データのモデル化

IoT(Internet of Things)は、物理オブジェクトのネットワークであり、インターネットに接続されています。これらのデバイバイスの多くは、センサーなどのようにデータを生成します。

このデータを効率的に保存および取得するには、 バケット パターンを使用できます。

IoT データを整理する一般的な方法は、データをバケットにグループ化することです。 バケット化により、特定のデータグループが整理され、次のことが可能になります。

  • 履歴傾向の検出、

  • 将来の傾向を予測する

  • ストレージの使用を最適化します。

データをグループ化するための一般的なパラメーターは次のとおりです。

  • 時間

  • データソース(複数のデータセットがある場合)

  • CUSTOMER

  • データの型(例: 金融データのトランザクションの種類)

注意

MongoDB 5.0 以降では、時系列コレクションは時系列データに推奨されるコレクション タイプです。 パフォーマンスを低下させる可能性があるため、バケット パターンを時系列コレクションと組み合わせて使用しないでください。

センサーから取得した温度データを保存するコレクション を考慮します。 センサーは 1 分ごとの温度を記録し、そのデータをtemperaturesというコレクションに保存します。

// temperatures collection { "_id": 1, "sensor_id": 12345, "timestamp": ISODate("2019-01-31T10:00:00.000Z"), "temperature": 40}{ "_id": 2, "sensor_id": 12345, "timestamp": ISODate("2019-01-31T10:01:00.000Z"), "temperature": 40}{ "_id": 3, "sensor_id": 12345, "timestamp": ISODate("2019-01-31T10:02:00.000Z"), "temperature": 41}...

このアプローチでは、データとインデックスのサイズの点ではスケーリングができません。 たとえば、アプリケーションにsensor_id フィールドとtimestamp フィールドのインデックスが必要な場合、パフォーマンスを向上させるには、センサーからのすべての受信読み取りをインデックス化する必要があります。

document modelを活用して、特定のタイムスパンの測定値を保持するドキュメントにデータをバケット化できます。 1 分ごとに取得された読み取りを 1 時間のグループにバケット化する次の更新されたスキーマを検討してください。

{ "_id": 1, "sensor_id": 12345, "start_date": ISODate("2019-01-31T10:00:00.000Z"), "end_date": ISODate("2019-01-31T10:59:59.000Z"), "measurements": [ { "timestamp": ISODate("2019-01-31T10:00:00.000Z"), "temperature": 40 }, { "timestamp": ISODate("2019-01-31T10:01:00.000Z"), "temperature": 40 }, ... { "timestamp": ISODate("2019-01-31T10:42:00.000Z"), "temperature": 42 } ], "transaction_count": 42, "sum_temperature": 1783}

この更新されたスキーマは、スケーラビリティを向上させ、アプリケーションが実際にデータを使用する方法をミラーリングします。 ユーザーは特定の温度読み取り値をクエリしない可能性が高くなります。 代わりに、ユーザーは 1 時間または 1 日にわたる温度動作をクエリする可能性が高くなります。 バケット パターンは、データを均等な期間にグループ化することで、これらのクエリを容易にします。

サンプルドキュメントには、 transaction_countとsum_temperatureの 2 つの計算フィールドが含まれています。 アプリケーションが特定時間の温度の合計を頻繁に取得する必要がある場合は、合計の実行中の合計を計算することでアプリケーションのリソースを節約するのに役立ちます。 この 計算パターン アプローチにより、データが要求されるたびに合計を計算する必要がなくなります。

事前集計されたsum_temperatureとtransaction_countの値を使用すると、特定のバケットの平均温度( sum_temperature / transaction_count )などのさらなる計算が可能になります。 ユーザーは、午後 2 時 3 分の特定の温度をクエリするのではなく、午後 2 時から午前 3 時 00 分の間の平均温度をアプリケーションでクエリする可能性がはるかにあります。 特定の値をバケット化して事前計算することで、アプリケーションはその情報をより簡単に提供できます。

MongoDB はデフォルトで UTC で時刻を保存し、すべてのローカル時間表現をこの形式に変換します。 変更されていないローカル タイム値を操作またはレポートする必要があるアプリケーションは、UTC タイムスタンプとともにタイム ゾーンを保存し、アプリケーション ロジックで元のローカル タイムを計算する場合があります。

MongoDB shell では、現在の日付と現在のクライアントの UTC からのオフセットの両方を保存できます。

var now = new Date();db.data.insertOne( { date: now, offset: now.getTimezoneOffset() } );

保存されたオフセットを適用することで、元のローカル時間を再構築できます。

var record = db.data.findOne();var localNow = new Date( record.date.getTime() - ( record.offset * 60000 ) );