Cost-Based Aggregation
После того как ядро Express Server было помещено внутрь СУБД Oracle, оно было переписано для того, чтобы по-новому работать с памятью и дисками. Это очень большая работа. Так как по сути Express-движку стало необходимо работать внутри "виртуальной машины" Oracle. Хотя внешне, для программиста все осталось также. Тот же DML, те же объекты.
Однако, с сейчас возросли требования к объемам хранимых в OLAP данных.
Система хранения данных на диске в Express хорошо подходит для задач таких как планирование и бюджетирование (что подтверждается успехом Oracle Financial Analyzer). В любой момент времени можно обновить любую ячейку в кубе, что не умеют многие OLAP сервера, или если и умеют, то с оговорками.
Однако, в случае, если нам нужно хранить просто большие объемы данных, такая система оказывается неэффективной, так как эти данные и их агрегаты занимают много места на диске. А диск - устройство медленное. Чтобы прочитать большое количество данных с диска, нужно потратить много времени.
В OLAP 10g появился новый тип хранения данных - Compressed Composite.
К сожалению, я не встречал нигде описание того, как он устроен, но, по-видимому, это компессированный вариант старой модели. По крайней мере, он полностью прозрачен для DML.
Достоинства сжатых композитов в том, что они позволяют хранить больше данных в расчете на блок. А прочитать блок с диска, и распаковать в памяти объем, равный нескольким несжатым блокам - обычно процесс более быстрый, чем чтение сразу несжатых блоков с диска.
Когда разрабатывался Express сервер это было не так актуально, так как процессоры были слабые и оперативной памяти было мало, поэтому разработчики Express были больше озабочены тем, как найти компромисс между медленными процессорами и малой памятью и требованиями пользователей к быстрому отклику. И если вернуться хотя бы на 10 лет назад, то на бытовом железе того времени, OLAP показывал обычно большую производительность, чем запросы по реляционной базе. Express очень эффективно работал на машинах с количеством оперативной памяти 128Мб и меньше.
Потом времена изменились, и новые OLAP сервера, которые писались в то время уже изначально затачивались под то, что памяти много, диски дешевые, а процессоры быстрые. И обычно данные там сразу хранятся в сжатом виде.
Недостаток сжатого хранения в том, что теряется возможность быстро обновить произвольную ячейку куба. Так как задача становится подобной тому, как если бы в zip архиве нужно было быстро обновить один байт в текстовом файле, который в нем запакован. Понятно, что для этого архив нужно распаковать, изменить байт и запаковать обратно. При этом размер архива может поменяться и значит записать его в тоже место на диске может не получиться.
Еще одна проблема, с которой сталкивались разработчики сервера в том, как обсчитывать и хранить агрегаты. Ведь нужна иллюзия того, что весь куб обсчитан и достаточно запросить данные из ячейки с определенным координатами и эти данные куб выдаст. Независимо от того, запрашиваются ли агрегированные или детальные данные. Но заранее агрегировать все нельзя, так как большой обсчитанный куб не поместится ни на какие диски. Поэтому каждый OLAP сервер использует разные подходы к тому, как хранить агрегаты.
Почти всегда это комбинация физического хранения на диске части агрегатов и вычислений недостающих агрегатов "на лету". И тут очень важно найти баланс. Ведь если все обсчитывать на лету, это требует слишком большого количества детальных данных и затрат процессора. Если записать все на диск, то с одной стороны диска не хватит, а с другой, если запрос требует данных которые хотя и обсчитаны заранее, но лежат в большом количестве блоков на диске - засчет медленного чтения диска можно потратить времени даже больше, чем если бы считали все "на лету".
В Express есть такое понятие - AGGMAP или карта агрегации. В ней записано какие уровни и какие куски агрегатов куба нужно обсчитывать заранее и хранить на диске, а какие считать на лету. Создание хорошей карты - большое искусство. Сжатые композиты эту проблему частично снимают.
В OLAP 11g появилось нововведение. Это новый тип обсчета агрегатов. Так называемая Cost-Based Aggregation. Архитектура ее опять же не раскрывается, но в документации написано, что теперь производится автоматическое вычисление самых тяжелых для расчета на лету мест в кубе и именно они рассчитываются заранее и записываются на диск. Разработчик куба должен указать только процент обсчета куба. По умолчанию это 20-30% в зависимости от типа куба. 100% значит что все агрегаты должны храниться на диске.
Дальше сервер все делает автоматически. Предполагается, что играя этим процентом можно достигать баланса между производительностью и объемом места на диске.
Как я уже сказал, со временем отклика в 11g гораздо лучшеше, чем в 10g. Чья тут в основном заслуга - сжатых композитов, партиционирования кубов, более грамотной обработки условия запроса или стомостной агрегации или еще чего-то - мне не известно.
Скорее всего, все сразу. Однако, в 11g появилась из этого списка стоимостная агрегация и обработка условий в SQL. Так что, причина, скорее всего, тут.
Память
Напишу еще несколько слов о памяти. Как я уже написал - в OLAP, да и не только, важно найти баланс между тем, что хранится на диске и тем, что можно подкачать в память. Сколько нужно памяти на сервере - зависит от структуры куба и агрегатов, объема данных, запросов пользователя и их количества. При работе с Express был такой "бытовой" индикатор: если во время агрегации или запроса пользователя процессор занят на 100%, значит Express хватает памяти. А если процессор не загружен, значит происходят чтение и запись с дисков или свопирование. Сколько нужно памяти если ее не хватает можно было проверить только экспериментально.
В Oracle 11g Enterprise Manager довольно грамотно рассчитывает рекомендации по памяти для OLAP. На тех данных, что были у меня, я пробовал отдавать Oracle от 784 Мб до 2Гб.
Совет Oracle на самом большом моем кубе был взять примерно 1,5 гигабайта. Больше ему не нужно было ни для каких запросов. Если памяти давать меньше, то все в общем-тоже работало, но агрегация проходила в разы медленнее, что наверное не сюрприз.
Собственно, совет в том, что если вы разрабатываете кубик в OLAP - смотрите на рекомендации Enterprise Manager, так как он учитывает сколько же сервер реально требовал ресурсов. Предсказать это самому очень сложно, по причинам, которые я перечислял.
Благодарности
Я хотел бы вразить благодарность Георгию Тимошенко, наверное самому большому русскоязычному специалисту по Oracle Express, которого я знаю. Он сильно помог мне во время вспоминания устройства Express и OLAP DML и сэкономил мне массу времени при подготовке доклада про OLAP и этих статей.
Еще я хочу сказать спасибо Саше Рындину, который хоть пока и не специалист по OLAP, но несколько раз помог мне с пониманием работы Oracle СУБД в некоторых ситуациях.
По плану я хотел написать еще про Cube-Oraganized Materialized Views, но с одной стороны идея их простая и красивая и ее можно понять из слайдов презентаций, а с другой стороны, если описывать детали, то на это нужно много времени.
Эта третья часть была написана в черновом варианте еще в декабре, но дописать ее у меня дошли руки только сейчас. Поэтому опубликую я пока ее. А новую статью про Mat Views и другие темы постараюсь написать позже, когда появится больше свободного времени.