現在、マイクロコントローラーからセンサー出力を読み取り、Hibernateを使用して毎秒複数のPostgresテーブルに書き込むプロジェクト（Javaで記述）があります。合計で、毎秒約130列分のデータを書き込みます。データが書き込まれると、データは永久に静的なままになります。このシステムは、現在の状況では正常に動作しているようです。
私の質問は、将来このデータをクエリして平均化するための最良の方法に関するものです。実行可能だと思ういくつかのアプローチがありますが、どれが最適にスケーリングおよびパフォーマンスするかについてのインプットを探しています。
毎秒データを収集して書き込むため、月に250万行以上を生成することになります。現在、このデータは、JChart2Dに書き込むJDBC selectステートメントを介してプロットされています（つまり、SELECT圧力、温度、速度FROMデータWHERE time_stamp BETWEEN startTime AND endTime）。ユーザーは、長すぎる期間（startTimemおよびendTime delta <1日）を指定しないように注意する必要があります。そうしないと、クエリが実行されるまで数分（またはそれ以上）待つ必要があります。
将来の目標は、GoogleFinanceを強化するGoogle視覚化APIと同様のユーザーインターフェースを持つことです。時間スケーリングに関しては、つまり、期間が長くなるほど、データは「よりスムーズ」（またはより平均化）になります。
私が検討したオプションは次のとおりです。
オプションA： SQL avg関数を使用して、平均化されたデータポイントをユーザーに返します。ユーザーがたとえば半年間データを表示するように要求した場合、このオプションは高額になると思います。このシナリオのインターフェースは、ユーザーの要求に基づいて平均する行数をスケーリングすると思います。IEは、ユーザーが1か月のデータを要求した場合、インターフェイスは86400行ごとに平均を要求し、最大30データポイントを返します。一方、ユーザーが1日のデータを要求した場合、インターフェイスは2880行ごとに平均を要求します。 30個のデータポイントを返しますが、より細かくなります。
オプションB： SQLを使用して時間間隔内のすべての行を返し、Javaインターフェースを使用してデータを平均化します。私はこれをキックについて簡単にテストしましたが、要求されたインターバル時間の1日あたり86400行を返すため、コストがかかることがわかっています。SQL選択を実行するときに考慮していないことがない限り、これは実行可能なオプションではないと思います。
オプションC：このデータはすべて、書き込まれると静的であるため、Javaプログラム（Hibernateを使用）を使用して、現在書き込んでいるデータとともに平均のテーブルも書き込むことを検討しました。このオプションでは、データを「蓄積」して平均化し、指定された間隔（5秒、30秒、1分、1時間、6時間など）でテーブルに書き込むJavaクラスがいくつかあります。将来のユーザーインターフェイスプロットプログラムは、ユーザーが指定した時間間隔を取り、クエリする平均のテーブルを決定します。このオプションは、多くの冗長性を作成し、より多くのストレージスペースを必要とするように見えますが、（私の考えでは）最高のパフォーマンスが得られますか？
オプションD：より経験豊富なコミュニティからの提案？