mysql - 我应该担心表中的 1B+ 行吗？

Question

我有一个记录文章浏览量的表格。它有以下列:

id, article_id, day, month, year, views_count.

假设我想跟踪每篇文章的每日浏览量/每一天。如果我有 1,000 篇用户撰写的文章。行数将计算为:

365 (1 year) * 1,000 => 365,000

这还不算太糟糕。但是说吧。文章数量增长到1M。而随着时间的流逝，3年过去了。行数将计算为:

365 * 3 * 1,000,000 => 1,095,000,000

显然，随着时间的推移，这个表会不断增长。而且相当快。这会造成什么问题？或者我不应该担心，因为 RDBM 经常处理这样的情况？

我计划在我们的报告中使用浏览量数据。要么将其分解为数月甚至数年。我应该担心表中的 1B+ 行吗？

Answer 1

要问自己(或您的利益相关者)的问题是:您真的需要 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

(我还没有测试过那个查询，这只是一个例子)