|
Когда мы создаем в SSAS меру типа distinct count, она
по-умолчанию создается в новой группе мер, причем метаданные источника данных
копируется из исходной группы мер. То есть, если исходная группа мер
содержала в себе 50 секций, то определения(запросы) этих секций абсолютно
таком же виде скопируются в новую группу мер.
Удобно? На первый взгляд да.
Но в некоторых случаях начинаются проблемы при процессинге: для новосозданных
секций он идет очень-очень долго. Часто в разы дольше, чем обрабатываются
секции исходной группы мер.
Почему так происходит?
Первый момент: если запустить Profiler, то можно увидеть, что запрос,
поступающий в хранилище, содержит сортировку по тому полю, по которому
построена distinct count-мера. Построением нужного индекса можно существенно
ускорить такой запрос. Этот момент очевиден и применяется достаточно часто.
Второй момент: напомню, что distinct count-секции генерируются на основе
секций некоторой исходной группы мер. А эти исходные секции часто основаны на
представлениях. Вот тут-то и зарыта собака.
Рассмотрим на примере: куб "Продажи" с данными о себестоимости
товаров, пусть здесь в качестве источника данных выступает преставление, в
котором факты продаж джойнятся с табличкой себестоимости товара. Это значит,
что СУБД должена сначала выполнить объединение данных, затем их
отсортировать, причем эта самая себестоимость в данном случае нам фактически
не нужна! А если она не нужна, то от нее стоит избавится и взять в качестве
источника сразу таблицу продаж, а не автоматически сгенерированное
представление. То есть стоит чуть-чуть поработать руками и заменить в
источник данных для этой группы мер.
Этот подход может в разы увеличить скорость процессинга, особенно на кубах,
содержащих несколько distinct count-мер.
|
Комментариев нет:
Отправить комментарий