Враження від Oracle OLAP 11g. Частина 3., Oracle, Бази даних, статті

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 і інші теми постараюся написати пізніше, коли з’явиться більше вільного часу.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*