EssBase Calc Performance: еще раз о производительности

Последнее время я посветил настройке производительности расчетов Essbase на одном из проектов в телекоме. Благодаря грамотно поставлено целям и правильной мотивацией ) были решены задачи повышения скорости расчетов , например с 6 часов до 15 минут.
После всего этого, я утвердился в истинности пяти простых правил, которые позволяют сразу делать “быстрые” расчеты

Хоть они уже и банальны, но их стоить обозначить для ориентира :

1) всегда рассчитываем наименьший возможный срез данных
а) aгрегировать значения только с помощью каскадных функций
b) категоричный запрет в использовании расчетов от модели (CREATENONMISSINGBLK ON )
c) разбавляем одну или две sparce аналитики d-calc элементами
d) запрет на повсеместное использование SUMRANGE, – особенно в Dcalc.
e) использовать переменных расчетов EssBAse (или “технические” срезы), что бы сократить кол-во переходов по срезам данных
g) промежуточный расчеты обязательно сохраняем , лишний раз не пересчитываем.

2) Если модель больше 14 измерений, то блок состоит из 3-х аналитик
a) Размер блока может быть любым, пик оптимальности в районе 350K
b) Если периоды в блоке , то кварталы всегда динамические
с) Прочий DCALC в блоке должен быть максимально простым, вся вычурная логика в расчетах.

3) Минимизация автоматических транзакций между приложениями
a) Все партиции, XWRITE и Xref заменяем на export -> import
b) ReportScript и MDX не должны обращаться к более чем двум Sparce DCALC
c) В ряде случаев самым оптимальным вариантом – это создание промежуточных приложений, чем “долгий” ReportScript или DataExport

4) Реструктуризация приложений на регулярной основе
а) Для ввода используется только элементы нулевого уровня
b) Агрегаты – это действительно агрегаты , а не произвольный функциональный расчет на элементах верхнего уровня.
c) Придерживаемся золотого правила – одно приложение – один куб

5) Любое предположение по оптимизации нуждается в проверке
а) Разработчик должен разрабатывать и тестировать модель в изолированной среде на всем возможном (производственном) объеме данных
b) Допускается первичные итерации на “технических” данных и “приближенных” моделях