我正在为我的公司设计一个RoR项目，我们的开发团队已经遇到了一些关于设计的争论，特别是数据库。
我们有一个名为Message的模型需要持久化。这是一个非常非常小的模型，除了id之外只有三个db列，但是当我们投入生产时，可能会有很多这样的模型。我们每天有多达100万次的插入。模型只会被两个可以被索引的外键搜索。同样，这些模型永远不会被删除，但我们也不必在它们三个月大的时候保留它们。
所以，我们想知道的是，在Postgres中实现这个表是否会带来重大的性能问题?有没有人有使用大型SQL数据库的经验告诉我们这是否会是个问题?如果是的话，我们应该选择什么?
每个表中的行本身不会成为问题。
所以粗略地说，每天100万行，持续90天就是9000万行。我不认为Postgres不能在不了解您所做事情的所有细节的情况下处理这些问题。
Depending on your data distribution you can use a mixture of indexes, filtered indexes, and table partitioning of some kind to speed thing up once you see what performance issues you may or may not have. Your problem will be the same on any other RDMS that I know of. If you only need 3 months worth of data design in a process to prune off the data you don't need any more. That way you will have a consistent volume of data on the table. Your lucky you know how much data will exist, test it for your volume and see what you get. Testing one table with 90 million rows may be as easy as:
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.18亿行的表，并发现了30倍的改进。
此外，对于一个非常大的表，在外键上创建索引是个好主意。
例子:
假设我们在名为ccbank的数据库中有一个名为investment的表。 假设查询中最常用的索引是(bandkid,record_date)
下面是创建和聚类索引的步骤:
"drop index investment_bankid_rec_dt_idx; 创建索引investment_bankid_rec_dt_idx (bankid, record_date); "cluster investment_bankid_rec_dt_idx on investment;" Vacuumdb -d ccbank -z -v -t investment
在步骤1-2中，我们用一个新的优化的索引替换旧的索引。在步骤3中，我们将表聚类:这基本上是将DB表按索引的物理顺序放置，这样当PostgreSQL执行查询时，它就会缓存最有可能的下一行。在第4步中，我们清空数据库以重置查询计划器的统计信息。
