sql - 需要数据库设计建议

Question

我是一家电信公司的独立开发人员，我正在向任何有时间回答的人寻求一些数据库设计建议。

我每天向一个表中插入约 200 万行，然后每月对这些表进行归档和压缩。每个月表包含约 15,000,000 行。尽管这个数字逐月增加。

对于我在上面执行的每个插入操作，我都将属于同一行的数据组合起来并创建另一个“相关”表。该表当前未存档，因为我需要确保我不会错过对相关表的更新。 (希望这是有道理的)尽管一般来说，这些信息在经过几天的处理后应该保持相当稳定。

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

所以我想毕竟我的问题很简单。我是否应该编写一个脚本，将相关表中的数据分组到较小的表中。或者我应该将查询结果集存储在内存缓存之类的东西中吗？我已经在使用 mysqls 缓存，但由于对数据存储时间的控制有限，因此效果不理想。

我可以看到使用像 memcache 这样的东西的主要优点:

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

我可以看到使用像 memcache 这样的东西的主要缺点:

• 如果机器重新启动/缓存被刷新，数据将不持久。

使用MySql的主要优点

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

使用MySql的主要缺点

• 每次我想存储提供一组新的分组数据时都必须定义表格模板。
• 必须编写一个循环遍历相关数据并填充这些新表的程序。
• 随着数据的不断填充，增长速度可能仍会变慢。

很抱歉问了一个很长的问题。无论如何，在这里写下这些想法对我很有帮助，任何处理此类问题的建议/帮助/经验都将不胜感激。

非常感谢。

艾伦

Answer 1

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

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

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.

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

只是一个想法!