我想知道是否有任何性能影響將大量計算成員添加到我的多維數據集中。一方面,事情定義一次,集中定位,測試並可用於任何不支持MDX的客戶端是很好的。另一方面,我添加的這些成員中的一些可能不會經常使用,所以我可以將它們內聯到一兩個可能需要它們的報告中。計算成員在SSAS中的性能影響
從具有不必要的成員四處張望,我應該保持計算的成員數量儘可能小的雜亂除了?會不會增加立方體處理時間?他們會減慢不使用這些計算成員的查詢嗎?
我想知道是否有任何性能影響將大量計算成員添加到我的多維數據集中。一方面,事情定義一次,集中定位,測試並可用於任何不支持MDX的客戶端是很好的。另一方面,我添加的這些成員中的一些可能不會經常使用,所以我可以將它們內聯到一兩個可能需要它們的報告中。計算成員在SSAS中的性能影響
從具有不必要的成員四處張望,我應該保持計算的成員數量儘可能小的雜亂除了?會不會增加立方體處理時間?他們會減慢不使用這些計算成員的查詢嗎?
計算成員很少有對處理也沒有對其他查詢沒有影響。儘可能多地添加你想要的!
原因是他們只是在立方體上定義,但實際上在運行時評估。因此,只有那些會被它們放慢或影響的查詢纔是使用它們的查詢。由於這個原因,期望它們比本地成員慢一點。
尋找一切機會,使計算成員多維數據集的實際組成部分,如果它的使用非常頻繁。另外,瞭解並喜愛scope
聲明。雖然計算的成員scope
d仍然在運行時計算,但scope
語句爲其提供了一個現成的執行計劃,因此它往往會更快。我會經常在DSV中創建一個成員,然後爲我的大批量計算成員創建一個成員。
任何時候,你可以把計算回關係模型,它將增加MDX查詢性能;但也會對加工性能產生負面影響。
如果可以預先計算使用行SQL邏輯了一些措施,那麼這些暴露在你的數據源視圖的措施。存儲引擎可以構建聚合,公式引擎可以做的工作量更少。你基本上是把重要的東西推到sql。這個作品真的很好靜態計算和換算係數之類的東西簡單的算術等
你能做的就是創造不應該由作爲隱藏的最終用戶可以使用任何中間計算成員另一件事,這不會有任何影響績效;但會從最終用戶的角度來解決這個問題。
並非所有成員都是預先計算的立方體的整個點?爲什麼SSAS會提供預先計算自定義成員的有限手段?嘆... – Jake 2010-08-03 23:08:03
@Jake:不是*全部*成員。如果是簡單的計算,多維數據集中度量值的組合不值得存儲 - 例如,如果您將「零售」和「Internet銷售」作爲多維數據集中的度量值,並且您希望「總銷售額」,則不會爲了保持「總銷售額」衡量標準,要將事實大小增加33% - 只需定義「總銷售額=零售銷售額+互聯網銷售額」的計算方法效率更高...... – 2011-03-16 10:33:41