聚合还是不聚合，这是数据库架构设计的问题答案

【问题标题】：To aggregate or not to aggregate, that is the database schema design question聚合还是不聚合，这是数据库架构设计的问题
【发布时间】：2010-12-29 16:18:08
【问题描述】：

如果您正在执行最小/最大/平均查询，您更喜欢使用聚合表还是简单地跨原始表中的一系列行进行查询？

这显然是一个非常开放的问题，没有一个正确的答案，所以我只是在寻找人们的一般建议。假设原始数据表由时间戳、数字外键（比如用户 ID）和十进制值（比如购买金额）组成。此外，假设表中有数百万行。

我都做了，我很伤心。一方面，聚合表给了我更快的查询速度，但代价是增加了额外的表。显示聚合范围的当前值要么需要完全返回原始数据表，要么需要组合更细粒度的聚合。我发现在应用程序代码中跟踪查询哪个聚合表的时间比您认为的要多，并且需要更改架构，因为原始聚合范围总是不够的（“但我想看看我们在过去 3 个付款期的销售额！”）。

另一方面，从原始数据中查询可能会非常缓慢，但让我对数据范围非常灵活。当范围边界发生变化时，我只需更改查询，而不必重建聚合表。同样，应用程序代码需要更少的更新。我怀疑如果我在索引方面更聪明（即始终具有良好的覆盖索引），我将能够减少从原始数据中进行选择的代价，但这绝不是万能药。

有没有我可以两全其美？

【问题讨论】：

我通常使用 MySQL，但希望人们的提示适用于所有 SQL 数据库。
@pr1001：在某种程度上这是一个普遍的问题，但是一些数据库提供了使这个问题变得更容易的机制（例如 Oracle 的“物化视图”），所以这样做“正确”将是数据库- 特定程度

标签： sql performance indexing aggregation maintainability

【解决方案1】：

我们遇到了同样的问题，也遇到了您遇到的同样问题。我们最终将报告切换到分析服务。 MDX 和分析服务本身有一个学习曲线，但它非常棒。我们发现的一些好处是：

您有很大的灵活性查询任何你想要的方式。在我们之前必须建立特定的聚合体，但现在一个立方体回答了我们所有的问题问题。
立方体中的存储空间要小得多比详细的数据。
构建和处理多维数据集花费更少的时间和更少的产出数据库服务器上的负载比聚合确实如此。

一些缺点：

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

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

【讨论】：

+1 用于提及 Pentaho。参与 Pentaho 的一些人来自 Cognos of BI。

【解决方案2】：

它有助于选择一个好的主键（即 [user_id, used_date, used_time]）。对于恒定的 user_id，在 used_date 上执行范围条件会非常快。

但是随着表的增长，您可以通过聚合到像 [user_id, used_date] 这样的表来减小表大小。对于时间无关紧要的每个范围，您都可以使用该表。另一种减小表大小的方法是归档您不再（允许）查询的旧数据。

【讨论】：

【解决方案3】：

我总是倾向于原始数据。一旦聚合，您就无法返回。
与删除无关 - 除非有最简单的聚合数据集，否则您无法准确地将数据恢复/转置回原始数据。

理想情况下，我会使用物化视图（假设数据可以符合约束条件），因为它实际上是一个表。但 MySQL 不支持它们，因此下一个考虑将是具有计算列的视图，或更新实际表的触发器。

【讨论】：

我错过了他建议聚合和删除原始数据的部分吗？当然，原始数据需要保留。但除了原始数据，一些聚合数据也可以存储。
@marcc：我在哪里说要删除原始数据？
@Ponies：也许当你说一旦聚合就无法返回:)
@Daniel：这与删除无关。当我从SUM(col1 * col2) 获得一个值时，数据集越大，我就越不可能将该值恢复为它所包含的值。