この数はあなたが思っているほど高くはありません。現在の作業では、Webサイトのメトリックデータを保存しており、行の総数ははるかに多くなっています。以前の仕事では、モバイルネットワークからメトリックを収集するpgデータベースを使用し、1日あたり約20億のレコードを収集しました。したがって、数十億のレコードを恐れないでください。
あなたは間違いなくデータを分割する必要があるでしょう-おそらく日ごとに。この量のデータを使用すると、インデックスがまったく役に立たないことがわかります。 EXPLAINに表示される飛行機によって異なります コマンド出力。たとえば、telcoアプリは、エンジン全体の速度を低下させるだけなので、インデックスをまったく使用しませんでした。
もう1つの質問は、必要なクエリへの迅速な応答です。また、ユーザーに許可するクエリの粒度（時間/日/週などの合計）のステップ。週、月、四半期などの粒度の集計を行う必要がある場合もあります。
追加：
そのtelcoアプリの1日あたり約20億のレコードは、1日あたり約290GBを要しました。また、COPYコマンドで一括挿入を使用して1秒あたり最大23000レコードを挿入することを意味しました。すべてのバルクは数千のレコードでした。生データは分単位で分割されました。ディスクの待機を回避するために、dbには4つの異なるディスク/アレイ上に4つのテーブルスペースがあり、パーティションがそれらに分散されていました。 PostreSQLは問題なくすべてを処理することができました。したがって、適切なHW構成についても検討する必要があります。
また、pg_xlogディレクトリを別のディスクまたはアレイに移動することもお勧めします。別のファイルシステムだけではありません。それはすべて別々のハードウェアでなければなりません。 SSD適切なエラーチェックのあるアレイでのみ推奨できます。最近、単一のSSD上のデータベースが破損しているという問題が発生しました。