|
В основе современной технологии систем баз данных лежит реляционная модель,
предложенная Е.Ф.Коддом еще в 1969 году [5]. Первые реляционные системы появились на рынке в 1983 г., а сейчас они прочно заняли доминирующее положение. Реляционная база данных состоит из отношений, которые легче всего представить себе в виде двумерных (плоских) таблиц, содержащих информацию о некоторых классах объектов из предметной области. В случае базы данных, содержащей информацию о телефонных номерах, таким классом объектов будут абоненты городской телефонной сети. Каждая таблица состоит из набора однородных записей, называемых кортежами. Все кортежи в отношении содержат один и тот же набор атрибутов, которые можно рассматривать как столбцы таблицы. Атрибуты представляют свойства конкретных экземпляров объектов определенного класса. Примерами атрибутов отношения Телефонная_книга могут служить Фамилия, Номер, Адрес.
Совокупность отношений и образует базу данных, которая в виде файлов специального формата хранится на магнитных дисках или других устройствах внешней памяти.
Рис. 1.
Пример запроса на языке SQL, выбирающего из отношения Телефонная_книга
номера телефонов и адреса всех абонентов, имеющих фамилию Иванов.
Над реляционными отношениями определен набор операций, образующих реляционную алгебру. Аргументами и результатами реляционных операций являются отношения. Запросы к реляционным базам данных формулируются на специальном языке запросов SQL (ранее называемом SEQUEL) [6]. На рис. 1 показан пример запроса на языке SQL, выполняющего операции селекции и проекции. В нашем случае из отношения Телефонный_справочник осуществляется выборка (селекция) всех записей, у которых атрибут Фамилия принимает значение ‘Иванов’. В результирующее отношение проецируются только столбцы Номер и Адрес.
Если исходное отношение достаточно велико, выполнение операции селекции, скорее всего, потребует значительных затрат машинного времени. Для ускорения мы можем попытаться организовать параллельное выполнение запроса на нескольких процессорных узлах многопроцессорной системы. К счастью, реляционная модель наилучшим образом подходит для «распараллеливания» запросов. В самой общей форме этот процесс можно описать так.
Каждое отношение делится на фрагменты, которые располагаются на различных дисковых устройствах. Запрос применяется не к отношению в целом, а к данным фрагментам. Каждый фрагмент обрабатывается на отдельном процессоре. Результаты, полученные на различных процессорах, затем объединяются (сливаются) в общее результирующее отношение, как это схематично показано на рис. 2. Таким образом, разбивая отношение на n фрагментов в параллельной машине баз данных с n процессорными узлами, мы уменьшаем время выполнения запроса в n раз!
Рис. 2.
Параллельное выполнение запроса. Исходное отношение разбивается на фрагменты по первым двум
цифрам телефонного номера. Каждый фрагмент располагается на отдельном дисковом устройстве и обрабатывается отдельным процессором Pi. Полученные результаты сливаются в единое результирующее
отношение.
Однако не все так просто, как может показаться сначала. Первая проблема, с которой мы столкнемся, — по какому критерию производить деление отношения на фрагменты? В нашем примере на рис. 2 мы применили так называемое упорядоченное разделение, использующее первые две цифры телефонного номера в качестве критерия распределения кортежей по дискам. Но подобный способ разбиения отнюдь не идеален, так как в результате мы скорее всего получим фрагменты, существенно различающиеся между собой по размерам, а это, в свою очередь, может привести к сильным перекосам в загрузке процессоров. При неудачной разбивке отношения на фрагменты на один из процессоров может выпасть более 50% от общего объема нагрузки, что снизит производительность нашей многопроцессорной системы до уровня системы с одним процессором! Известно несколько методов разбиения отношения
на фрагменты в параллельной машине баз данных (см., например, [9]), однако ни один из них не может обеспечить сбалансированной загрузки процессоров во всех случаях. Следовательно, чтобы «распараллеливание» запросов в параллельной машине стало эффективным, мы должны иметь некоторый механизм, позволяющий выполнять перераспределение (балансировку) нагрузки между процессорами динамически, то есть непосредственно во время выполнения запроса.
Другая серьезная проблема, связанная с использованием параллельных машин баз данных, возникает из-за ограниченной масштабируемости. В многопроцессорной системе процессоры делят между собой некоторые аппаратные ресурсы: память, диски и соединительную сеть, связывающую отдельные процессоры между собой. Добавление каждого нового процессора приводит к замедлению работы других, использующих те же ресурсы. При
большом числе участников может возникнуть ситуация, когда они будут дольше ждать того или иного общего ресурса, чем работать. В этом случае говорят об ограниченной масштабируемости системы.
Само число процессоров и дисков влечет за собой и третью серьезную проблему, с которой мы столкнемся при создании параллельных машин, — проблему обеспечения отказоустойчивости системы. Действительно, вероятность выхода из строя магнитного диска в однопроцессорной системе не очень велика. Однако, когда наша параллельная система включает в себя несколько тысяч процессоров и дисков, вероятность отказа возрастает в тысячи раз.
Это рассуждение применимо к любой массовой аппаратной компоненте, входящей в состав многопроцессорной системы. Поэтому для параллельных машин баз данных проблема отказоустойчивости становится особенно важной.
Четвертая проблема связана с обеспечением высокой готовности данных: система должна восстанавливать потерянные данные таким образом, чтобы это было «не очень» заметно для пользователя, выполняющего запросы к базе данных. Если в процессе восстановления 80-90% ресурсов системы тратится исключительно на цели восстановления базы данных, то такая система может оказаться неприемлемой для случаев, когда ответ на запрос должен быть получен немедленно.
|
