数据库设计 : storing many large reports for frequent historical analysis

Question

我是一名资深程序员，对 DBMS 或设计数据库的经验很少。

我知道有类似的帖子，但今晚我感到很困惑。

我正在从事一个项目，该项目需要我每天多次存储大量报告，而且还没有处理过这种规模的存储或表格。请允许我以通用的方式描述我的问题:

过程:

• 一个脚本收集大约 300 行信息，设置 A，每天 2-3 次。这些行的结构永远不会改变。这些行包含两列，均为整数。
• 该脚本还同时收集了大约 100 行信息集 B。这这些行的结构也没有改变。这些行包含八列，都是字符串。

我需要存储所有这些数据。 Set A 将经常使用，并且每天用于分析。集合 B 将在收集当天频繁使用，然后在未来有节制地用于历史分析。理论上我可以为每一行存储一个时间戳以供以后查询。

如果线性存储，两组数据都在各自的表中，使用 DBMS，数据每年将达到约 30 万行。由于对 DBMS 经验不多，这对于管理两个表来说听起来很高大上。

我觉得好像在脚本的每次传递中将此信息放入数据库会导致读取时间变慢和一般响应速度变慢。例如，生成一个 Access 数据库并将此信息放入两个表中似乎是一种过于简单的解决方案。

我想我的问题是:就性能而言，多少行对于一个表来说太多了？我知道为每一天或每一月创建表格的品味很差。

当然这只会融入我的下一个但类似的问题审计日志...

Answer 1

300 行，每天大约 50 次，持续 6 个月，对于任何数据库来说都不是什么大障碍。您要使用哪个数据库？大多数人会很容易地处理这个负载。如果每个表的数据行数超过几亿，则有几种技术可以处理数据碎片。但是通过有效的索引和清理，您可以获得您想要的性能。我自己每周处理超过 2 亿行的繁重数据表。确保根据您为获取该数据而发出的查询设置了索引。无论你在 where 子句中有什么，都应该在 db 中为它有一个适当的索引。

如果您每个表的行数超过数百万，您应该查看表的分区 数据库实际上将文件系统中的数据存储为文件，因此分区将有助于根据某些谓词制作更小的数据文件组，例如:日期或某些独特的列类型.您会将其视为单个表，但在文件系统上，数据库会将数据存储在不同的文件组中。那你也可以试试表分片。这实际上就是您提到的....基于某些谓词(如日期)的不同表。

希望这对您有所帮助。