Question

我正在开发一个网站，其中记录每个客户所做的每一次点击和每次展示都很重要。

所以我有一个数据库，其中包括（其中包括）两个表：“点击”和“印象”。 “印象”表格具有以下结构：

ip int unsigned not null,
ts int unsigned not null,
main_post int unsigned not null,
side_post int unsigned not null,
PRIMARY KEY (ip,ts,main_post,side_post)

因此列数很少而且它们都是int类型，因此它是一个高效的表。但是，令我担心的是，这张桌子的速度会快得令人难以置信。对于每个请求，此表中将添加五个新行，因为每个主帖旁边总是有五个侧面帖子。另外，对于每个请求，我都要检查此表，以确保我没有再向客户显示相同的帖子。

“点击”表格类似，但不太极端（每个请求只添加一行）。

所以我的问题是：这会是多少？经过几周或几个月的使用后，这张桌子会变得太大而无法处理吗？如果是，那么最佳解决方案是什么？也许每周或每个月开一张新桌子？

提前致谢

Answer 1

您每天要处理多少次点击？
每天有多少次展示？
你要记录多长时间？
如果用户一个月没有访问，您是否需要知道他上次访问时看到了什么？
如果用户一周没有访问该怎么办？

对这些问题和相关问题的回答将决定您的需求。但是，如果您的网站变得非常受欢迎并且您认为自己确实需要很长的历史记录，那么该表将变得无法管理。你有一个每行16个字节的表;你有一个索引，可能会花费你每行20-24字节（有一点开销）。因此，对于每个页面展示，您将在展示次数表中使用200个字节左右。每秒N页，你将使用大约20×N MiB /天。

我不清楚你将如何构建对这个表的查询，以确保用户不再显示相同的材料。我不知道你是否认为IP是IP地址（你听说过IPv6吗？）而TS是时间戳。我不相信IP地址是跟踪用户的合适方式（同一个用户可能在一天中有多个IP地址 - 从办公室和家里连接，更不用说咖啡店了）。我不确定PK索引会对您的查询有多大帮助。

当您知道如何使用数据时，您可以决定如何存储数据。

我强烈怀疑你会觉得这个设计过于繁琐。该表足够大，您的查询将大大减慢您的速度。是的，我相信您需要仔细管理表格，定期丢弃旧数据，同时保留最新数据。

Answer 2

无论您使用哪种归档方法，重要的是规范化任何重复数据，这对于OLTP数据通常总是一个好主意。标准化将有助于您看到相同的主要和侧面帖子相关联。

其中一种方法可能会有所帮助，但不了解您的数据，很难知道。

*主要帖子总是与相同的侧柱相关联（听起来不是这样）。这会将您的桌子减少到当前尺寸的20％：

-- same impressions table minus side_post

-- table side_post
main_post int unsigned not null,
side_post int unsigned not null,
order int unsigned not null,
PRIMARY KEY (main_post,side_post)

*主要职位与不同的副职位相关联。这种方法也会减少主表

-- same impressions table minus side_post and add key
main_side_post int unsigned not null

-- table side_post
main_side_post int unsigned not null --PK
-- rest of columns from table side_post above

Answer 3

首先，如果表是InnoDB，则添加auto_increment作为主键，其余作为唯一键。这样，写入将是顺序的，而不是随机的，并且在大表（GB的大小）中，它非常重要。

接下来，在时间戳上对表进行分区，它会使表保持较小，并且查询驻留在同一分区上的一段数据将会很快。

接下来，请记住，您正在将读取负载转换为写入负载！（每个访问者都写到页面）。更好地聚合内存中的数据并执行更少的写入。特别是当同一个访问者刷新页面时 - 不要再次访问数据库。 Read here some tips

这张桌子太大了吗？

3 个答案: