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的查詢的面向行的數據庫相比具有顯着的性能提升。有幾個很好的選擇，你應該試駕他們。