用于存储统计数据的数据库表结构答案

【问题标题】：Database table structure for storing statistics data用于存储统计数据的数据库表结构
【发布时间】：2016-03-23 18:57:34
【问题描述】：

我正在尝试在我的 MYSQL 数据库中创建一个表，用于每天将点击数据存储到我的帖子中，我想出的是这样的：

ID | post_id | click_type | created_date
1    1         page_click   2015-12-11 18:13:13
2    2         page_click   2015-12-13 11:16:34
3    3         page_click   2015-12-13 13:24:01
4    1         page_click   2015-12-15 15:31:10

对于这种类型的存储，我可以获得 1 号帖子在 2015 年 12 月获得的点击次数，甚至可以知道帖子编号在 12 月 15 日下午 1 点到 11 点之间获得的点击次数。但是，假设我每天获得 2000 次点击，这意味着它将每天创建 2000 行，这意味着每月 60.000 次和每年 720.000 次。

我想到的另一种方法是这样的，每个帖子存储一行一天，如果当天点击超过一次，它会增加计数

ID | post_id | click_type | created_date | count
1    1         page_click   2015-12-11     13
2    2         page_click   2015-12-11     26
3    3         page_click   2015-12-11     152
4    1         page_click   2015-12-12     14
5    2         page_click   2015-12-12     123
6    3         page_click   2015-12-12     163

在这种方法中，如果每天至少点击一次页面（这意味着创建行），它将每天生成 1000 行（假设我有 1000 个帖子），每月生成 30.000 行，每年生成 360.000 行。

我正在寻找有关如何存储这些统计信息以及是否要获取每日点击统计信息的建议。我对性能有些担忧（当然这对大数据人员来说没什么：D，但很抱歉我缺乏经验）。如果 2-3 年后该表中有超过 100 万行，您认为可以吗？你认为哪一个对我更有效？

【问题讨论】：

Summary Tables

标签： mysql database database-design

【解决方案1】：

每年 720,000 条记录不一定是很多数据。一种选择可能是不用担心。需要考虑的可能是点击数据的重要性。如果一年后您不再关心，那么您可以使用历史数据清理协议来删除比您关心的更早的数据。

如果您担心存储大量数据并且不想删除历史记录，那么您可以考虑预先计算汇总统计数据并将其存储起来，而不是存储交易详细信息。

问题在于，您必须提前知道您将继续关心的最小时间分辨率是多少。此外，如果您的动机是节省空间，那么您必须小心，您的摘要数据最终不会占用比原始交易更多的空间。如果您以多种分辨率存储汇总数据，这很容易发生，就像在数据仓库安排中一样。

【讨论】：

【解决方案2】：

这似乎是 rrdtool (http://oss.oetiker.ch/rrdtool/) 的一个很好的应用程序。在这里您可以为不同的时间间隔指定多个分辨率，例如：

1 天平均 5 分钟
1 周平均 30 分钟
1 个月平均 2 小时
1 年平均 1 天

等等。这也经常用于图表。通常这与rrd-files一起使用，但也可以基于mysql 使用rrdgraph_libdbi

【讨论】：