我有一张表可以跟踪文章视图。它包含以下列：
id, article_id, day, month, year, views_count.
假设我想跟踪每篇文章的每日观看次数。如果我有1000个用户写的文章。行数将计算为：
365 (1 year) * 1,000 => 365,000
哪个也不错。但是，请说。文章数量增长到1M。随着时间的推移，到了3年。行数将计算为：
365 * 3 * 1,000,000 => 1,095,000,000
显然，随着时间的推移，这张桌子会继续增长。并且非常快。这会引起什么问题？或者我不应该担心，因为RDBM处理这种情况很常见吗？
我计划在报告中使用观看数据。要么将其分解为数月甚至数年。我应该担心表格中的1B +行吗？
答案 0 :(得分：5)
问自己（或您的利益相关者）的问题是：您是否真的需要对旧数据进行1天分辨率？
了解MRTG等产品如何通过RRD进行日志记录。理论上，您不会无限期地以最大分辨率存储所有数据，但会定期将它们汇总为越来越大的摘要。
这使得你可以在最后5分钟内获得1秒的分辨率，然后是最后一小时的5分钟平均分，然后是每小时一天，每天一个月，依此类推。
所以，例如，如果你有一堆像这样的记录用于一篇文章：
year | month | day | count | type
-----+-------+-----+-------|------
2011 | 12 | 1 | 5 | day
2011 | 12 | 2 | 7 | day
2011 | 12 | 3 | 10 | day
2011 | 12 | 4 | 50 | day
然后，您将定期创建一个汇总这些数据的新记录，在此示例中只是该月的总计数
year | month | day | count | type
-----+-------+-----+-------|------
2011 | 12 | 0 | 72 | month
或者每天的平均值：
year | month | day | count | type
-----+-------+-----+-------+------
2011 | 12 | 0 | 2.3 | month
当然，您可能需要一些标志来指示数据的“汇总”状态，在这种情况下，我使用“类型”列来查找“原始”记录和处理过的记录，允许您清除当天记录所需。
INSERT INTO statistics (article_id, year, month, day, count, type)
SELECT article_id, year, month, max(day), sum(count), 'month'
FROM statistics
WHERE type = 'day'
GROUP BY article_id, year, month, type
（我没有测试过该查询，只是一个例子）
答案 1 :(得分：3)
答案是“它取决于”。但是，可能需要处理很多事情。
然而 - 这通常是“当你需要时越过那座桥梁”的问题。如果这将成为您未来的问题，那么考虑一下您可以做什么是一个好主意。但是在实际需要之前实施任何建议可能为时尚早。
我的建议是，如果它发生的话，就是不要将个人记录保留超过X个月（根据您的需要调整X）。相反，您可以将当前提供的汇总数据存储到报告中。你要做的就是运行一个每日脚本来查看你的记录并抓取任何超过X个月的任何东西......并创建某种类型的“daily_stats”对象，然后删除原件（或者更好的是，将它们归档到某处。）
这将确保数据库中只有X个月的数据 - 但您仍然可以快速访问长时间线报告的统计数据形式。
答案 2 :(得分：2)
如果您可以采取一些措施，那么您不必担心这一点。
如果您的团队中有DBA，那么您可以与他/她讨论，我相信他们会很乐意提供协助。
此外，就像在许多数据仓库中使用的那样，我刚看到@Taryn的帖子（我同意 - ＆gt;）也存储聚合数据。根据您在相关表格中保留的数据，可以快速建议这样做。如果您在编辑/更新记录时遇到问题，那么它就会发现（甚至更多）这样的事实：您只需要设置限制，例如要保留多少数据（这意味着这些数据可以修改）并且程序+作业到位以确保每天检查/更新聚合数据，并且可以在进行任何更改时手动更新/检查。这样，保持了数据完整性。与您的DBA讨论您可以采取的其他方法......
顺便说一句，如果您还不知道。每周或每月报告通常需要汇总数据，而许多其他报告则基于间隔。根据需要将您的聚合粒度化，但不要过于单调乏味或看似夸张。