需要数据库设计建议

Ala*_*lis 7 mysql sql memcached caching

我是一家电信公司的独立开发人员,我正在接受任何有一点时间回答的人的数据库设计建议.

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

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

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

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

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

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

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

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

使用MySql的主要优点

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

使用MySql的主要缺点

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

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

非常感谢.

艾伦

cod*_*ike 2

除了上面讨论的选项之外,您可能还想考虑添加更强大的硬件(如果可以的话)。

你的问题表明这里的根本问题是结果的速度:

然而,我的公司现在希望针对这些数据执行一些统计,并且这些表变得太大,无法在合理的时间内提供结果。

在结果速度很重要的情况下,在问题上投入更好/额外的硬件通常比开发新代码/数据库结构/等更便宜。

只是一个想法!