私は自分の会社のRoRプロジェクトの設計に取り組んでおり、開発チームはすでに設計、特にデータベースについて少し議論をしています。
永続化する必要があるMessage
というモデルがあります。 id以外のdb列が3つしかない非常に小さなモデルですが、本番環境に移行するとこれらのモデルが大量に存在する可能性があります。 1日に最大1,000,000の挿入を探しています。モデルは、インデックスを作成できる2つの外部キーによってのみ検索されます。同様に、モデルを削除する必要はありませんが、約3か月経過したモデルを保持する必要もありません。
したがって、このテーブルをPostgresに実装するとパフォーマンスに重大な問題が生じるのではないかと考えています。これが問題になるかどうかを教えてくれる非常に大きなSQLデータベースの経験はありますか?もしそうなら、どの代替案を採用すべきでしょうか?
テーブルごとの行は、それ自体では問題になりません。
したがって、90日間で1日に約100万行を言うと、9000万行になります。あなたが何をしているかの詳細を知らずに、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億1800万行を超えるテーブルがあり、30倍の改善が見られました。
また、非常に大きなテーブルの場合、外部キーにインデックスを作成することをお勧めします。