数据库：聚合与存储预先计算的数据以在大型数据存储中查找？答案

【问题标题】：database: aggregation vs storing pre computed data for lookup in large data store?数据库：聚合与存储预先计算的数据以在大型数据存储中查找？
【发布时间】：2018-04-21 11:21:23
【问题描述】：

我们有一个包含 200 万条记录的表，并以每分钟 30 条记录的速度插入新行。

表结构为： |投诉 |手机 |请求日期时间| .我们收到投诉、用户的手机和当前日期，并将其保存在此表中。我们可以在这个表中有多行具有相同的移动设备。

只有在过去 30 天内来自同一“手机”的请求少于 12 个时，我们才需要保存新记录。我们在这里使用三种方法来计算特定移动设备的记录数：

每次插入新记录之前，首先在数据库中运行聚合查询以检查我们是否已经有 12 条具有该数量的记录。如果是，请不要插入新的。这里的问题是查询的性能。
或在一天结束后存储此数据，即过去 29 天内具有相同手机号码的行在表中，仅在当天运行聚合，然后将两者相加以检查其是否小于 12。

或者有人可以为此提出更好的解决方案吗？

【问题讨论】：

标签： mysql performance database-design database-performance

【解决方案1】：

另一种更好的方法可能是：

1) 在每个 EOD，维护一个移动负面清单表（投诉数 > 12）。

2) 如果记录是该列表的一部分，您将永远不会处理它。甚至您可以将这些记录缓存在内存中（取决于您使用的技术）并避免一起调用数据库。

3) 或者，您可以安排一个批次（比如每小时），这可以使用其他项目和缓存更新负面列表。

基于 cmets 编辑

4) 如果你在负数表中没有找到记录，继续你的正常计数逻辑。

5) 您可以扩展 LRU（最近最少使用）缓存策略，以将频繁记录的计数保留在内存中，以避免进行数据库调用。确保在主数据库中插入 12 条记录后立即将记录刷新到否定列表中。

【讨论】：

这里有几个问题 1. 如果有人在一小时内轰炸数据库，你会从同一个号码中获得多条记录 2. 在 eod，我们需要在非常大的数据集上运行作业，即插入的每个号码过去 29 天
对于 EOD 的大型数据集案例，如果我理解正确，您已经在计算工作时间内每条记录插入的 29 天数据！在非工作时间运行一次计数不应占用该时间。

【解决方案2】：

我将提出即时检查的论据...

这是查询，对吗？

SELECT COUNT(*)
    FROM tbl
    WHERE num = 1234
      AND datetime >= NOW() - INTERVAL 30 DAY;

您每秒拥有的INSERT 少于一个。
查询不应返回超过 12 个，对吗？
使用INDEX(num, date)，SELECT 的速度非常快。
现在您的查询速度为 60 个查询/分钟（1/秒）。（一个SELECT +（通常）一个INSERT）直到超过 100/秒，事情才会变得冒险。
BTree 索引非常有效，并且受表大小的影响不大。因此，2M 行不是一个因素。 20 亿也不会。
我建议此解决方案比其他选择更简单。亲吻。

（我是汇总表的大力支持者，但我不能在这里证明它的合理性。）

【讨论】：

查询有可能返回大于 12 的现有记录。与最初一样，它被允许推送尽可能多的行。它可能高达 200，但一个月后，它将是 12
将LIMIT 12 添加到我建议的查询中，因为您只需要区分“=12”。（无论如何，200 不会比 12 慢太多。）
感谢您的帮助。在这种情况下，我们应该使用汇总表，即当性能优先时，考虑汇总表方法的阈值应该是多少
这里只需要触摸12行就可以暴力破解。假设它是 12K，那么每日小计（在汇总表中）可能是明智的（然后只有 30 行可触及）。或者也许 120K 会是一个更好的阈值；我没有真实的号码。另一个考虑因素：您的 2M 行可能适合缓存（参见 innodb_buffer_pool_size），因此不需要 I/O。