Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / OLAP и DWH Новый топик    Ответить
 SSAS: AttributeRelationships RIGIT vs FLEXIBLE - query Performance  [new]
Yuri Abele
Member

Откуда: Латвия -> Литва -> Тольятти -> Karlsruhe
Сообщений: 1537
Зашел тут у нас спор про то есть ли разница в производительности для MDX запросов по иерархиям, если в них тип связи жесткая или гибкая.
То что на процессинг влияет известно, меня именно производительность запросов по большим измерениям с несколькими уровнями интересует.
13 сен 17, 12:39    [20792465]     Ответить | Цитировать Сообщить модератору
 Re: SSAS: AttributeRelationships RIGIT vs FLEXIBLE - query Performance  [new]
Alex_496
Member

Откуда: Moscow https://www.dvbi.ru
Сообщений: 3509
Может не совсем в тему отвечу, но:

я делаю практически всегда Rigid связи, т.к. у меня Process Data и Process Index разнесены на отдельные шаги.
И если значения атрибутов измерения изменятся, то нужно выполнить Process Index, а читать из источников данные в факты групп мер (Process Data) не нужно.

Ну а в измерениях значения атрибутов могут меняться часто и для большого количества элементов:
то на реляционном источнике клиентов перемаркировали в другие сегменты, то многие заявки в другие статусы перешли, то, казалось бы, по абсолютно древним записям чего-то там исправили
13 сен 17, 14:11    [20792823]     Ответить | Цитировать Сообщить модератору
 Re: SSAS: AttributeRelationships RIGIT vs FLEXIBLE - query Performance  [new]
Utwig_
Member

Откуда:
Сообщений: 1
Greg Galloway говорит, что разницы нет:
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/abc4e1a3-de81-4206-80dc-0d9ff096660e/rigid-vs-flexible-attribute-relationship?forum=sqlanalysisservices

Индексы и аггрегации для гибких связей нужно, конечно, с Process Index актуализировать.
13 сен 17, 16:07    [20793200]     Ответить | Цитировать Сообщить модератору
 Re: SSAS: AttributeRelationships RIGIT vs FLEXIBLE - query Performance  [new]
Ferdipux
Member

Откуда: Москва
Сообщений: 406
Yuri Abele,

Не совсем в тему. Как-то анализировал производительность запросов в кубе с большим количеством партиций и M2M связей в каскаде, партицирование было по времени. Для партиций выставлялись Partition Slice в соответствии с элементами иерархии измерения времени. Анализировались промежуточные запросы при отборе по M2M измерениям, особенно по непрямым.
Так вот, пока связи в DimDate были flexible - косяков при отборе промежуточных партиций M2M было много, то есть в некоторых случаях шло сканирование всех партиций. После перевода на rigid связи - пустое сканирование прекратилось.
Среда экспериментов - SSAS 2012.
13 сен 17, 18:33    [20793665]     Ответить | Цитировать Сообщить модератору
 Re: SSAS: AttributeRelationships RIGIT vs FLEXIBLE - query Performance  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 31488
Блог
Ferdipux,

Ну, не факт, что причина в этом. Может быть это было банальное опережающее чтение.
14 сен 17, 00:36    [20794236]     Ответить | Цитировать Сообщить модератору
 Re: SSAS: AttributeRelationships RIGIT vs FLEXIBLE - query Performance  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 31488
Блог
Alex_496
Может не совсем в тему отвечу, но:

я делаю практически всегда Rigid связи, т.к. у меня Process Data и Process Index разнесены на отдельные шаги.
И если значения атрибутов измерения изменятся, то нужно выполнить Process Index, а читать из источников данные в факты групп мер (Process Data) не нужно.

Ну а в измерениях значения атрибутов могут меняться часто и для большого количества элементов:
то на реляционном источнике клиентов перемаркировали в другие сегменты, то многие заявки в другие статусы перешли, то, казалось бы, по абсолютно древним записям чего-то там исправили


Каким образом это работает? Ведь в случае жестких связей требуется full-процессинг после того, как элемент изменил свое положение в иерархии. В случае большого куба это чревато тем, что в начале рабочего дня кубы будут не обновлены.

По моему мнению жесткие связи можно использовать только в измерении календаря, или в других случаях подобных измерений.
14 сен 17, 00:40    [20794239]     Ответить | Цитировать Сообщить модератору
 Re: SSAS: AttributeRelationships RIGIT vs FLEXIBLE - query Performance  [new]
Alex_496
Member

Откуда: Moscow https://www.dvbi.ru
Сообщений: 3509
Критик,

если у Автора измерения не в десятки миллионов элементов, то чего волноваться за full processing измерений. Если натуральные иерархии в 4-5 уровней с хорошим коэффициентом отношения уровня к предыдущему уровню - вообще класс.
Ентерпрайз сейчас поди уж не удивить 1Тб оперативной памяти.

Кстати, может кто подскажет как еще ускорить process index больших измерений
14 сен 17, 02:21    [20794281]     Ответить | Цитировать Сообщить модератору
 Re: SSAS: AttributeRelationships RIGIT vs FLEXIBLE - query Performance  [new]
Критик
Member

Откуда: Москва / Калуга
Сообщений: 31488
Блог
Alex_496
Критик,

если у Автора измерения не в десятки миллионов элементов, то чего волноваться за full processing измерений. Если натуральные иерархии в 4-5 уровней с хорошим коэффициентом отношения уровня к предыдущему уровню - вообще класс.
Ентерпрайз сейчас поди уж не удивить 1Тб оперативной памяти.

Кстати, может кто подскажет как еще ускорить process index больших измерений


Дык измерение маленькое, а фактов куча. К тому же в процессе обработки нужно отдельную делать ветку, в которой нужно будет перепроцешивать весь куб.

По большим измерениям я исследовал вопрос - у меня все уперлось в производительность на ядро. Видимо, в коде процессинга SSAS имеется кусок, который не распараллеливается.
14 сен 17, 02:39    [20794294]     Ответить | Цитировать Сообщить модератору
 Re: SSAS: AttributeRelationships RIGIT vs FLEXIBLE - query Performance  [new]
Ferdipux
Member

Откуда: Москва
Сообщений: 406
Критик
Ferdipux,

Ну, не факт, что причина в этом. Может быть это было банальное опережающее чтение.

Может, и так. Но такое полное сканирование возникало часто и на повторе запроса.
По факту - в нашем случае переход на rigid связи в измерении времени помог на каскадных M2M запросах ощутимо, даже пользователи это заметили.
14 сен 17, 09:44    [20794599]     Ответить | Цитировать Сообщить модератору
 Re: SSAS: AttributeRelationships RIGIT vs FLEXIBLE - query Performance  [new]
Alex_496
Member

Откуда: Moscow https://www.dvbi.ru
Сообщений: 3509
Критик,

что-то не понимаю зачем делать full-процесс групп мер, когда изменяются связми между атрибутами измерений.
Process Data - подливаем новые фактовые записи в последние партиции, а вот Process Index - та да.

И это та да (пересчет агрегатов) у меня наименьше по времени чем остальные фазы Process.
14 сен 17, 10:04    [20794652]     Ответить | Цитировать Сообщить модератору
 Re: SSAS: AttributeRelationships RIGIT vs FLEXIBLE - query Performance  [new]
vikkiv
Member

Откуда: London / Zurich
Сообщений: 1141
Критик
..Каким образом это работает? Ведь в случае жестких связей требуется full-процессинг после того, как элемент изменил свое положение в иерархии. В случае большого куба это чревато тем, что в начале рабочего дня кубы будут не обновлены...
поддержу Alex_496 и немного не соглашусь с Критик - не обязательно делать ProcessFull, тип связей для проблемных измерений можно менять на живом кубе, это не меняет состояния {Processed/Unprocessed} измерения/мер.
14 сен 17, 10:28    [20794756]     Ответить | Цитировать Сообщить модератору
 Re: SSAS: AttributeRelationships RIGIT vs FLEXIBLE - query Performance  [new]
vikkiv
Member

Откуда: London / Zurich
Сообщений: 1141
гмм.. хотя Alex_496 почему-то говорит о мерах, в то время как речь скорее о иерархиях..
14 сен 17, 10:30    [20794763]     Ответить | Цитировать Сообщить модератору
 Re: SSAS: AttributeRelationships RIGIT vs FLEXIBLE - query Performance  [new]
vikkiv
Member

Откуда: London / Zurich
Сообщений: 1141
Alex_496
что-то не понимаю зачем делать full-процесс групп мер, когда изменяются связми между атрибутами измерений.
Process Data - подливаем новые фактовые записи в последние партиции, а вот Process Index - та да.
И это та да (пересчет агрегатов) у меня наименьше по времени чем остальные фазы Process.
потому что при жестких связях (и изменениях в них со стороны данных измерения) - процессинг измерения вывалится с ошибкой (т.к. в алгоритме нет операции сброса агрегаций для этого типа связей), есть 2 решения:
(а) - перепроцесить (Full) соответствующие MG
(б) - изменить тип связи, Process (Update на измерение, Index на MG), вернуть связи (если есть необходимость)
14 сен 17, 10:43    [20794819]     Ответить | Цитировать Сообщить модератору
Все форумы / OLAP и DWH Ответить