ここで少し混乱しています...ミリ秒ごとに読み取りを行う特定のセンサーの配列であるプロジェクトに参加するように提案されています（はい、1秒間に1000回の読み取り）。読み取り値は、818 や 1529 などの 3 桁または 4 桁の数字です。この読み取り値は、サーバー上のデータベースに保存し、リモートでアクセスする必要があります。
私はこれほど大量のデータを扱ったことはありませんが、1 つのセンサーから 1 日に読み取られる MB はどれくらいになると思いますか?... 4(桁)x1000x60x60x24 ... = 345600000 ビット ... ですよね? 1 日あたり約 42 MB … それほど悪くはないようですよね?
したがって、たとえば 1 GB の DB には、1 つのセンサーからの 23 日間の情報が保持されますよね?
MySQLとPHPはおそらくそれを処理できないことを理解しています...あなたは何を提案しますか、おそらくいくつかのAP? 紺碧？オラクル？
3 桁または 4 桁の数字 =
4 bytes if you store it as a string.
2 bytes storing it as a 16bit (0-65535) integer
1000/sec -> 60,000/minute -> 3,600,000/hour, 86,400,000/day
as string: 86,400,000 * 4 bytes = 329megabytes/day
as integer:86,400,000 * 2bytes = 165megabytes/day
特に同じデータに対して頻繁に選択を実行している場合は、そのような挿入負荷の下ではDB のパフォーマンスが低下する可能性があります。大規模な検索用に DB を最適化すると、高速/頻繁な挿入の速度が低下します。一方、単純な整数の挿入は、正確には「ストレスの多い」操作ではありません。
おそらく、一時データベースに挿入して、メインの「アーカイブ」データベースに1時間ごとに大量コピーを行う方がよいでしょう。そのデータが最大 1 時間古いことを理解して、そのメイン アーカイブ テーブルで分析/マイニングを行います。
しかし、最終的には、これらすべてのバリエーションをベンチマークし、特定のユース ケースに最適なものを確認する必要があります。データベースランドには、「Y を達成するために X を実行する必要がある」タイプのアドバイスはありません。
ほとんどの場合、このように高度に離散化されたデータを長期間保持する必要はありません。いくつかのオプションを使用して、ボリュームを最小限に抑えることができます。まず、一定期間が経過すると、時間単位のデータを最小/最大/平均値にまとめることができます。検出されたいくつかの不安定な状況、または定義により詳細なデータを保持する必要がある状況についてのみ、詳細な情報を保持できます。また、多くのことがイベント ログに変換される場合があります。これらのアプローチは、数十年前に私が当時働いていた会社によって提供されたいくつかの産業オートメーションシステムで実装され、成功裏に使用されました. 利用可能なストレージ デバイスのサイズは、現在のサイズよりも数倍小さかった.
したがって、まず、保存するデータを分析してから、そのストレージを最適化する方法を決定する必要があります。
@MarcBの数値に従うと、1kHzで2バイトは、2KB /秒、つまり16Kビット/秒になります。これはそれほど問題ではありません。
賢明で柔軟なアプローチは、センサーの読み取り値のキューを作成することであると思います。このキューは、データベースが明確になるまで単純にポップできます。これらのデータレートでは、問題はスループット（ダイヤルアップモデムで処理できる）ではなく、タイミング間のギャップです。システムキャッシング値は、次の値が格納されるのに十分な速さで邪魔にならないようにする必要があります。特にGC干渉がある場合は、1msが戻るのに長くはかかりません。
キューの利点は、一方の端でキューに何かを追加するのが安価であり、もう一方の端で値を一括処理できることです。したがって、センサー側は必要な応答性を取得し、データベースは一括処理されます。
リレーショナル データベースが必要ない場合は、mongodb のような NoSQL データベースを使用するか、Java を使用している場合はJDBM2のような単純なソリューションを使用できます。