Каков наиболее эффективный способ расчета промежуточных итогов потребления в Sql Server Analysis Services?

Question

В SSAS 2005 у меня есть куб, который вычисляет текущие суммы по миллионам записей. Текущая реализация использует функцию суммирования PeriodsToDate в MDX, и она ужасно медленная, в некоторых случаях для получения результатов требуется 15 минут или более. Существует огромное количество решений этой проблемы, поэтому я надеюсь, что кто-то другой уже опробовал некоторые из них и может сэкономить мне время на внедрение и тестирование каждого из них.

Является ли предпочтительным вычислять текущие суммы и вычисления типа скользящего окна в T-SQL с помощью курсора (пожалуйста, не используйте решения для перекрестного объединения от Celko, я знаю, что они хорошо выглядят на бумаге, но решения для перекрестного соединения ужасно медленные по мере роста ваших данных ), используя задачу сценария в службах SSIS (или есть ли лучший способ сделать это в службах интеграции) или используя MDX в службах Analysis Services?

Есть еще идеи?

Answer 1

Мне потребовалось немного времени, чтобы понять, где это будет работать с иерархией времени и без нее в измерении времени. Основываясь на моих данных и структуре куба, вот что я собрал:

with member [Measures].[RunningTotal] as 
'sum({[Deferred Revenue Date].[Standard Calendar].CurrentMember.Level.Item(0):[Deferred Revenue Date].[Standard Calendar].CurrentMember}, [Measures].[Deferred Revenue Amount])'
select
    {[Measures].[Deferred Revenue Amount]
    ,[Measures].[RunningTotal]
    } on columns,
    nonempty([Deferred Revenue Date].[Standard Calendar].[Date], [Measures].[Deferred Revenue Amount]) on rows
from
DW;

Одним из приемов является предложение nonempty (), которое будет возвращать значения только в столбце вычисленной меры, если есть пересечения с измерением и мерой. Без этого вы получите кучу NULL в столбце меры и кучу повторных значений в столбце вычисленной меры. На самом деле это довольно удобный запрос.

Рассчитанный элемент будет работать независимо от уровня, указанного вами в операторе SELECT, будь то дата, месяц или год. В моем случае я пытался свидание как можно ближе к тому, что ты пытался сделать. Я написал запрос, похожий на ваш, для моего куба, и он запустился за 43 секунды. Этот новый запускается примерно за 2 секунды, и у нас довольно много данных, поэтому он должен работать гораздо быстрее и для вас, при условии, что у вас построены агрегаты и т. Д.

Проблема с MDX в том, что есть как восемнадцать способов что-то сделать, и только один или два будут работать хорошо.

Удачи.

Answer 2

Я мог бы увидеть наиболее эффективный способ выполнения промежуточного итога, используя агрегацию куба. Идея состоит в том, чтобы получить сумму всех предыдущих членов + сумма (parent.firstsibling: parent.prev member, measure) + sum (parent.parent.firstsibling: parent.parent.prevmember, measure)

Answer 3

MDX, который я сейчас использую, очень медленный, вот он.

Sum
(
PeriodsToDate([Date of Transaction].[Date].[(All)], [Date of Transaction].[Date].CurrentMember), [Measures].[Amount - Response]
)