join - Mondrian/OLAP 是连接大尺寸/集合的错误工具吗？

Question

简介: 我见过的大多数 MDX 连接示例都涉及连接相对较小的集合，例如每个集合包含数十或数百个项目。但我发现自己也想尝试加入(特别是“非空加入”)每个有数千或数万个项目的集合，但到目前为止效果不佳。我想知道这是否可以工作，或者我是否可能需要考虑使用 Mondrian/OLAP 以外的其他东西。

具体来说，我有一个多维数据集，用于记录公司 (n=7000) 和客户 (n=27000) 之间的交互。目前 Firm 和 Client 都是完全扁平的层次结构；有所有级别和个人公司级别，中间没有其他级别。有一个中央事实表，以及公司和客户的单独维度表。

我的用户至少似乎想要按照这些方式获得汇总报告，汇总公司和客户之间的所有非空交互:

select
  [Measures].[Amount] on columns,
  NonEmptyCrossJoin([Firm].Children,
                      [Client].Children) on rows
from MyCube

但是这个查询及其变体在我的测试蒙德里安设置中不起作用。要么我得到 OutOfMemoryException(在 2GB Java 堆上)，要么 Java 似乎在 mondrian.rolap.RolapResult$AxisMember.mergeTuple(TupleCursor) 上花费了不可能的时间。 (如果有帮助，我可以提供更完整的堆栈跟踪。)“不可能很长”我的意思是 Java 会在我放弃之前几个小时内一直忙于查询。

我最初希望上述查询能够正常执行，因为从概念上讲，只需按照以下方式执行 SQL 查询，就可以稍微有效地完成:

select Firm, Client, Sum(Amount) as n
from fact, firm, client
where fact.firmid = firm.firmid and fact.clientid = client.clientid
group by Firm, Client

(实际上，如果我直接在 MySql 中执行这样的操作，执行时间不会超过 15 秒。)

但是从调试日志来看，蒙德里安似乎并没有尝试这种优化。相反，它似乎是在内部进行连接，并且最终以特别慢的方式进行。我已经在我的 mondrian.properties 中设置了 mondrian.native.crossjoin.enable=true，但这似乎不是 Mondrian 能够“制作原生”的连接类型之一。 (如果我打开 mondrian.native.unsupported.alert=ERROR 然后我得到相应的异常。)

我想知道我是否需要阻止我的用户尝试在如此大的维度/集合上进行连接，或者 Mondrian 可能不是我在这里寻找的工具。但也许我只是做错了什么。

Answer 1

为了跟进，我尝试在 Sql Server Analysis Services (Sql Server 2008) 中设置一个类似的多维数据集，似乎 icCube 对不同的 OLAP 工具的性能有所不同:

甚至在我了解 SSAS 最佳实践之前，这种类型的 MDX 的性能就得到了很大的提高。沿着这些路线的查询

select
  [Measures].[Amount] on columns,
  NON EMPTY
  crossjoin([Firms].[Firm Name].Children,
            [Clients].[Client Name].Children)
  on rows
from MyCube

从对 Mondrian 不可行到在 Sql Server 下花费大约 10 秒钟。可以想象，这与 MS 的商业智能开发工作室默认情况下指导我创建 MOLAP 多维数据集有关，或者 SSAS 有一个更智能的查询计划器。

无论如何，也许这对我来说已经足够快了。如果没有，我还不确定在这种情况下 SSAS 可以得到多少优化。 (令人失望的是，即使我第二次重新运行查询，它仍然需要大约 10 秒；我希望缓存可能会产生更显着的效果。)

切线地，您可能会注意到，在刚刚引用的 MDX 中，我已将原始的 NonEmptyCrossJoin 替换为与 NON EMPTY 相结合的普通 crossjoin。这是因为，至少在 Sql Server 世界中，NonEmptyCrossJoin 显然被视为已弃用的不良做法。 (这里是 noted in Microsoft's MDX Language Reference 。前 SSAS 开发者之一的 Mosha 在一篇名为 MDX: NonEmpty, Exists and evil NonEmptyCrossJoin 的文章中描述了这种情况。简而言之，NonEmptyCrossJoin 语义困惑，应用有限，从 Sql Server 2005 左右开始，查询优化器已经足够聪明，可以在没有 NonEmptyCrossJoin 的情况下快速查询。)所以我在上面的 MDX 中替换了一个更现代的批准等效项。 (它仍然适用于 NonEmptyCrossJoin，尽管 NonEmptyCrossJoin 根本没有加快速度。)