我有一个收集性能指标并将它们存储在数据集市中的应用程序。然后,我使用 Mondrian 对数据进行分析和临时探索。我每天收集大约 5e6 行,METRIC 表的总大小约为 300M 行。
我们根据与 SLA 的指标比较为我们的数据“着色”。颜色正好有 5 个不同的值。例如,当我们执行简单的 MDX 查询以获取特定日期范围(例如 1 天)的数据颜色分布时,我们会看到如下查询:
2014-06-11 23:17:08,042 调试 [sql] - 223: SqlTupleReader.readTuples [[Color].[Color]]: 执行 sql [select "METRIC"."COLOR" as "c0" from "METRIC"" METRIC”组按“METRIC”。“COLOR”按“METRIC”排序。“COLOR”ASC NULLS LAST] 2014-06-11 23:17:58,747 DEBUG [sql] - 223: , exec 50704 ms
为了提高性能,数据集市包含小时和天级别的聚合表,并且两个聚合表都包含 COLOR 列。
我知道蒙德里安非常依赖底层数据库的性能,但真的没有办法调整它。我可以在 COLOR 上创建索引(因为索引的完整扫描将比表的完整扫描稍微快一些),但是在 300M 行表上创建具有 5 个不同值的索引似乎很愚蠢。day 聚合表有大约 500K 行,并且对这个表执行几乎相同的查询会明显更快,但 Mondrian 似乎总是针对这些维度查询使用基本事实表。
我的问题是,有没有办法避免这个查询?如果我无法避免,是否可以让 Mondrian 使用聚合表进行此类查询?我已经在这个维度/层次结构的单个级别中指定了 approxRowCount,并且消除了类似的查询来获取值的计数。我还没有深入了解 Mondrian 的来源,以确定是否有可能使用聚合表,或者我是否有一些配置阻止了它。
编辑澄清:
我可能没有很好地提出我的问题——让我试着澄清一下。我的 MDX 查询类似于:
select [Color].[Color].Members on columns,
{[Measures].[Metric Value], [Measures].[Count]} on rows
from [Metric]
where [Time].[2014].[June].[11]
我可以看看这个并手写一个 SQL 查询来回答这个查询
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
数据库在大约 100 毫秒内扫描大约 4K 行来回答这个查询。Mondrian 需要几分钟来回答查询,因为它执行了几个不直接回答 MDX 查询的查询,而是获取有关维度的信息。在上述情况下,数据库必须扫描 300M 行,用时 50 秒,才能返回有 5 种可能的颜色。如果颜色在正常维度表中,则只有 5 行,但在退化维度中,可能有数百万行。
所以我的问题是:
a)有没有办法告诉蒙德里安退化维度的值并避免这些查询?
b) 有没有办法让蒙德里安从聚合表中回答这些查询?