4

センサーデータを保存・可視化するアプリの再開発を考えています。アプリケーションには複数のユーザーがアクセスでき、センサーを無制限に追加できます。現在、ユーザーは 10 人で、約 1000 個のセンサーがあります。ユーザー数はおそらく変わらないでしょう。十分な電力 (ソーラー パネル) がある場合、センサーは 5 秒ごとにデータを送信します。

現在、データは 4 つのテーブルに格納されています。

  • ユーザー [ID、メール、パスワードなど]
  • デバイス [id, name, user_id] user_id: 外部キー
  • センサー [id, device_id, type] device_id: 外部キー
  • Data [id, sensor_id, time, data] sensor_id: 外部キー

問題は、Data テーブルが非常に大きくなることです。目標は、ほぼ 1 年間データを保持することです。私は MySQL を使用していますが、そのパフォーマンスに非常に失望しています。現在、Gunicorn でフラスコを使用しており、RabbitMQ を使用して格納手順をキューに入れています。既存のシステムのパフォーマンスを向上させるために変更できることはありますか? このことをゼロから始めた場合、どのような変更を加えますか? この状況で NoSQL は大きな違いを生むでしょうか? 私はあまりにも多くを求めていますが、この種の問題に直面したのは初めてです。

4

4 に答える 4

3

  1. 1k のセンサーがあり、それぞれが 5 秒ごとにデータを生成するため、 Akkaのようなフレームワークを使用して多くのリクエストを処理し、多くのスレッドの問題を回避する良い例のように思えます

  2. 処理ステージが最適化されたように見えたら、NoSQL について正しく記述しました。コメントの中でインデックスの欠落について言及されていましたが、テーブルが 1 つしかないinsertため、テーブルごとにすべてのデータのインデックスの再計算がトリガーされる可能性があります。これにより、アプリのスループットが低下する可能性があります。

    この問題を解決する方法はたくさんあります。テーブルを最後に分割して最新のデータを含めるか、2 つのテーブルを使用します。1 つは読み取りとクエリ用、もう 1 つは書き込み用で、2 番目から 1 番目への一括挿入と一緒に使用します。カットオフ インデックスを使用すると、これは間違いなく高速です。両方ではなく、大量の読み取りまたは大量の書き込み用にストレージを最適化できるというよく知られた問題があります。

    または、NoSQL を見ることができます。特に Redis が頭に浮かびます。データ型を見てくださいhttp://redis.io/topics/data-types-intro

    Redis は本質的に長いリストをサポートしています。クエリをサポートしていないため、必要なクエリを提供SELECT ... FROM ... WHERE ...するには、独自のインデックスとキャッシュを提供する必要があります。key:value ストアの使用方法に興味がある場合は、Twitterのデモをご覧ください。Twitter はあなたと同じ問題を解決しなければなりません。

これが私の最後のポイントになります。より優れたスケーラビリティを提供したいが、その方法がわからない場合は、facebook、twitter、または netflix アーキテクチャを見てください。

于 2013-08-30T06:31:13.807 に答える
1

Martin Podval として NoSql を検討する必要がありますが、ここでもいくつかのトリックを試すことができます。まず、データを複数のテーブルに分割し始めます。最も頻繁に使用される時間範囲に応じて、1 つのテーブルを 1 週間または 1 か月に分割できます。次に、時間範囲については、複数のテーブルにクエリを実行し、結果を結合する必要があります (小さな map&reduce ジョブ) が、小さなテーブルに対する複数のクエリは、大きなテーブルに対する単一のクエリよりも高速であることが証明されます。

2 番目の秘訣は、テーブルのインデックス作成を最適化し、JOIN 操作を絶対に避けることです。

最後に、キャッシングを追加することができます。これは非常に古いトリックであり、多くの議論がありますが、1000 個のセンサーで 1 年間 10 人のユーザーが同じデータを複数回見る可能性が高いと思います。

最良の解決策は、NoSQL ソリューションを使用するだけではなく、分散型のソリューションを使用することだと思います。安価なサーバーでもパフォーマンスが向上します。計算すると、1 年間で約 63 億のレコードが必要です。どんなに高速なコンピュータでも、どのようなシステム (ストレージ システム) を使用していても、メモリからでもデータを読み取るには長い時間がかかります。

于 2013-08-30T06:59:09.967 に答える
1

テレメトリ データに関する議論は、業界で既に実証されているソリューションを議論せずには完了しません。

HDF5はそのようなソリューションの 1 つです。HDF5 は、テレメトリ データを格納および管理するためのデータ モデル、ライブラリ、およびファイル形式です。無限の種類のデータ型をサポートし、柔軟で効率的な I/O と大量の複雑なデータ向けに設計されています。

SQL Server には、大規模なテレメトリ データ セットの処理に特に適したFILESTREAMデータ型があります。McClaren Systems はこれを使用して、F1 レースカーからテレメトリー データを収集します。

FileStream McClaren のケース スタディ
を使用したプログラミング

于 2013-08-31T18:19:45.443 に答える