Для ускорения расчетов distinct count провел тестирование куба, заменив обычную MOLAP меру с агрегатами на ROLAP, как неоднократно советовали на форумах.

Уже было подумал, что это совсем не то, но нашел упоминание, что нужно в Msmdsrv.ini выставить единицу для свойства
OLAP\ProcessPlan\EnableRolapDistinctCountOnDataSource . После этого вместо запроса из DBE всего набора элементов, distinct count всеже стал считаться на стороне DBE.

Но возникла новая проблема. Запросы получаются крайне не оптимальные.
Допустим есть факт продаж в метрике Товар-Магазин-МесяцГода. В таблицу факта добавлен отдельный столбец БрендТовара. И мы хотим посчитать число магазинов, продававших товары БрендТовара-МесяцГода.

Но бренд задан как дочерний атрибут измерения СвойстваТовара. Из-за этого движок строит запрос без использования готового столбца БрендТовара. Он к факту джойнит справочник товаров, получая оттуда бренд.
Это выходит крайне дорогой джойн, а если мы, например, еще выведем РегионМагазина, то эти дополнительные 2 джойна напрочь лишают затею по оптимизации всякого смысла. Сolumn stored index уже не используется эффективно, задействуются другие для поиска при джойнах.

Решение пока видится только одно: выносить в отдельные измерения в качестве ключевых атрибутов БрендТовара, РегионМагазина...
НО!!! Это крайне сильно портит интерфейс, если учесть, что атрибутов достаточно много. И производительность прочих MOLAP мер страдает, также невозможно создать иерархии...

Может кто знает решение, как не выносить в отдельные измерения атрибуты, но чтобы они использовались непосредственно в запросе, а не их джойн с самого низа гранулярности факта по измерениям этих атрибутов?!