sql – 需要数据库设计建议

我每天插入一个表~200万行,然后这些表每月进行存档和压缩.每个月表包含~15,000,000行.虽然这个月逐月增加.

对于我上面的每个插入,我将来自属于一起的行的数据组合并创建另一个“相关”表.此表目前尚未归档,因为我需要确保永远不会错过相关表的更新. (希望这是有道理的)虽然一般来说,这些信息在处理几天后应该保持相当静态.

所有这些都是完美的.然而,我的公司现在希望针对这些数据执行一些统计数据,并且这些表格变得太大而无法在合理的时间内提供结果.即使设置了适当的索引.

所以我想在完成上述所有问题后我的问题很简单.我应该编写一个脚本,将相关表中的数据分组到较小的表中.或者我应该将查询结果集存储在memcache之类的内容中？我已经在使用mysqls缓存了,但是由于对数据存储时间的控制有限,所以它并不理想.

我可以看到使用memcache之类的主要优点：

>查询兑现后,我的关联表上没有阻塞.
>在后端收集器之间共享收集的数据的更大灵活性
和前端处理器. (即自定义报告可以写在
后端和这些结果存储在缓存下的一个键中
然后与想要查看此报告数据的任何人共享
>如果我们开始与大量客户共享此数据,那么冗余和可扩展性.

我可以看到使用memcache之类的主要缺点：

>如果重新启动计算机/刷新缓存,则数据不会持久.

使用MySql的主要优点

>持久数据.
>减少代码更改(尽管添加
像memcache这样的东西是微不足道的
无论如何)

使用MySql的主要缺点

>每次我想存储时都必须定义表模板,提供一组新的分组数据.
>必须编写一个循环相关数据并填充这些新表的程序.
>随着数据的不断增加,潜在的增长速度仍然会放缓.

抱歉相当长的问题.无论如何,这有助于我写下这些想法,并且非常感谢处理这类问题的任何建议/帮助/经验.

非常感谢.

艾伦

解决方法

您的问题的这一点表明,这里的根本问题是结果的速度：

However my company now wishes to
perform some stats against this data,
and these tables are getting too large
to provide the results in what would
be deemed a reasonable time.

在结果速度很重要的情况下,在问题上抛出更好/更多的硬件往往比开发新的代码/数据库结构/等更便宜.

只是一个想法！

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!