Влияние размера БД на скорость расчетов

Основным ведущим параметром, влияющим на  время расчета, является кол-во операций дискового ввода-вывода. Соответственно размер файла данных влияет на операцию поиска нужного среза данных и на операцию извлечения найденного среза.  Применительно  к объектам Essbase,  можно выделить два типа роста БД

1)      В рамках бюджетного блока, это рост объема данных (т.е. кол-ва значащих записей ) внутри среза Версия – Сценарий – Период планирования

2)      И рост данных связанный с хранением исторических данных предыдущего периода, т.е. вне текущего бюджетного блока.

Для первого случая

Для того что бы оценить сколько времени потребуется на расчет текущего бюджетного среза при двукратном росте значащих записей с  данными, было произведено следующие тестирование.

1)       Создан эталонное бизнес правило, с включенным блоком агрегации данных.

2)      Произведен контрольный расчет

3)      Текущую модель  скопирован на другой срез

4)      Произвели расчет с учетом дополнительного среза.

Данный эксперимент показал, что кол-ва рассчитанных ячеек данных (запись Sparse Calculations: [ ] Cells в файле лога ) было увеличено в два раза (или на 100 % ) со значения [2.4527e+07] до значения [4.9054e+07] Cells, время расчета увеличилось в 1,5 раза или на 50%   со значения [9.89]  до [15.47]

Для второго случая

Для того что бы оценить сколько времени потребуется на расчет при увеличении объема исторических данных нужно просто скопировать сценарий и измеряя показатель времени расчета, можно сказать об удачном или неудачном проектировании модели,

т.е. если производительность расчетов упала менее чем на 20% при росте БД в два раза, то данная многомерная модель сбалансирована и в ней удачно выбраны плотные направления и порядок разряженных. Если расчет упал в разы – то это первый признак того что модель нуждается в пересмотре.

Для анализа обоснованности выбора того или иного направления в блок, рекомендуется след. подход

a) – выгрузить все данные нулевого уровня в реляционную табличку

b) – запросами вида

select “Account” ,”Scenario”,”Version”, count (*) from XX_RP_CHECK0 group by “Account”, “Scenario”, “Version”

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

c) – На основании данной статистики делаются выводы

о верности принятия решения по включению в блок того или иного направления
о порядке разряженных направлений
о возможности и способе разделения данного приложения
Максимальный допустимый размер БД, 20Gb – если база получается больше – начинайте думать об оптимизации