要聚合或不聚合,这是数据库架构设计问题

Question

如果您正在进行min/max/avg查询,是否更喜欢使用聚合表或只是在原始表中的一系列行中进行查询？

这显然是一个非常开放的问题,没有一个正确的答案,所以我只是在寻找人们的一般性建议.假设原始数据表包含时间戳,数字外键(例如用户ID)和小数值(比如购买金额).此外,假设表中有数百万行.

我已经完成了两件事并且被撕裂了.一方面,聚合表给了我明显更快的查询,但代价是增加了额外的表.显示聚合范围的当前值要么完全退回到原始数据表,要么组合更细粒度的聚合.我发现在应用程序代码中跟踪哪个聚合表来查询何时需要更多工作,并且需要进行模式更改,因为原始聚合范围总是不够("但我想看到我们在过去3个工资期内的销售额!").

另一方面,从原始数据查询可能会非常缓慢,但让我对数据范围非常灵活.当范围边界发生变化时,我只需更改查询而不必重建聚合表.同样,应用程序代码需要更少的更新 我怀疑,如果我对我的索引更加智能(即总是具有良好的覆盖索引),我将能够减少从原始数据中选择的惩罚,但这绝不是灵丹妙药.

无论如何,我可以充分利用这两个世界吗？

Answer 1

我们遇到了同样的问题，也遇到了您遇到的同样的问题。我们最终将报告转向 Analysis Services。MDX 和分析服务本身有一个学习曲线，但效果很好。我们发现的一些好处是：

1. 您可以非常灵活地以任何您想要的方式进行查询。之前我们必须构建特定的聚合，但现在一个立方体可以回答我们所有的问题。
2. 立方体中的存储远小于详细数据。
3. 与聚合相比，构建和处理多维数据集花费的时间更少，并且在数据库服务器上产生的负载也更少。

一些缺点：

1. 构建多维数据集和学习 MDX 有一个学习曲线。
2. 我们必须创建一些工具来自动处理立方体。

更新：既然您使用的是 MySql，您可以看看Pentaho Mondrian，它是一个支持 MySql 的开源 OLAP 解决方案。不过我从来没有用过它，所以我不知道它是否适合你。有兴趣知道它是否适合您。