PLCデータをSQL Serverデータベースに保存する
多くのPLC（コンベヤベルトやロボットなどの産業機械の制御に使用されるプログラマブルロジックコントローラー）からの生データポイントをSQL Serverデータベースに保存する必要があるソフトウェアソリューションを開発しています。私の主な関心事は、大量の生の数値データを適切に保存する方法です。
各データポイントには次のプロパティがあります。
- スタンプされた日時
- 次のいずれかです：ブール、整数、浮動小数点、または文字列
- データポイントは1年を通して毎秒保存できます（年間約31,536,000データポイント）
データを収集する各PLCには500ものデータポイントがあり、数千のPLCをサポートすることを計画しています。つまり、少なくとも年間15,768,000,000,000データポイント（年間31,536,000ポイント* 500ポイント* 1000 plcs）があります。現在、各データ型（bool、int、float、string）のテーブルがあります。レコードとストレージの数を減らすために、レコードごとに4つのデータポイント[ID、DateTime、DataGroupID、Value1、Value2、Value3、Value4]を保存しています。
私はこれを実装しましたが、それはうまくいきます（最大のテーブルを約7,200万レコードにして高速クエリを実行）。等。）
したがって、柔軟性を向上させるための私の考えは、データ型固有のテーブルを保持することですが、各データポイントを独自のレコードとして単に格納することです。 bigint（レコードIDのデータ型）の最大サイズの簡単な計算から、利用できるIDがたくさんあることがわかりました。ただし、ストレージ要件、およびクエリのパフォーマンスは依然として問題です。この方法を使用して何かを心配する必要がありますか？より良いオプションはありますか？
私の懸念の根源は、巨大なデータベース/テーブルを経験したことがないということです。そのため、数百万のレコードが小さいことはわかっていますが、それでもオーバーザトップテーブルがどのようになるかわかりません。さらに、データの保存は私のソフトウェアの基礎であるため、更新を行うには多くの作業が必要になります。
基本から始めましょう：
リレーショナルデータベースに年間16兆の生データポイントを保存する必要がありますか？おそらくそうではありません。後でそれをどうするか、そしてそれらのクエリがどのようになるかを考えてください。リレーショナルデータベースは、他のテーブルとの関係があり、頻繁に挿入/更新/削除したり、一般的なレポートツールで読み取ったりする必要があるデータに最適ですが、ここではあまり適していません。
RDBMSで実行しない場合、どこで実行しますか？時系列データベースに対応 、設計されたものこの正確な目的のために。例には Graphite および InfluxDB が含まれます。
それを行う必要があった場合、何に注意する必要がありますか？あらゆる種類のメンテナンスが非常に困難になります-インデックスの再構築、統計の更新、バックアップ、CHECKDBなど。代わりに、データがより小さなボリュームに分割される動的シャーディング設計を検討してください。たとえば、データウェアハウジングレルムでは、大きなテーブルは通常、日付範囲（2017Q3、2017Q2、2017Q1など）で分割されるため、新しい受信データ用の新しい列を追加する必要がある場合は、現在のテーブルを変更するだけで済みます。レポートの目的で、すべてのテーブルを結合して1つのビューにすることができますが、1兆行のテーブルに対するあらゆる種類のアドホッククエリが困難である可能性があることに注意してください。 （天国は、誰かが注文を希望し、サポートするインデックスがない場合に役立ちます-さようなら、tempdbドライブ領域です。）