数据库设计：存储大量大型报表，用于频繁的历史分析

Question

我是一名资深程序员，对 DBMS 或设计数据库几乎没有经验。

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

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

过程：

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

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

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

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

我想我的问题是：就性能而言，一个表有多少行是太多行？我知道为每天或每月创建表格会很糟糕。

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

Answer 1

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

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

希望这会有所帮助。

Answer 2

你想多了。 300k 行并不重要。几乎任何关系数据库或 NoSQL 数据库都不会出现任何问题。

您的设计听起来不错，但是，我强烈建议您利用数据库的功能为每一行添加一个主键，使用您可用的任何功能。通常这涉及使用 AUTO_INCREMENT 或序列，具体取决于数据库。如果你使用像 Mongo 这样的 nosql，它会为你添加一个 id。关系理论依赖于拥有一个主键，拥有一个用于诊断通常很有帮助。

所以你的基本设计是：

表 A tableA_id |一个 |乙|创建于

表 B tableB_id |列… |创建于

CreatedOn 将促进日期范围查询，限制数据以进行汇总，并允许您按日期边界（天、周、月、年）进行 GROUP BY。

如果您要进行这种类型的分组，请确保您在 CreatedOn 上有一个索引。

此外，对任何列使用最小的数据类型。例如，如果整数的范围低于特定限制或为非负数，您通常可以选择一种可以减少所需存储量的数据类型。