PostgreSQLテーブルには大きすぎますか？

私は会社のRoRプロジェクトの設計に取り組んでおり、私たちの開発チームは、設計、具体的にはデータベースについて、少々議論を交わしています。

Message永続化する必要のあるというモデルがあります。これは、id以外にdb列が3つしかない非常に小さなモデルですが、本番環境に移行すると、これらのモデルが大量に存在する可能性があります。1日に最大100万件の挿入が見られます。モデルは、インデックスを作成できるモデル上の2つの外部キーによってのみ検索されます。また、モデルを削除する必要はありませんが、約3か月経過したモデルを保持する必要はありません。

では、このテーブルをPostgresに実装するとパフォーマンスに重大な問題が発生するのではないかと思います。これが問題になるかどうかを教えてくれる非常に大規模なSQLデータベースの経験がある人はいますか？もしそうなら、私たちはどの代替案を使うべきですか？

テーブルごとの行は、それ自体では問題になりません。

つまり、1日あたり100万行を90日間とすると、9千万行になります。Postgresがこれに対処できない理由はないと思います。

データの分散に応じて、インデックス、フィルター処理されたインデックス、および何らかの種類のテーブルパーティションを組み合わせて使用​​することで、パフォーマンスの問題が発生する場合と発生しない場合に、速度を上げることができます。あなたの問題は、私が知っている他のどのRDMSでも同じです。データを削除するプロセスで3か月分のデータ設計のみが必要な場合は、これ以上必要ありません。これにより、テーブルに一定量のデータが含まれます。幸運なことに、どれだけのデータが存在するかがわかっているので、ボリュームをテストして、何が得られるかを確認します。9000万行の1つのテーブルをテストするのは、次のように簡単です。

select x,1 as c2,2 as c3
from generate_series(1,90000000) x;

https://wiki.postgresql.org/wiki/FAQ

Limit   Value
Maximum Database Size       Unlimited
Maximum Table Size          32 TB
Maximum Row Size            1.6 TB
Maximum Field Size          1 GB
Maximum Rows per Table      Unlimited
Maximum Columns per Table   250 - 1600 depending on column types
Maximum Indexes per Table   Unlimited

1億行を超えるテーブルでクエリを大幅に高速化する別の方法は、営業時間外に、クエリで最も頻繁に使用されるインデックスでテーブルをクラスタ化することです。2億1,800万行を超えるテーブルがあり、30倍の改善が見られました。

また、非常に大きなテーブルの場合は、外部キーにインデックスを作成することをお勧めします。