"Взрыв" базы данных

"Взрыв" базы данных представляет собой феномен многомерных баз. Несмотря на то, что эта проблема исследовалась специалистами, тем не менее, трудно объяснить, почему и как это происходит. Представляется, что это связано с разреженностью базы данных и предварительной агрегацией данных. Если многомерная база данных содержит небольшое число элементов данных, сравнимое с количеством обеспечиваемых ею уровней агрегации, каждый фрагмент данных будет вносить больший вклад во все получаемые из него данные. Когда база данных "взрывается", размер ее становится существенно больше, чем он должен быть.

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

Таблица 1. Многомерные базы данных

За	Против
Точно моделируют бизнес-данные	Как правило, не могут грамотно управлять очень большими базами данных
Обеспечивают быстрый доступ без SQL	Представляют собой новую, и, поэтому, еще не оптимизированную технологию
Содержат заранее рассчитанные сводные данные	Имеют риск "взрыва"

MOLAP— это классическая форма OLAP, так что её часто называют просто OLAP. Она использует суммирующую БД, специальный вариант процессора пространственных БД и создаёт требуемую пространственную схему данных с сохранением как базовых данных, так и агрегатов. В этом случае наличествует программа, на этапе предварительной загрузки данных в OLAP из источников выполняющая предварительный расчёт агрегатов (вычислений по нескольким исходным значениям, например «Итог за месяц»), которые затем сохраняются в специальную многомерную БД, обеспечивающую быстрое извлечение. Примеры таких продуктов— Microsoft Analysis Services, Oracle OLAP Option, Oracle/Hyperion Essbase, Prognoz, SAS OLAP Server, Cognos PowerPlay. Hybrid OLAP является комбинацией. Сами данные хранятся в реляционной БД, а агрегаты — в многомерной БД.

Системы, имеющие в своей основе «физический OLAP» обеспечивают стабильно лучшее время отклика на запросы, чем системы «виртуальный OLAP».

ROLAP

ROLAP - это Relational On-Line Analytical Processing, то есть Реляционный OLAP. Термин ROLAP обозначает, что OLAP-сервер базируется на реляционной базе данных. Исходные данные вводятся в реляционную базу данных, обычно по схеме "звезда" или схеме "снежинка", что способствует сокращению времени извлечения. Сервер обеспечивает многомерную модель данных с помощью оптимизированных SQL-запросов.

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

Таблица 2. Реляционные базы данных

За	Против
Идеальны для больших объемов данных	Для сложных запросов SQL не является оптимальным
Отработанная, оптимизированная технология	Определение оптимальной схемы хранения данных представляется более трудным и важным делом

ROLAP работает напрямую с реляционным хранилищем, факты и таблицы с измерениями хранятся в реляционных таблицах, и для хранения агрегатов создаются дополнительные реляционные таблицы. Поставщики систем «виртуальный OLAP» заявляют о большей масштабируемости их продуктов в плане поддержки очень больших объемов данных.

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

В большинстве случаев корпоративные хранилища данных реализуются средствами реляционных СУБД, и инструменты ROLAP позволяют производить анализ непосредственно над ними. При этом размер хранилища не является таким критичным параметром, как в случае MOLAP.

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

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

Главный недостаток ROLAP по сравнению с многомерными СУБД - меньшая производительность. Для обеспечения производительности, сравнимой с MOLAP, реляционные системы требуют тщательной проработки схемы базы данных и настройки индексов, то есть больших усилий со стороны администраторов БД. Только при использовании звездообразных схем производительность хорошо настроенных реляционных систем может быть приближена к производительности систем на основе многомерных баз данных.

HOLAP (Гибридные OLAP) использует реляционные таблицы для хранения базовых данных и многомерные таблицы для агрегатов. В этом случае данные хранятся в реляционных СУБД, а агрегаты могут не существовать вообще или создаваться по первому запросу в СУБД или кэше аналитического ПО. Примеры таких продуктов— SAS, SAP BW, Deductor, BusinessObjects, Microstrategy.

Особым случаем ROLAP является ROLAP реального времени (Real-time ROLAP— R-ROLAP). В отличие от ROLAP в R-ROLAP для хранения агрегатов не создаются дополнительные реляционные таблицы, а агрегаты рассчитываются в момент запроса. При этом многомерный запрос к OLAP-системе автоматически преобразуется в SQL-запрос к реляционным данным.

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

MOLAP лучше всего подходит для небольших наборов данных, он быстро рассчитывает агрегаты и возвращает ответы, но при этом генерируются огромные объёмы данных.

ROLAP оценивается как более масштабируемое решение, использующее к тому же наименьшее возможное пространство. При этом скорость обработки значительно снижается.

HOLAP находится посреди этих двух подходов, он достаточно хорошо масштабируется и быстро обрабатывается.

Архитектура R-ROLAP позволяет производить многомерный анализ OLTP-данных в режиме реального времени.

Сложность в применении OLAP состоит в создании запросов, выборе базовых данных и разработке схемы, в результате чего большинство современных продуктов OLAP поставляются вместе с огромным количеством предварительно настроенных запросов. Другая проблема — в базовых данных. Они должны быть полными и непротиворечивыми.