Вертикальное разбиение данных
Эффективно только в том случае, если при выполнении запроса требуется просмотр всего нескольких колонок таблицы, и чем меньше соотношение - "Число колонок в таблице/Число колонок, на которые есть ссылки в запросе", тем менее эффективным оказывается данный метод.
Методы хранения данных по строкам и по колонкам взаимно исключают друг друга, и решение о том, как будут храниться данные, должно быть принято заранее.
Не поддерживается транзакционная обработка данных, и очень сильно снижается производительность системы при выполнении операций обновления данных.
Таким образом, сегодня вновь складывается ситуация, от которой, казалось бы, давно и безвозвратно ушли. И вновь на первый план выносится значимость вопросов проектирования базы данных на физическом уровне: "Чтобы гибко формировать запросы и быстро получать результат, необходима гибкая комбинация разных высокоэффективных индексных структур. ...корпорации нуждаются в таких проектировщиках базы данных, которые понимали бы, что в ней находится и как она будет использоваться. Хороший проект базы данных на физическом уровне - это залог высокой производительности" (5). До боли знакомая цитата, но взятая из статьи 1996, а не 1976 года. Вспомним региональные и индексно-последовательные файлы, инвертированные списки, иерархические и сетевые БД.
К тому же от проектировщиков аналитической системы можно и даже нужно требовать, чтобы они понимали - что находится в БД. Но требовать от них того, чтобы они понимали, как она будет использоваться, просто нереально. Это требование хорошо для традиционной СОД, но никак не для системы, предполагающей нерегламентированную аналитическую обработку данных.
Более просто и эффективно аналитические системы реализуются средствами специализированных баз данных, основанных на многомерном представлении данных. В этих системах данные организованы не в виде плоских таблиц (как в реляционных системах), а в виде упорядоченных многомерных массивов - гиперкубов (или поликубов).
Очевидно, что такое решение требует большей суммарной памяти для хранения данных, больших затрат времени при их загрузке и является менее гибким при необходимости модификации структур данных. Но, как уже было сказано выше, в аналитических задачах все это окупается за счет более быстрого поиска и выборки данных, отсутствия необходимости в многократном соединении различных таблиц и многократного вычисления агрегированных значений. И, как правило, среднее время ответа на нерегламентированный аналитический запрос при использовании многомерной СУБД обычно на один-два порядка меньше, чем в случае реляционной СУБД с нормализованной схемой данных.
Казалось бы, все очевидно и выбор однозначен - многомерные БД. Однако не все так просто. Многомерные базы, в силу чисто исторических причин, "не умеют" работать с большими объемами данных. На сегодняшний день их реальный предел - база объемом в 10-20 гигабайт. И хотя данное ограничение не связано с какими-либо внутренними объективными недостатками многомерного подхода и, скорее всего, является временным, сегодня это так. С чем нельзя не считаться.
К тому же за счет денормализации и предварительно выполненной агрегации 20 гигабайт в многомерной базе, в лучшем случае, эквивалентны не более чем 1 гигабайту исходных данных. По оценкам Кодда [3], для систем, основанных на многомерном представлении данных, это соотношение лежит в диапазоне от 2.5 до 100. И здесь необходимо остановиться на основном недостатке многомерных БД - неэффективному, по сравнению с реляционными БД, использованию внешней памяти. И это уже объективный фактор.
В основе многомерного подхода лежит представление данных в виде многомерных гиперкубов, при этом обычно предполагается, что внутри такого гиперкуба нет пустот. То есть все ячейки куба всегда заполнены. Это связано с тем, что данные в них обычно хранятся в виде множества логически упорядоченных блоков (массивов), имеющих фиксированную длину, причем именно блок является минимальной индексируемой единицей. И хотя в МСУБД, как правило, подразумевается, что блоки, полностью заполненные неопределенными значениями, не хранятся, это обеспечивает лишь частичное решение проблемы. Данные в таких системах хранятся в упорядоченном виде. И неопределенные значения устраняются, и то частично, только в том случае, если мы за счет выбора порядка сортировки сгруппируем их в максимально большие непрерывные группы.
Но такое решение может напрямую вступить в конфликт с тем, что МСУБД работают очень быстро только тогда, когда данные в них заранее отсортированы в том порядке, в котором они должны быть отсортированы в ответе на запрос. Но порядок сортировки, наиболее часто используемый в запросах, может не совпадать с тем, в котором они должны быть отсортированы, для максимального устранения неопределенных (несуществующих) значений. В результате разработчик может оказаться перед трудноразрешимой дилеммой:
пожертвовать быстродействием, но это одно из главных достоинств и часто одна из основных причин выбора именно МСУБД;
пожертвовать внешней памятью, но увеличение объема данных также не повышает быстродействие. Кроме того, как уже говорилось, МСУБД в настоящее время не приспособлены для работы с большими объемами данных.
Таким образом, МСУБД однозначно хороши только при выполнении двух требований.
Уровень агрегации данных в БД достаточно высок, и, соответственно, объем БД не очень велик (не более нескольких гигабайт).
В качестве граней многомерного куба выбраны достаточно стабильные во времени реквизиты (с точки зрения неизменности их взаимосвязей), и, соответственно, число несуществующих значений относительно невелико.
К сожалению, сегодня отсутствуют официальные сравнительные результаты тестирования производительности систем, реализованных на основе многомерных и реляционных баз данных (некоторые дополнительные аргументы в пользу того и другого подхода приведены в таблице 7), но при этом общая оценка такова: "Производительность хорошо настроенных реляционных систем, при использовании схемы звезда, вполне сравнима с производительностью систем, реализованных на основе многомерных баз данных".
| Многомерный подход Для достижения сравнимой производительности реляционные системы требуют тщательной проработки схемы БД, определения способов индексации и специальной настройки. В случае многомерных БД, как правило, не требуется даже указание на то, по каким реквизитам (группам реквизитов) требуется индексация данных. Ограничения SQL остаются реальностью, что не позволяет реализовать в РСУБД многие встроенные функции, легко обеспечиваемые в системах, основанных на многомерном представлении данных. Производители РСУБД находятся на этапе поиска, и ни один из описанных выше механизмов не является бесспорным и универсальным. Реляционный подходРСУБД обеспечивают качественно более высокий уровень защиты данных (по классу B1 Orange Book) и разграничения прав доступа. РСУБД имеют более развитые средства администрирования и реальный опыт работы с большими и сверхбольшими БД. Для многомерных БД в настоящее время отсутствуют единые стандарты на интерфейс, языки описания и манипулирования данными. МСУБД не поддерживают репликацию данных, наиболее часто используемую в качестве механизма загрузки. |
Таблица 7. Дополнительные аргументы в пользу МСУБД и РСУБД.
2.2 Витрины Данных
Концепция Витрин Данных (Data Mart) была предложена Forrester Research еще в 1991 году. По мысли авторов, Витрины Данных - множество тематических БД, содержащих информацию, относящуюся к отдельным аспектам деятельности организации, должны были стать реальной альтернативой Информационным Хранилищам (Information Warehouse) фирмы IBM.
Концепция Витрин Данных имеет ряд несомненных достоинств.
Аналитики видят и работают только с теми данными, которые им реально нужны.
Целевая БД Витрины Данных максимально приближена к конечному пользователю.
Витрины Данных обычно содержат тематические подмножества заранее агрегированных данных, их проще проектировать и настраивать.
Для реализации Витрин Данных не требуются высокомощная вычислительная техника.
И именно Витрины Данных (или что-то очень близкое к ним) подразумевал Э. Кодд, когда использовал термин "OLAP Server".
Но концепция Витрин Данных имеет и очень серьезные пробелы. По существу, здесь имеется в виду реализация территориально-распределенной информационной системы с мало контролируемой избыточностью, но не предлагается способов для обеспечения целостности и непротиворечивости хранимых в ней данных.
Идея соединить две концепции - Хранилищ Данных и Витрин Данных, по-видимому, принадлежит М. Демаресту (M. Demarest), который в 1994 году в работе "Построение Витрин Данных" [6] предложил объединить две концепции и использовать Хранилище Данных в качестве единого интегрированного источника данных для Витрин Данных.
И сегодня именно такое многоуровневое решение:
первый уровень - общекорпоративная БД на основе РСУБД с нормализованной или слабо денормализованной схемой (детализированные данные);
второй уровень - БД уровня подразделения (или конечного пользователя), реализуемые на основе МСУБД (агрегированные данные);
третий уровень - рабочие места конечных пользователей, на которых непосредственно установлен аналитический инструментарий;
постепенно становится стандартом де-факто, позволяя наиболее полно реализовать и использовать достоинства каждого из подходов:
- компактного хранения детализированных данных и поддержки очень больших БД, обеспечиваемых РСУБД;
- простота настройки и хорошие времена отклика при работе с агрегированными данными, обеспечиваемыми МСУБД.