センサーアレイから大量のデータを保存する

私は、巨大なセンサーアレイからのデータサンプルを保存するソリューション（appおよびdb）を実装することを任されました。アレイは現在約20,000個のセンサーで構成されていますが、まもなく100,000個のセンサーに拡大します。各センサーは10秒ごとにデータサンプルを送信し、各サンプルのサイズは28バイトです。

したがって、合計を行うと、次のようになります。

• 1日あたりセンサーあたり8640サンプル
• 1日あたりセンサーあたり242kBのデータ
• 1日あたり864百万サンプル

今、データを保存/取得する最善の方法は何だろうと思っていますか？ソフトウェアが既に指定された後、私はこのプロジェクトに「参加」したので、SQL Serverを使用してWindowsプラットフォームに実装する必要があります。

私の頭の中の現在の解決策は、データサンプルを格納する2つのテーブルを持つDBを作成することです。1つ目は2つ目のインデックスの一種として機能し、センサーごとに1日あたりのバイナリフィールドに照合サンプルを格納します。

Table 1:

  RecordID - BigInt - Identity
  SensorID - BigInt - Primary Key
  Date - DateTime - Primary Key (yyyy-mm-dd)

Table 2:

  RecordID - BigInt - Primary Key (from an insert into Table 1)
  Data - Binary 

基本的に、すべてのセンサーのサンプルを一時ファイル（センサーごとに1つ）に書き込みます。毎日の終わりに、表1のエントリを作成し、生成されたRecordIDを使用して、ファイルを表2のデータフィールドにダンプします。

この方法では、8億4400万エントリではなく、1日あたり100,000エントリしかテーブルに登録されません。データはLANまたは高速WANで利用可能である必要があります。そのため、1日単位でセンサーデータを取得できます。

すべてのデータを保存する必要がありますが、ほとんどのデータはおそらく読み込まれません。そのため、テーブルの読み取りの量は書き込みよりも大きくなることはありません。

データファイルへのパスを保存するだけで、ファイルシステムを使用して何かを実装できることは知っていますが、バイナリフィールドが256kB未満の場合、SQL ServerはNTFSよりも優れていることを読みました。（256 KBと1 MBの間には灰色の領域がありますが、1 MBを超えるバイナリサイズの場合、NTFSはSQL Serverよりもはるかに優れています）。

また、100,000個のセンサーからのデータを独自のファイルに保存する場合、フォルダー内に大量のファイルがあるか、各フォルダーにいくつかのファイルがある複雑なツリー構造を持つことにより、ファイルシステムに問題を引き起こすことはありません。ファイルの断片化も考慮します。

1. 誰でも上記に関する実用的なアドバイス/コメントを提供できますか？

2. 私が陥りそうな明らかな落とし穴はありますか？

3. サンプルデータは非常にうまく圧縮されています。242 kBファイルは約85kBに圧縮されます。ただし、サンプルデータ（列）が自動的に圧縮されるように、データベースレベルで何らかの圧縮を実装できますか？

4. このプロジェクトでは、SQL Serverは明らかに間違った選択肢ですか？

5. 2つのテーブルの設計は賢明ですか、それとも2つのテーブルと同じように「パフォーマンス」の高い単一のテーブルに組み合わせることができますか？

はい、かなり迅速に遭遇するかなり大きな落とし穴があります。それはテーブルのサイズとメンテナンスに関係しています。毎日一時テーブルにデータを入れてから、永続テーブルに移動したいと言うことで、ある程度正しい軌道に乗っていますが、すぐにこのスキームで問題が発生します。

たとえば、2年後に最も古い月のデータを「ロールオフ」したいとします。設計では、大きな大きなテーブルに対してDELETEステートメントを発行する必要があります。インデックスの数にもよりますが、これはおそらく多少遅くなります。また、インデックスの断片化を引き起こします。これを修正する唯一の方法は、この非常に大きなテーブルのインデックスを再構築または再編成することであり、これもパフォーマンスの問題を引き起こします。大きな単一テーブル型の設計には、他にも多くの問題があります。たとえば、大きな単一のテーブルでは、FILEGROUPベースのバックアップを実行できません。つまり、データベースの完全バックアップが必要な場合、BIGになり、完了するまでに時間がかかります。

解決策は何ですか？ テーブルのパーティション分割。これについては、できる限り多くの場所で詳しく読んでください。基本的に、パーティショニングを使用すると、データを「テーブル内のテーブル」に分割できます。各パーティションは同じスキーマを共有し、テーブルオブジェクトを介してアクセスされますが、インデックスの作成方法と保守方法は異なります。パーティションは基本的にテーブルであり、いくつかの便利なキーによって分割されます。あなたの場合、おそらく日付になります。それらは、テーブルと同じように（そして同じくらい速く）ドロップできます。つまり、ビッグデータテーブルを日付ごとにパーティション化すると、他のパーティションのインデックスに悪影響を与えることなく、古いパーティションを即座にドロップできます。パーティションを異なるファイルグループに配置できます。つまり、古いパーティションをロールオフするか、一般的に使用されていない場合は安価なコモディティストレージにロールオンできます。最後になりましたが、SQL 2012では古い読み取り専用パーティションでは、すべてのセンサーデータを挿入するアクティブパーティションで、より挿入指向の異なるインデックススキームを使用します。

お役に立てれば。パーティショニングとパーティショニングスキームに関して行うべき多くの研究がありますが、今、あなたが見なければならない方向を知っていることを願っています。

PS：ああ、私はあなたの質問の箇条書きリストを忘れました...答え1、2、5。上記を参照してください。回答3：SQL Serverでは、パーティション単位でパーティションを圧縮できるため、PAGE圧縮を使用して古いパーティションを積極的に圧縮します。しかし、これを行うと行外の大きなデータ型は圧縮されないと思います-繰り返しますが、センサー値を正規化することでこの問題を軽減することができます。回答4：絶対にそうではありませんが、静的データを1日ごとに保存し、それ以外の方法で検索したくない場合は、圧縮されたフラットファイルを使用する方がはるかに簡単です。

PPS：ああ、もう一つ。これをすべて機能させるために、2つのテーブルのソリューションは必要ありません。その値が「記憶させることができるので、大規模なバイナリセンサデータは、タイプVARBINARY（MAX）でなければならない行のうち」それでも（参照単一のテーブル内の列であるsp_tableoptionのドキュメントを）。ただし、そうしないとデータベースがセンサーデータのチャンクを時間で取得する以上のことには向かないため、テーブルにあるバイナリデータからセンサーデータの一部を正規化することを検討する必要があります。

Hadoopソリューションを検討してください。2 Tb /日がすぐに追加されます。また、デルタレコード（つまり、初期値）のみを記録し、変更が発生した場合のみ記録することも検討してください。