Mondrian w/Degenerate Dimensions的性能不佳

Question

我有一个应用程序收集性能指标并将它们存储在数据集市中。然后，我使用Mondrian对数据进行分析和临时探索。我每天收集约5e6行，METRIC表的总大小约为300M行。

我们根据与SLA的度量指标比较来“数据”我们的数据。颜色有5个不同的值。当我们进行简单的MDX查询以获得特定日期范围（例如1天）的数据的颜色分布时，我们看到如下的查询：

2014-06-11 23：17：08,042从“METRIC”“METRIC”组中通过“METRIC”执行sql [选择“METRIC”。“COLOR”为“c0” ）。 “COLOR”，以便通过 “公制” “COLOR” ASC NULLS LAST] 2014年6月11日23：17：58747 DEBUG [SQL] - 223：，EXEC 50704毫秒

为了提高性能，数据集市包括第四天的聚合表小时和天的级别，并且两个聚合表都包含COLOR列。

我知道Mondrian非常依赖底层数据库的性能，但实际上没有办法调整它。我可以在COLOR上创建一个索引（因为对索引的全面扫描比对表的完整扫描稍快），但在300M行表上创建具有5个不同值的索引似乎很愚蠢。日聚合表大约有500K行，并且对这个表执行几乎相同的查询的速度要快得多，但是Mondrian似乎总是转到基本事实表以查找这些维度查询。

我的问题是，有没有办法避免这个查询？如果我无法避免它，是否有可能让Mondrian使用这种查询类型的聚合表？我已在此维度/层次结构的单一级别中指定了approxRowCount，并且消除了类似查询以获取值的计数。我还没有挖掘到蒙德里安的来源，但还没有确定是否有可能使用聚合表，或者我的部分是否有一些配置阻止它。

编辑澄清：

我可能没有做询问我的一个很好的工作问题，让我尝试和澄清。我的MDX查询看起来是这样的：

select [Color].[Color].Members on columns, 
     {[Measures].[Metric Value], [Measures].[Count]} on rows 
from [Metric] 
where [Time].[2014].[June].[11] 

我可以看看这和手工编写回答这个查询

select COLOR, avg(VALUE), sum(FACT_COUNT) 
from AGG_DAY_METRIC 
where YEAR = 2014 
    and MONTH = 6 
    and DAY_OF_MONTH = 11 
group by COLOR 

数据库回答这个查询在100ms左右扫描约4K行SQL查询。 Mondrian需要几分钟的时间来回答 查询，因为它有几个查询不直接回答MDX查询，而是获取有关 维度的信息。在上面的情况下，数据库必须扫描300M行，花费50秒，返回5个可能的颜色。如果颜色位于正常尺寸表中，则只有5行，但在退化维度中，可能有数百万行为100个。

所以我的问题是：

一）有没有办法告诉蒙德里安退化维度的价值和避免这些疑问？

b）有没有办法让Mondrian从聚合表中回答这些查询？

Answer 1

此问题已解决，而不是通过修改Mondrian架构或应用程序中的任何内容，而是通过修改数据库。在这种情况下，数据库是Oracle，我们能够创建一个启用了查询重写的物化视图。

物化视图是由Mondrian发出的确切查询创建的。由于颜色值不会非常频繁地变化（在我们的例子中几乎不会），物化视图每天都会进行一次全面刷新。

在这种情况下，查询从分钟到几毫秒。如果您面临这样的问题，并且您的数据库是Oracle，那么这是一种加快元组分辨率以降低基数的退化维度的好方法。

Answer 2

如果不知道更多关于模式的信息，很难给出具体说明，但在我看来，您必须确保具有某些颜色（计数）的行数必须标记为聚合度量（Count或Max Number）。

请注意，这些聚合不是连续计算的（我认为这将对后备数据存储产生负面影响，而Mondrian将不会为传入的事实保留内存中的流动集合）。

可以将聚合指定为在特定时间（每晚，每小时...）运行/重建。这会让Mondrian有点不适合进行实时分析，但是您应该能够对历史数据进行即时查询。

Answer 3

如果您的维度在300M事实表中有5个不同的值，则它不应该是退化维度。它应该在一个单独的维度表中。只有基数接近完整事实表的行数时才应使用退化维度，从而使得单独的表格毫无意义，因为不会显着节省存储空间，并将维度结果加入大量正在读取的数据中;

如果将颜色放在单独的暗淡表格上，则任何“读取元组”查询都会在几ms内返回结果，并解决您的问题。

但是，更重要的是，您的问题，蒙德里安应该能够从agg表中选择暗淡的值。除非在多维数据集中有不同数量的聚合器，在这种情况下，您处于一个棘手的情况（除非有一个与您需要的详细程度完全匹配的聚合表，否则Mondrian很可能会扫描事实表）。

您还应该将此退化维的highCardinality属性设置为True。即使只有5个不同的值，具有highCardinality = false也会告诉Mondrian，扫描整个维度以填充成员列表是安全的。将其设置为true将停止此扫描。

您还应该为此列添加索引。将索引添加到事实表中的每个键和退化维列总是一个好主意。使用索引，DB应该比SQL查询快得多。

最后，你有一个300M行的事实表。你使用的是什么DBMS？它是一个面向列的数据库吗？如果没有，您应该尝试将它们作为数据存储的替代方案。面向列的数据库与面向类似Mondrian的查询的面向行的数据库相比具有显着的性能提升。有几个很好的选择，你应该试驾他们。