对于依赖于时间的大型数据集，命名表september_2010是否可接受且有效？

Question

我需要每天存储大约73,200条记录，包括3个数据点：id，date和integer。

我团队的一些成员建议使用月份作为表名创建表（september_2010），而其他人建议使用一个包含大量数据的表...

有关如何处理此数据量的任何建议？感谢。

==========感谢您的所有反馈。

Answer 1

我建议反对。我称之为antipattern 元数据Tribbles 。它会产生多个问题：

• 您需要记住每年创建一个新表，否则您的应用会中断。
• 无论年份如何，都要对所有行查询聚合更难。
• 更新日期可能意味着将一行从一个表移到另一个表。
• 很难保证伪表单在多个表中的唯一性。

我的建议是将它保存在一个表中，除非你已经证明表的大小正在变成一个真正的问题，并且你无法以任何其他方式解决它（例如缓存，索引，分区）。

Answer 2

好像把它放在一张桌子里就好了。它将使检索在将来更容易维护1个表，而不是每年12个表。每天73,200条记录，将需要将近4年的时间达到100,000,000，这仍然在MySQL的能力范围内。

Answer 3

绝对不是。
它会毁掉桌子之间的关系 表关系是基于字段值构建的，而不是表名。

特别是对于这个仅增长300Mb /年的桌子

Answer 4

所以在100天内你有7.3 M行，一年约25M左右。 25M行不再是很多了。 MySQL可以处理数百万行的表。这实际上取决于您的硬件和查询类型以及查询频率。

但是您应该能够对该表进行分区（如果MySQL支持分区），您所描述的是旧的SQL Server分区方法。在构建这些月度表之后，您将构建一个视图，将它们连接在一起，看起来像一个大表...这实际上是分区所做的，但它都是封闭的并且完全优化。

Answer 5

通常这会产生比它更值得的麻烦，更多的维护，你的查询需要更多的逻辑，并且从多个时期提取数据是痛苦的。

我们在一个（MyISAM）表中存储了2亿多个基于时间的记录，并且查询仍然非常快。

你只需要确保你的时间/日期列上有一个索引，并且你的查询使用索引（例如，在日期列上使用DATE_FORMAT或类似的查询可能不会使用索引。我不会为了恢复性能，不要把它们放在单独的表格中。

对于如此大量的记录而言非常痛苦的一件事是，当您必须删除旧数据时，这可能需要很长时间（例如，在数百个表中擦除一个月的数据时需要10分钟到2个小时）竖（）行。出于这个原因，我们有partitioning个表，并使用time_dimension（参见例如time_dimension表，有点向下here）关系表来管理句点而不是简单的日期/日期时间列或字符串/ varchars代表日期。

Answer 6

  

我团队的一些成员建议使用月份作为表名创建表（september_2010），而其他人建议使用一个包含大量数据的表...

不要听他们说。你已经存储了一个日期戳，不同月份的情况如何以一种方式分割数据是一个好主意？引擎将处理较大的数据集，因此按月拆分只会人为地隔离数据。

Answer 7

我的第一反应是：Aaaaaaaahhhhhhhhhh !!!!!!

表名不应嵌入数据值。你没有说数据意味着什么，但是为了争论起见，我不知道温度读数。试想一下，试图写一个查询来查找上个月平均温度上升的所有月份。你必须遍历表名。更糟糕的是，想象一下试图找到所有30天的时期 - 即可能跨越月界的时期 - 温度在过去的30天内增加。

实际上，只检索旧记录将来自一个简单的操作 - “select * where id = whatever” - 将成为一个复杂的操作，要求您让程序从动态日期生成表名。如果您不知道日期，则必须扫描所有表格，搜索每个表格以获得所需的记录。呸。

将所有数据放在一个正确规范化的表中，像上面这样的查询非常简单。每个月都有单独的桌子，这是一场噩梦。

只需将日期作为索引的一部分，并且在一个表中包含所有记录的性能损失应该非常小。如果表的大小确实成为一个性能问题，我可以简单地理解为一个表创建存档数据与所有旧的东西和一个当前数据与您定期检索的一切。但是不要创建数百个表。大多数数据库引擎都有使用“表空间”等方式跨多个驱动器对数据进行分区的方法。如有必要，请使用数据库的复杂功能，而不是将原始模拟混合在一起。

Answer 8

取决于您需要执行的搜索。如果通常受日期约束，则拆分是好的。

如果您进行拆分，请考虑将表格命名为foo_2010_09，以便表格按字母数字排序。

Answer 9

你的数据库平台是什么？

在SQL Server 2K5 +中，您可以按日期进行分区。

我的不好，我没注意到标签。虽然@thetaiko是正确的，但这完全符合MySQL处理这个问题的能力。

Answer 10

我想说这取决于数据的使用方式。如果大多数查询都是在完整数据上完成的，那么总是将表再次连接在一起将是一种开销。 如果您大多数时候只需要一部分数据（按日​​期），那么将表格分成更小的部分是个好主意。

对于命名，我会做tablename_yyyymm。

编辑：当然，您还应该考虑数据库和应用之间的另一个层来处理分段表，具体取决于给定的日期。然后哪个会变得非常复杂。

Answer 11

我建议放弃一年，每个月只有一张桌子，以月份命名。通过重命名所有表$ MONTH_ $ YEAR并重新创建月份表，每年归档您的数据。或者，由于您正在为数据存储时间戳，因此请继续添加到相同的表中。我假设您首先要问的是，按月分隔您的数据符合您的报告要求。如果没有，那么我建议将其全部保存在一个表中，并在性能成为问题时定期归档历史记录。

Answer 12

我同意这个想法，不必要地使你的数据库复杂化。使用单个表格。正如其他人所指出的那样，这些数据远远不足以进行外部处理。除非您使用SQLite，否则您的数据库将很好地处理它。

但是，它还取决于您希望如何访问它。如果旧条目实际上仅用于归档目的，那么归档模式是一个选项。版本控制系统通常会将不经常使用的数据分离出来。在你的情况下，你只需要1年> 1年就可以离开主表。这严格来说是数据库管理任务，而不是应用程序行为。应用程序只会加入当前列表和_archive列​​表（如果有的话）。同样，这在很大程度上取决于用例。是否通常需要旧条目？是否有太多数据需要定期处理？