エネルギーデータ(ガス/電力消費、電力供給)を保存するシステムをリファクタリングしています。データは、将来変更される可能性のあるスキーマで15分ごとに絶対データをポストするセンサーから取得されます(読み取り:ドキュメントストレージが必要です)。
生データはMongoDBデータベースに保存されます。バックグラウンドプロセスがこのデータを読み取り、MySQLデータベースにさまざまな解像度で格納されている構造化デルタデータに変換します。
MongoDBスキーマ:| device_id (uint) | timestamp (ISODate) | data (unspecified object) |
MySQLスキーマ:(複数のテーブル:hour
、day
、month
、year
)| device_id (uint) | timestamp (datetime) | gas_consumption | electricity_consumption | ... |
MongoDB data
フィールドが定義を変更すると、バックグラウンドプロセスがデータのバージョンを検出し、それに応じて処理します。 MySQLデータベースは、MongoDBデータから再作成される場合があり、新しいスキーマが使用される場合があります(将来必要になる場合があります)。
新しい状況では、時系列データベースを使用したいと思います(これは多くの外部関係者から提案されているため)。アトミック(データベース)レベルで実装したい機能が2つあります。
要件:
典型的なクエリは次のようになります(疑似コード):SELECT <fields> BETWEEN <start-date> AND <end-date> WITH RESOLUTION <time-resolution>
。
時系列をサポートするいくつかのデータベース(InfluxDB、MongoDB、Graphite、RRDtool、Redis、OpenTSDBなど)を見てきましたが、さまざまな解像度やギャップフィリングをネイティブでサポートするデータベースが見つかりません。
MongoDBはオプションである可能性がありますが、書き込みはファイアアンドフォーゲットです。つまり、欠落データは検出されない可能性があります。生データの場合、これが頻繁に発生しない限り、これは問題ではありません。処理されたデータの場合、これは大きな問題です。アプリケーションの残りの部分では、非常にまれなEdgeの場合でも、これらのテーブルのデータはシーケンシャルであると想定しています。
MySQLもオプションになります(たとえば、初期実装を変更しないなど)が、時系列データベースは理由によって時系列データベース用に最適化されているように感じます。
現在の状況は良いアプローチですか?そうでない場合、何がより良いでしょうか?私のユースケースは時系列を保存する世界でそれほどユニークではないように感じますが、正しい方向にプッシュすることができるリソースをオンラインで見つけることができないようです。
カリフォルニアエネルギー委員会(UT3、または niversal Translator 3)の同様のアプリケーションに取り組みました。いくつかのポイント: