Концепции построения и реализации информационных систем

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

Другим подходом к повышению производительности, является вертикальная фрагментация данных. Предположим, что у нас имеется  таблица из 10,000,000 строк, каждая строка состоит из 30 полей (колонок), по 10 символов (байт) каждое. Абстрагируясь от вопросов эффективности или неэффективности хранения данных в конкретной реализации РСУБД, предположим, что объём результирующей БД равен объёму исходных данных. В этом случае, мы получим БД размером в 3 гигабайта.

В традиционных реализациях РСУБД, данные хранятся построчно и при последовательном просмотре, вне зависимости от того, значения из скольких колонок таблицы  требуются для формирования ответа на запрос, будут считаны все 3 гигабайта данных. Но, в аналитических запросах, крайне редко возникает необходимость работы одновременно со всеми колонками таблицы. Именно на этом предположении и основывается механизм вертикальной фрагментации, при использовании которого, данные хранятся не построчно, а по столбцам. Таким образом, каждый столбец представляет собой независимый раздел данных и при запросах на чтение, может обрабатываться независимо. И если в нашем примере, для формирования ответа на запрос потребуются значения из трёх столбцов таблицы, нужно будет считать только 300 мегабайт, а не 3 гигабайта данных.

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

Оптимизаторы  обработки запросов со схемой звезда

• Наиболее широко распространенный сегодня, способ оптимизации запросов типа звезда, предполагает построение промежуточной таблицы, являющейся декартовым произведением используемых в запросе справочных таблиц. И только затем, выполняется последовательный просмотр, но уже только двух таблиц (фактологической и промежуточной), в процессе которого и отсеиваются все строки, не удовлетворяющие условиям выборки. К сожалению, в ряде случаев, такое решение может только наоборот увеличить время обработки или вообще сделать выполнение запроса невозможным.

Покажем это  на примере. Такой способ оптимизации  дает эффект только тогда, когда промежуточная  таблица умещается в оперативной  памяти. Но это не всегда так. Если запрос ссылается на 10 справочных таблиц, в  каждой из которых всего 10 строк длиной в 40 символов, в результате декартова произведения, мы получим промежуточную таблицу в 10 миллиардов строк. А объем оперативной памяти необходимый для размещения такой таблицы, составит 400 гигабайт. И это без учета памяти для операционной системы, системных программ СУБД и буфера для просмотра, теперь уже ставшей относительно маленькой фактологической таблицы.

Bitmap индексы:

• Бесполезны, при малом числе различных значений в индексируемой колонке. Предположим, что индексируется поле “Пол Сотрудника”. Здесь мы имеем всего два значения: Мужской/Женский. И если, данные не были заранее упорядочены по этому полю, и оно используется в качестве критерия выборки, скорее, всего, придётся считать всю таблицу. Это связано с тем, что на физическом уровне считывается не отдельная строка, а блок, в котором размещены значения нескольких строк, и, вероятность того, что в каждом блоке записаны только строки, относящиеся к мужскому или женскому полу, настолько невелика, что использование Bitmap индексов только замедлит выполнение запроса.
• Бесполезны, при большом (более нескольких сотен) количестве различных значений в индексируемой колонке. В этом случае требуется использование различные вариантов комбинированных методов индексирования (комбинация B-деревьев, битовых массивов и списков идентификаторов записей).
• Как правило, значительно снижают производительность системы при выполнении операций обновления данных.

Горизонтальное  разбиение данных

• Разбиение таблицы может производиться только в соответствии со значениями данных одной колонки таблицы.

Например, если таблице содержится информация о  продаже товаров в регионах (50 регионов) за последние 48 месяцев, имеет  смысл разбить таблицу или  по регионам (каждый фрагмент соответствует  определённому региону) или по времени (каждый фрагмент соответствует определённому месяцу). Но, каждое из этих решений, ускорит обработку лишь определённого фиксированного класса запросов.

Вертикальное  разбиение данных

• Эффективно только в том случае, если при выполнении запроса требуется просмотр всего нескольких колонок таблицы и чем меньше соотношение - “Число колонок в таблице/Число колонок, на которые есть ссылки в запросе”, тем менее эффективным оказывается данный метод.
• Методы хранения данных по строкам и по колонкам взаимно исключают друг друга и решение о том, как будут храниться данные, должно быть принято заранее.
• Не поддерживается транзакционная обработка данных и очень сильно снижается производительность системы при выполнении операций обновления данных.

Таким образом, сегодня вновь складывается ситуация, от которой, казалось бы давно и безвозвратно ушли. И вновь, на первый план выносится значимость вопросов проектирования базы данных на физическом уровне: ”Чтобы гибко формировать запросы и быстро получать результат, необходима гибкая комбинация разных высокоэффективных индексных структур. ... корпорации нуждаются в таких проектировщиках базы данных, которые понимали бы, что в ней находится и как она будет использоваться. Хороший проект базы данных на физическом уровне - это залог высокой производительности” (5). До боли знакомая цитата, но взятая из статьи 1996, а не 1976 года. Вспомним региональные и индексно-последовательные файлы, инвертированные списки, иерархические и сетевые БД,

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

МСУБД. Более просто и эффективно аналитические системы реализуются средствами специализированных баз данных, основанных на многомерном представлении данных. В этих системах данные организованы не в виде плоских таблиц (как в реляционных системах), а в виде упорядоченных многомерных массивов - гиперкубов (или поликубов).

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

Казалось бы, все очевидно и выбор однозначен - многомерные БД. Однако не все так  просто.

Многомерные базы, в силу чисто исторических причин, “не умеют” работать с большими объемами данных. На сегодняшний день, их реальный предел - база объемом в 10-20 гигабайт. И хотя, это ограничение, не связано с какими либо внутренними объективными недостатками многомерного подхода и, скорее всего, является временным, сегодня это так. И с этим нельзя не считаться.

К тому же, за счет де нормализации и предварительно выполненной агрегации 20 гигабайт в многомерной базе, в лучшем случае эквивалентны не более чем 1 гигабайту исходных данных. По оценкам Кодда /3/, для систем основанных на многомерном представлении данных, это соотношение лежит в диапазоне от 2.5 до 100. И здесь необходимо остановиться на основном недостатке многомерных БД - неэффективному, по сравнению с реляционными БД, использованию внешней памяти. И это уже объективный фактор.

В основе многомерного подхода лежит представление данных в виде многомерных гиперкубов, при этом обычно предполагается, что внутри такого гиперкуба нет пустот. То есть все ячейки куба всегда заполнены. Это связано с тем, что данные в них обычно хранятся в виде множества логически упорядоченных блоков (массивов) имеющих фиксированную длину, причем именно блок является минимальной индексируемой единицей. И хотя, в МСУБД обычно предполагается, что блоки, полностью заполненные неопределенными значениями, не хранятся, это обеспечивает лишь частичное решение проблемы. Данные в таких системах хранятся в упорядоченном виде. И неопределенные значения устраняются, и то частично только в том случае, если мы за счет выбора порядка сортировки сгруппируем их в максимально большие непрерывные группы.

Но, такое решение, может напрямую вступить в конфликт с тем, что МСУБД работают очень быстро только тогда, когда данные в них заранее отсортированы в том порядке, в котором они должны быть отсортированы в ответе на запрос. Но, порядок сортировки, наиболее часто используемый в запросах, может не совпадать с тем, в котором они должны быть отсортированы, для максимального устранения неопределенных (несуществующих) значений. В результате разработчик может оказаться перед трудно разрешимой дилеммой:

• Пожертвовать быстродействием, но это одно главных достоинств и часто одна основных причин выбора именно МСУБД,
• Пожертвовать внешней памятью, но увеличение объема данных, так же не увеличивает быстродействие. Кроме того, как уже говорилось, МСУБД в настоящее время не приспособлены для работы с большими объемами данных.

Таким образом, МСУБД однозначно хороши только при  выполнении двух требований:

• Уровень агрегации данных в БД достаточно высок и соответственно объем БД не очень велик (не более нескольких гигабайт).
• В качестве граней многомерного куба выбраны достаточно стабильные во времени реквизиты (с точки зрения неизменности их взаимосвязей) и соответственно число несуществующих значений относительно невелико.

К сожалению, сегодня  отсутствуют официальные сравнительные  результаты тестирования производительности систем реализованных на основе многомерных и реляционных баз данных (некоторые дополнительные аргументы в пользу того и другого подхода приведены в таблице 7), но при этом, общая оценка такова: “производительность хорошо настроенных реляционных систем, при использовании схемы звезда, вполне сравнима с производительностью систем реализованных на основе многомерных баз данных”.

Таблица 7. Дополнительные аргументы в пользу МСУБД и РСУБД

Витрины Данных - недостающее звено в концепциях построения аналитических систем

Концепция Витрин Данных (Data Mart) была предложена Forrester Research ещё в 1991. По мысли авторов, Витрины  Данных: - множество тематических БД содержащих информацию, относящуюся к отдельным аспектам деятельности организации, должны были стать реальной альтернативой Информационным Хранилищам (Information Warehouse) фирмы IBM.