我们正在一个自定义的OpenX广告服务器上运行一个MySQL数据库,这得到了大约。每天点击100万次。我们需要存储所有这些点击信息并显示基于它的统计信息。
现在,所有的点击信息每两天聚合一次,并删除特定的点击信息。但我们希望为我们的子公司提供一个新的功能,这将使他们能够设置一个动态跟踪id (TID),基本上,跟踪他们的点击和转换的基础上。
因此,问题是,我们的click表每天将增加至少100万个条目,我们需要能够搜索这个表,并显示一个用户在特定时间内的所有点击,按上面提到的TID分组,或者按TID进行搜索。
我看了一下MySQL分区,它似乎是一个很好的解决方案,但是,我不确定它在一个巨大的数据库(可能有数十亿个条目)上是否仍能很好地工作。
你认为什么是解决这个问题的正确方法?
编辑:
基于你的回答,我现在想的是一个混合的解决方案。
我们已经有了一个“活动”表,当单击在维护时聚合时,从该表中删除条目,该表如下所示:
表:单击
viewer_id .,date_time,affiliate_id,affiliate_id. tid
(我跳过了这一点不重要的列)
在维护时,我可以将所有内容移动到另一个月表中,它看起来几乎是相同的,例如,affiliate_id表: clicks_2012_11,它为date_time、和tid提供了索引,并由affiliate_id.进行分区。
因此,现在,当一家子公司希望看到他过去两个月的统计数据时,我知道我必须查看表: clicks_2012_10和Table: clicks_2012_11 (我的时间范围将限制在最多2个月)。因为我有由affiliate_id,分区的表,所以只会从两个表中搜索所需的分区,现在我可以列出在过去两个月中有任何活动的所有TID。
,你对这种方法有什么看法?有什么明显的问题吗?我是不是没有充分的理由就把事情复杂化了?
发布于 2012-10-29 14:11:34
大表(甚至是“巨大的”表)中没有任何使MySQL失败的固有内容。从以下方面看,大表主要是一个问题:
你需要解决所有这些问题。
分区主要用于大容量数据维护,例如删除整个分区。在默认情况下,仅在某一列上对大表进行分区并不是最佳做法。分区的引入总是出于特定的原因。
发布于 2012-10-29 14:16:09
插入的优化和检索的优化通常是相互排斥的。最好有两张桌子:
live data: no (or minimal) keys, myisam to remove transaction overhead, etc...
historical data: indexed up the wazoo, with data moved over from the live data on a periodic basis.https://stackoverflow.com/questions/13120925
复制相似问题