我們有一個Analysis Services多維數據集需要儘可能實時。這是一個相對較小的立方體,目前需要幾秒鐘來處理。確定處理SSAS立方體的最大頻率的準則?
這是否有任何指導原則?我很好奇其他人在做什麼。
而且,這將是處理多維數據集過於頻繁的影響?主要擔心的是SSAS服務器和源數據庫上的負載?在我們的情況下,這將是相當的名義。 SSAS客戶如何受到影響?當前的SSAS消費者是Excel,PerformancePoint和Sharepoint/Excel Services。
我們有一個Analysis Services多維數據集需要儘可能實時。這是一個相對較小的立方體,目前需要幾秒鐘來處理。確定處理SSAS立方體的最大頻率的準則?
這是否有任何指導原則?我很好奇其他人在做什麼。
而且,這將是處理多維數據集過於頻繁的影響?主要擔心的是SSAS服務器和源數據庫上的負載?在我們的情況下,這將是相當的名義。 SSAS客戶如何受到影響?當前的SSAS消費者是Excel,PerformancePoint和Sharepoint/Excel Services。
我會說你必須要考慮的第一個問題就是這個立方體多少會隨着時間的推移增長?如果它不斷更新和處理,那麼幾秒鐘可以迅速變成20分鐘。
例如,我們目前擁有一個擁有2000萬行(可能更多現在是呵呵)的立方體,其中包含與醫院帳單相關的財務數據以及需要大約20分鐘處理的費用,而且我們每天早上都會執行一次。根據一年中的某個時間,我們有時會再次在白天進行處理,但只要我們通知我們正在執行此操作,就沒有投訴。
這可能是因爲你必須「把它放在那裏」,並跟蹤它如何執行。
一旦你可以看到人們是如何使用的立方體,你可以決定是否重新處理不變確需如果是,你可能要優化如何發生這種情況。
Spcifically使用「用量優化」如下所述:
你有沒有考慮實時(ROLAP)分區來存儲當天的數據?通過這種方式,您可以在當天之前獲得所有數據的MOLAP性能,您可以每天處理該數據,但是ROLAP對於自上一個多維數據集進程以來收集的數據的低延遲。
如果你的立方體是足夠小,你甚至可以伸展,要成爲當前一週的數據,或更多。
至於頻繁處理的缺點,請查看下面的文章,它說:「如果處理作業成功,則在提交更改時將在該對象上放置排它鎖,這意味着對象暫時不可用用於查詢或處理,在事務的提交階段,查詢仍然可以發送給對象,但是它們將排隊直到提交完成。「 http://technet.microsoft.com/en-us/library/ms174860.aspx
那麼用戶將看到查詢性能產生影響。