Научный отчет за 1998 г. по гранту РФФИ No. 97-07-90148
Название проекта: Разработка высоко-параллельной масштабируемой системы управления базами данных для мультипроцессорной вычислительной системы без совместного использования ресурсов
Руководитель: Соколинский Леонид Борисович
Содержание
Программная структура системы Омега
Операционное окружение СУБД Омега
Уточнение стоимостной модели для оптимизации запросов
Расширение системы программирования Си для МВС-100
Технология коллективной разработки системы Омега
Заключение (сводка полученных результатов)
Программная структура СУБД омега имеет два уровня абстракции. Первый уровень абстракции составляет так называемый слой операционного окружения ядра СУБД. Во второй уровень входят собственно ядро СУБД и утилиты.
Подобная двухуровневая организация системы преследует следующие две основные цели: мобильность и эффективность.
Мобильность. Одним из основных требований к программной архитектуре системы Омега, сформулированных в [7], было требование мобильности. Данное требование подразумевало возможность переноса СУБД Омега с платформы МВС-100 на МВС-1000 и другие сходные аппаратные платформы. Операционное окружение СУБД Омега позволяет полностью абстрагироваться от специфики архитектуры аппаратной платформы. При переносе СУБД Омега на другую аппаратную платформу все изменения локализуются в пределах слоя операционного окружения. Перенос ядра и утилит СУБД заключается в простой перекомпиляции исходных текстов в контексте новой аппаратной платформы.
Эффективность. Другим важным требованием, предъявляемым к системе Омега, является эффективность [6]. В работах [8,9] была проанализирована возможность использования при реализации СУБД общесистемных сервисов, предоставляемых операционными системами общего назначения, прежде всего ОС UNIX. Проведенный анализ, в частности, показывает, что многие сервисы, предоставляемые большинством операционных систем, не удовлетворяют требованиям СУБД по критерию эффективности. Среди таких сервисов можно выделить следующие: управление буферным пулом, управление файловой системой, межпроцессный и межпроцессорный обмен сообщениями, диспетчеризация параллельных процессов. Слой операционного окружения СУБД Омега включает в себя реализацию всех перечисленных сервисов с максимальным учетом требований СУБД и особенностей аппаратной платформы МВС-100. Это позволило повысить эффективность данных сервисов (применительно к СУБД) примерно на порядок, по сравнению с ОС UNIX/Helios для МВС-100.
Операционное
окружение СУБД Омега включает в
себя следующие подсистемы: модуль
топологии, менеджер нитей
(легковесных процессов),
Омега-кондуктор (далее просто
кондуктор), Омега-маршрутизатор
(далее просто маршрутизатор) и
систему управления файлами. В
качестве промежуточного слоя между
аппаратной платформой и
операционным окружением
фигурирует используется ОС Router [10]
разработки ИПМ им. М.В. Келдыша РАН.
ОС Router представляет собой
распределенную операционную
систему класса toolset.
ОС Router обеспечивает следующие
основные функции:
- загрузку программ пользователя с
host-машины на процессорные модули;
- обмен данными между программой и
host-машиной в виде некоторого
подмножества системных функций
ввода/вывода UNIX;
- обмен сообщениями по линкам между
программами, запущенными на
различных вычислительных
процессорах.
Модуль топологии. Модуль топологии инкапсулирует аппаратные особенности топологии МВС и позволяет рассматривать его, как совокупность Омега-кластеров [1,7]. Адресом процессорного узла, таким образом, является пара: адрес кластера и номер узла в кластере. Реализация модуля топологии является аппаратно зависимой.
Менеджер нитей. Процессорный модуль МВС-100 представляет собой фактически двухпроцессорную ЭВМ с разделяемой памятью [1], и в этом смысле подобен ЭВМ с симметричной мультипроцессорной архитектурой. Однако процессоры в модуле МВС не являются симметричными. Один процессор выполняет вычислительные функции, другой - коммуникационные. На вычислительном процессоре выполняется ядро СУБД. Коммуникационный процессор выполняет передачу данных по линкам (высокоскоростным двунаправленным каналам) от одного процессорного модуля к другому, и обмен данными между вычислительным модулем и дисковой подсистемой. Отсюда возникает возможность реального распараллеливания работ в пределах одного процессорного модуля. Общепринятым средством распараллеливания являются процессы. На МВС-100 процессы поддерживаются только ОС Helios, являющейся распределенным аналогом ОС UNIX. В ОС Helios, как и в других реализациях UNIX переключение между процессами является относительно дорогой операцией, составляющей несколько тысяч инструкций [9]. В соответствие с этим, по причине недостаточной эффективности, процессы не могут быть использованы в СУБД для распараллеливания работ, основанного на асинхронном характере обменов. Как указывается в [8] единственной реальной возможностью распараллеливания работ в СУБД является использование легковесных процессов (нитей управления). Отсюда возникла необходимость в разработке менеджера нитей для МВС-100, так как ни OC Helios, ни тем более ОС Router, не поддерживают легковесных процессов.
Одной из потенциальных сложностей реализации менеджера нитей на МВС-100 является отсутствие аппаратного прерывания по таймеру. Таким образом, для квантования времени между нитями необходимо было предложить какую-то иную парадигму кванта времени, отличную от кванта, отсчитываемого таймером.
Одной их серьезных проблем, возникающих при программировании с явным использованием техники легковесных процессов, является проблема синхронизации по отношению к общим ресурсам [8].
В рамках проекта Омега была предложена новая модель организации параллельных процессов на базе парадигмы "производитель-потребитель". В данной модели процессы ассоциируются с потоками данных и являются средством структуризации программы. Данная модель позволяет обеспечить автоматическую синхронизацию и эффективную диспетчеризацию параллельных процессов. В модели предлагается концепция кванта времени, не зависящая от наличия аппаратного прерывания по таймеру. Данная модель детально описывается в работе [2].
На базе указанной
модели для МВС-100 был впервые разработан
и реализован менеджер нитей
(легковесных процессов). Менеджер
нитей обеспечивает возможность
организации параллельных нитей
управления в соответствии с
дисциплиной, определенной в модели
производитель-потребитель [2].
Менеджер нитей поддерживает два
класса нитей: системные нити и
пользовательские нити.
Менеджер нитей поддерживает для
нитей систему статических
приоритетов, назначаемых
пользователем при создании нитей.
Реальное управление нитями
выполняется на основе динамических
приоритетов. Алгоритм вычисления
динамических описан в работе [2].
Основу интерфейса
менеджера нитей составляют
следующие три функции:
init() -
инициализация менеджера нитей;
fork(...) -
создание новой нити;
schedule() -
выполнить диспетчеризацию.
Функция init() осуществляет запуск
менеджера нитей и оформляет
головной процесс в качестве
корневой нити.
Функция fork()
порождает новую нить. При этом
передачи управления новой нити не
происходит. Фактически функция fork
создает новую
запись в таблице нитей менеджера
нитей. Функция возвращает
уникальный идентификатор вновь
созданной нити.
Функция schedule()
передает управление менеджеру
нитей для дальнейшей
диспетчеризации. Менеджер нитей
просматривает все нити,
находящиеся в оперативной памяти и
готовые к выполнению, и выбирает
среди них наиболее приоритетную
нить. Чем меньше значение
динамического приоритета нити, тем
выше ее приоритетность. Ели имеется
несколько нитей с одинаково
высокой приоритетностью на
выполнение, выбирается та нить,
которая дольше всего ждет
процессорный ресурс в состоянии
готовности к выполнению. Если же не
удается вообще найти нити, готовые
к выполнению, менеджер передает
управление корневой нити процесса.
Менеджер нитей позволил сократить
трудоемкость операции
переключения между процессами до
нескольких сотен инструкций. Более
детально менеджер нитей описан в
работе [2]. Менеджер нитей может
использоваться и для других задач
на МВС-100, требующих
распараллеливания операций обмена
по линкам.
Маршрутизатор.
Одним из критических параметров,
влияющих на производительность
СУБД для массивно-параллельных
платформ, являются затраты на
межпроцессный (межпроцессорный)
обмен сообщениями. Однако для
многих ОС общего назначения
стоимость операции обмена может
составлять несколько тысяч
инструкций на одно сообщение. Так,
для PDP-11/70 UNIX, стоимость
межпроцессного обмена составляет
около 5000 инструкций [9].
В ОС Helios для МВС-100 латентная часть
передачи одного сообщения между
процессорными узлами составляет
около 3000 байт. Вследствие этого
система передачи сообщений ОС Helios
не может использоваться в
параллельной СУБД для МВС-100, так
как она не удовлетворяет
требованию эффективности. В ОС Router
латентная часть передачи сообщения
была сокращена до 400 байт. Однако
использование функций передачи
сообщений ОС Router требует явной
синхронизации нитей управления по
отношению к линкам. При наличии
большого количества обменов по
линкам, а для параллельной СУБД это
типичная ситуация, это ведет к
сложному, запутанному и опасному
программированию. Отладка
программы, в этом случае,
становится очень сложным делом.
Отсюда возникает необходимость
разработки системы обмена
сообщениями СУБД Омега, которая, с
одной стороны, подобно ОС Helios для
любых двух узлов многопроцессорной
системы предоставляла любое
количество виртуальных каналов для
межпроцессорного обмена
сообщениями (каждому обмену - свой
канал), и, с другой стороны, была бы
по эффективности сравнима с ОС Router.
Согласно требованию эффективности
система передачи сообщений должна
оптимальным образом учитывать
иерархическую аппаратную
архитектуру системы Омега. В
соответствие с этим система
сообщений была разделена на две
независимые подсистемы, - кондуктор
и маршрутизатор.
Маршрутизатор
обеспечивает межпроцессорный
обмен между узлами, принадлежащими
различным Омега-кластерам.
Реализация маршрутизатора
базируется на специально
разработанном протоколе обмена
сообщениями. Данный протокол
характеризуется тем, что
инициализация передачи сообщения
от одного узла другому требует
только двух элементарных обменов
(элементарный обмен примерно
эквивалентен передаче одного байта
информации). Это является важным
показателем с точки зрения
эффективности, так как при
межкластерном обмене сообщениями длина пути
между узлами может оказаться
относительно большой, и,
соответственно, затраты на один
элементарный обмен - достаточно
высокими. Указанный протокол
детально описан в работе [1].
Маршрутизатор поддерживает любое
количество асинхронных виртуальных каналов
между любыми двумя узлами. Для
идентификации каналов
используется понятие порта (канал,
соединяющий два узла, имеет
одинаковые номера портов с обеих
сторон). В реализации передачи
сообщений посредством каналов
используется копирование данных
типа "память-в-память" и
динамическое выделение памяти.
Однако это не сказывается на
производительности маршрутизатора
критическим образом, так как
межкластерные обмены в системе
Омега относительно редки.
На языке Си была написана
реализация маршрутизатора для
системы Омега. Маршрутизатор
показал хорошую
производительность на тестовых
примерах. Время , затрачиваемое
Омега-маршрутизатором на передачу
сообщения, в среднем, на порядок
меньше времени, затрачиваемого ОС
Helios. Интерфейс и структура
реализации маршрутизатора
детально описаны в работе [1].
Кондуктор.
Кондуктор обеспечивает средства
для организации обменов в пределах
одного Омега-кластера. Внешняя
организация кондуктора близка к
организации маршрутизатора, однако
кондуктор использует принципиально
иной внутренний протокол. В
соответствие с этим протоколом
инициализация передачи сообщения
от одного узла другому требует трех
элементарных обменов, и при
передаче сообщения не использует
копирование данных типа
"память-в-память". Данный
протокол оказывается достаточно
эффективным для внутрикластерных
обменов сообщениями, так как в этом
случае длина пути между узлами не
больше двух, в следствие чего
стоимость одного элементарного
обмена относительна низка. Другой
особенностью реализации
кондуктора является то, что при
создании нового виртуального
канала не требуется динамического
выделения памяти.
На языке Си была выполнена
реализация кондуктора для системы
Омега. Кондуктор, в среднем,
показывает более высокую
производительность на
внутрикластерных обменах, чем
маршрутизатор, однако проигрывает
последнему, когда длина пути между
узлами оказывается большой.
Детально интерфейс и структура
реализации кондуктора описаны в
работе [1].
Система управления файлами. Как указывается в работах [8,9], средства для работы с файлами, предоставляемые операционными системами общего назначения, как правило, оказываются неэффективными для использования в СУБД. Не является исключением и ОС Helios для МВС-100. В ОС Router средства для работы с файлами фактически отсутствуют. В соответствие с этим возникла необходимость разработки специальной системы управления файлами (СУФ) для системы Омега.
СУФ является частью ядра СУБД Омега и функционирует на каждом рабочем узле. Основным назначением СУФ является поддержка понятия файла, как набора записей фиксированной длины. Данные файлы используются на более высоких уровнях системной иерархии для представления отношений (таблиц), индексов и других объектов хранимой базы данных.
Требования к СУФ
системы Омега были
сформулированы в [11]. Среди них
можно выделить следующие:
- СУФ должна предусматривать
возможность внутрифайловой
кластеризации по значению
некоторого поля;
- СУФ должна поддерживать
буферизацию страниц на основе
единого внутреннего буферного
пула. При этом должны
поддерживаться выборка страницы с
упреждением и возможность задания
последовательности вытеснения
страниц из буферного пула.
Ни одна из имеющихся операционных систем для МВС-100 не предоставляет указанных возможностей.
Структура СУФ. СУФ строится как иерархия следующих трех подсистем: менеджер дисков, менеджер страниц и менеджер файлов.
Менеджер дисков обеспечивает представление виртуального диска в виде набора пронумерованных страниц по 4К. Основными операциями менеджера дисков являются следующие: считать страницу с диска в буфер; записать страницу из буфера на диск. Более детально менеджер дисков описан в [12].
Менеджер страниц обеспечивает представление базы данных (точнее ее части), хранящейся на данном виртуальном диске, в виде совокупности наборов страниц, представляющих собой связные списки. Менеджер страниц позволяет создавать и удалять наборы страниц, добавлять страницы в набор, удалять страницы из набора, осуществлять последовательный просмотр набора страниц, а также прямую выборку и выборку с упреждением страницы с указанным идентификатором. Интерфейс и реализация менеджера страниц детально описаны в [11].
Для менеджера страниц был разработан оригинальный механизм вытеснения страниц из буферного пула. Данный механизм базируется на введении для образов страниц статического и динамического рейтингов. Статический рейтинг - это целое число от 0 до 20. Статический рейтинг определяется пользователем при выполнении операции выборки страницы fetch, или при выполнении операции выборки с упреждением prefetch. Статический рейтинг остается неизменным на протяжении всего времени нахождения образа страницы в буферном пуле. При вытеснении страницы из буфера значение статического рейтинга теряется. Динамический рейтинг - это некоторая функция от статического рейтинга, принимающая значения в интервале от 0 до 1 (1 в интервал не входит). Значение динамического рейтинга может меняться во время нахождения страницы в буфере. Способ вычисления динамического рейтинга задается системой. Суммарный рейтинг страницы получается как сумма статического и динамического рейтингов. Если необходимо освободить место в буферном пуле, то вытесняется страница, имеющая минимальный суммарный рейтинг. Если таких страниц несколько, то вытесняется страница, дольше всего находящаяся в буферном пуле. Данный механизм дает возможность пользователю для любых двух страниц явно задать последовательность их вытеснения из буферного пула. Эта возможность является принципиально важной для организации восстановления базы данных после сбоя [9]. Использование динамического рейтинга позволяет реализовывать различные стратегии вытеснения страниц. В качестве эксперимента были реализованы стратегии FIFO и LRU.
Менеджер файлов обеспечивает представление базы данных в виде файлов, представляющих собой наборы неструктурированных записей одинаковой длины (запись имеет только одно информационное поле info). Интерфейс и реализация менеджера файлов детально описаны в [11].
На языке Си была выполнена реализация СУФ для МВС-100. Тестовые испытания показали хорошую производительность СУФ по всем параметрам. Данная СУФ может использоваться и для других задач на МВС-100, требующих интенсивных файловых обменов.
Эмулятор дисковой подсистемы. Мультипроцессорная система МВС-100, на которой выполняется проект, не имеет дисковой подсистемы (по причине финансовых ограничений). В соответствие с этим в рамках проекта был разработан и реализован специальный эмулятор дисковой подсистемы. Эмулятор реализует виртуальные (электронные) диски, используя оперативную память процессорного модуля. Виртуальные диски разбиваются на страницы по 4 Кбайта. Каждой странице присваивается уникальный в пределах диска номер. При реализации эмулятора дисковой подсистемы была использована технология клиент-сервер. Клиентскую часть эмулятора представляет менеджер дисков, запускаемый на каждом рабочем узле. Серверная часть (далее просто сервер) запускается на некотором выделенном узле, играющем роль дисковой подсистемы (обычно это нулевой узел кластера). Был разработан специальный протокол, для обмена данными между клиентами и сервером.
Эмулятор дисковой подсистемы поддерживает следующие основные функции, входящие в интерфейс менеджера дисков:
/* Записать
страницу на диск */
int ds_write(int /* pagenum */, void* /*
buffer */)
/* Считать
страницу с диска */
int ds_read(ds_pagenum_t /* pagenum */,
void* /* buffer */)
/* Сброс
содержимого диска в файл на
host-машине */
int ds_dump(char /* file */)
/* Загрузка
содержимого диска из файла на
host-машине */
int ds_reset(char /* file */)
После приобретения и установки реальной дисковой подсистемы необходимо будет переписать только серверную часть и реализацию клиента. Интерфейс клиента (менеджера дисков) при этом останется неизменным (в части функций чтения и записи страниц), что позволит ограничиться минимальными переделками в исходных текстах системы в целом. Более детально эмулятор дисковой подсистемы обсуждается в [15].
Проблему поиска
оптимального плана выполнения
запроса можно условно разбить на
две взаимосвязанные подзадачи:
определение оптимального порядка
выполнения операций и
распределение операций по
процессорам. В работе [13] была
построена стоимостная модель,
позволяющая определить
оптимальный порядок выполнения
операций. Эта
модель не учитывала распределения
операций по процессорам. К
настоящему моменту модель уточнена
таким образом, чтобы ее действие
распространялось на задачу
распределения процессоров. Для
этого в функцию стоимости
реляционной операции введена
зависимость от количества
процессоров, отводимых на
выполнение операции;
соответствующим образом изменена
функция стоимости плана выполнения
запроса:
Здесь N -
количество кортежей в исходном
отношении,
ki - количество
процессоров, отводимых на
выполнение операции qi
,
K - общее
число процессоров параллельной
системы,
gi и si - введенные в [13]
коэффициенты распараллеливания и
селективности операции qi.
В многопроцессорных системах
несколько операций могут
выполняться параллельно, в этом
случае время выполнения этой
группы операций будет равняться
времени выполнения самой
длительной операции из группы. План
может быть разбит на m групп параллельно
выполняемых операций, mО (1,...,l). Пусть nr
- номер
последней операции r-той группы, n0=1,
k=ki , ... , ki - вектор назначений
процессоров. Тогда функция
стоимости плана будет иметь
следующий вид:
Таким образом, проблема поиска
оптимального плана выполнения
запроса сводится к следующей
задаче:
Более детально
уточнение стоимостной модели
описано в работе [14].
Отладчик. Система программирования Си для МВС-100 не содержит встроенного отладчика. Поэтому в рамках проекта Омега был разработан и реализован простой отладчик, выполняющий трассировку программы и отладочную печать.
Отладчик состоит
из функций:
Begin_debug() -
начать отладочную печать;
Print_debug() -
вывести значения переменных;
End_debug() -
закончить отладочную печать.
Отладчик
позволяет задавать номера
процессоров, для которых следует
выводить отладочные сообщения. В
отладочные сообщения
автоматически могут включаться
номера процессоров.
Отладчик поддерживает два режима
работы, - режим выдачи отладочной
информации в виде дампа и режим
трассировки, обеспечивающий
пошаговое выполнение программы.
Использование данного отладчика,
как показал опыт, позволяет
существенно повысить
эффективность процесса отладки
сложных программ. Более детально
отладчик описан в работе [4].
Профилировщик.
Одной из наиболее важных задач,
возникающих при проектировании и
создании СУБД, является проблема
оптимизации запросов. Наибольшие
временные затраты при выполнении
запроса в параллельных системах
управления базами данных для
платформ с кластерной архитектурой
приходятся на передачу данных
между процессорными узлами и обмен
с дисками. Поэтому для оценки того
или иного плана выполнения запроса
к базе данных необходимо знать
общий объем данных, вовлекаемых в
обмен с дисками и передачу по
линкам.
С этой целью в рамках проекта Омега
был спроектирован и реализован
оригинальный профилировщик,
позволяющий решить эту задачу для
многопроцессорной среды МВС-100.
Профилировщик
имеет следующие основные функции:
Create_tag(int tag) -
создать тэг;
Begin_profile(int tag)
- начать профилирование по
указанному тегу;
End_profile(int tag) -
закончить профилирование по
указанному тегу;
int Link_read(int tag)
- выдает количество операций чтения
по линкам;
int Link_write(int
tag) - выдает количество операций
записи по линкам;
int Disk_read(int tag) - выдает количество
операций чтения с диска;
int Disk _write(int
tag) - выдает количество операций
записи на диск.
Функция Create_tag() создает в таблице
профилировщика учетную запись с
указанным тегом. Ключевыми
атрибутами записи являются тег и
идентификатор текущей нити
управления. Учетная запись, кроме
того, содержит поля, в которых будут
суммироваться передачи по линкам и
обмены с дисками, инициируемые
данной нитью управления. Функция Begin_profile() обнуляет счетчики
сообщений и обменов, и включает
режим профилирования для
указанного тега. Функция End_profile() выключает режим
профилирования для указанного
тега.
Каждый обмен с диском и каждая
передача сообщения, выполняемая
некоторой нитью управления,
увеличивают соответствующие
счетчики всех своих
профилировочных записей, для
которых включен режим
профилирования.
Тэг, по существу, является
некоторым идентификатором,
позволяющим пользователю
суммировать результаты
профилирования, полученные при
выполнении одного запроса на
нескольких процессорах. Более
детально профилировщик описан в
работе [4].
Эффективная разработка больших программных систем не возможна без использования современных технологий программирования. В соответствие с этим была разработана и внедрена оригинальная технология разработки программ [4] для МВС-100. Средства программной поддержки указанной технологии включают в себя следующие основные компоненты: систему контроля версий CVS, документатор DOC++, и компилятор C фирмы Portland Group (PGCC) для i860. Все три программных продукта являются разработками независимых фирм. Краткое описание данных систем приводится в [4].
Организация
коллективной разработки системы
Омега. Схематично
технологический цикл можно описать
следующим образом. Пусть
программист X разрабатывает
некоторую подсистему D системы OMEGA, а программист Y параллельно
разрабатывает некоторую
подсистему E
системы OMEGA.
Предполагается, что ранее были
разработаны подсистемы A, B и C, которые и составляют текущий
прототип системы OMEGA.
Вся история проекта хранится в OMEGA-репозитории,
который поддерживается средствами
CVS. Данный репозиторий хранит все
исходные тексты подсистем A, B и C, и все изменения,
которые были в них произведены
после включения в репозиторий.
С помощью компилятора PGCC и
программы-библиотекаря ar860 функции
подсистем A, B и C объединены в
библиотеку OMEGA-Lib.
Разрабатываемые подсистемы D и E образуют следующий
уровень иерархии по отношению к
подсистемам A, B и C и являются
независимыми друг от друга.
С помощью системы DOC++ из исходных
текстов подсистем A, B и C сгенерирован
гипертекстовый Справочник по
функциям OMEGA-Lib в формате HTML,
который может просматриваться
любым WWW обозревателем.
Для обращения к функциям подсистем A,
B и C программист получает
из репозитория тексты
соответствующих #include файлов.
С помощью компилятора PGCC строятся
загрузочные модули тестов
подсистем D и
E, при этом в
качестве параметра компиляции
указывается библиотека OMEGA-Lib.
Загрузочные модули тестов D и E выполняются на МВС. По
полученным отладочным дампам
анализируются и локализуются
ошибки. В исходные тексты вносятся
исправления, и цикл повторяется.
После того, как все тесты новой
подсистемы, скажем D, прошли без ошибок, ее
исходные тексты передаются
библиотекарю проекта. При этом,
данные тексты уже содержат
спецификации функций подсистемы D в соответствии с
синтаксисом DOC++.
Библиотекарь выполняет следующую стандартную последовательность действий. Он помещает исходные тексты подсистемы D в свою рабочую копию проекта. После этого библиотекарь собирает и запускает комплексный тест системы OMEGA. Если при выполнении теста возникли ошибки, подсистема возвращается программисту на доработку. Если комплексный тест прошел нормально, то средствами CVS библиотекарь помещает исходные тексты подсистемы в Репозиторий проекта. Затем, с помощью компилятора PGCC и программы-библиотекаря ar860, создается новый вариант библиотеки OMEGA-Lib, включающий в себя функции подсистем A, B, C и D. И, наконец, с помощью системы DOC++ генерируются HTML страницы, содержащие справочную информацию по функциям подсистемы D, которые добавляются в Справочник по функциям OMEGA-Lib.
Аппаратно-системное
обеспечение коллективной
разработки СУБД Омега.
Центральным звеном
аппаратно-системного обеспечения
является UNIX/Linux сервер, играющий
роль host-машины для МВС-100. Для
запуска PGCC, в том числе удаленного,
используется DOS-эмулятор. Это
позволяет вписать весь
технологический цикл разработки в
рамки одной операционной системы, -
UNIX/Linux.
Данное аппаратно-системное
обеспечение предусматривает два
варианта рабочего места
программиста.
Первый вариант полностью ориентирован на среду Linux. В качестве редактора используется редактор GNU Emacs, имеющий встроенную поддержку языка С и встроенный интерфейс с системой контроля версий CVS. Фактически Emacs играет роль интегрирующей оболочки, позволяющей редактировать, компилировать и запускать программы на языке С. На рабочих станциях разработчиков устанавливается OC Windows 95 или Windows NT. Рабочие станции находятся в общей локальной сети с Linux сервером, являющимся host-машиной для МВС-100. Для работы с Linux сервером на рабочих станциях используются Х-терминалы.
Второй вариант в качестве редактора использует среду Borland C++. Копии исходных текстов находятся на рабочей станции. После редактирования они по FTP пересылаются на Linux сервер. В качестве UNIX терминалов во втором варианте используется Telnet. С помощью DOS эмулятора на сервере Linux запускается PGCC компилятор, после чего задача запускается на выполнение на МВС-100. Оба варианта интенсивно используют утилиту Make.
Второй вариант
имеет два важных преимущества.
Во-первых, он позволяет работать
через Internet. В первом варианте этому
препятствует недопустимо низкая
для Х-терминала скорость передачи
данных через Internet.
Во-вторых, для аппаратно
независимых частей программной
системы, среда Borland C++ может
использоваться также для
компилирования, запуска и, что
особенно важно, для отладки
программ, так как содержит мощный
встроенный отладчик, отсутствующий
в PGCC (в комплектации МВС-100).
Описанная технология может быть полностью перенесена на МВС-1000 при минимальных доработках. Описанный технологический цикл и соответствующее программное обеспечение могут быть использованы на МВС-100/1000 для коллективной разработки больших программных систем различного назначения.
Прототипирование СУБД Омега включает в себя задачу построения программного интерфейса между ядром СУБД Омега и некоторой полнофункциональной СУБД или SQL сервером, работающим под управлением UNIX/Linux. Данный интерфейс обеспечивает возможность промышленного использования СУБД Омега еще на этапе прототипирования [6]. В соответствие с этим была разработана технология взаимодействия между ядром СУБД Омега, работающим на МВС-100, и СУБД Postgres95, работающей в среде UNIX/Linux. В основе данной технологии лежит использование FIFO-файлов (first in, first out) ОС UNIX. На базе данной техники был реализован прототип шлюза Омега-Postgres, с помощью которого был произведен экспериментальный обмен данными между двумя системами.
Разработана
программная структура СУБД Омега.
Спроектированы, закодированы
и полностью отлажены следующие
подсистемы ядра СУБД: модуль
поддержки топологии
межпроцессорных соединений,
эмулятор дисковой подсистемы,
система управления файлами,
система передачи сообщений,
система поддержки легковесных
процессов. В стадии разработки
находятся следующие подсистемы:
система параллельной оптимизации
запросов,
система поддержки фрагментации и
репликации файлов, система
поддержки сложных типов данных,
система поддержки различных
методов доступа к записям файла.
Разработана и внедрена
оригинальная технология
коллективной разработки больших
программных систем для МВС-100.
Разработано и реализовано
расширение системы
программирования Си на МВС-100 в виде
отладчика и высокоуровневого
профилировщика.
Разработаны эффективные протоколы
для внутрикластерного и
межкластерного обмена сообщениями,
оптимальным образом учитывающие
особенности аппаратной
архитектуры системы Омега. Данные
протоколы реализованы в подсистеме
передачи сообщений.
Разработана оригинальная модель
организации параллельных
процессов на базе парадигмы
"производитель-потребитель". В
данной модели процессы
ассоциируются с потоками данных и
являются средством структуризации
программы. Данная модель позволяет
обеспечить автоматическую
синхронизацию и эффективную
диспетчеризацию параллельных
процессов. Указанная модель
реализована в подсистеме поддержки
легковесных процессов в ядре СУБД
Омега.
Разработан оригинальный механизм
вытеснения страниц из буферного
пула, использующий концепцию
статического и динамического
рейтингов. Данный механизм
позволяет реализовывать
эффективные стратегии вытеснения,
учитывающие специфику СУБД.
Указанная техника применена в
реализации системы управления
файлами в рамках ядра СУБД Омега.
Выполнено уточнение стоимостной
модели, используемой для оценки
параллельного плана выполнения
запроса.
Разработана технология
взаимодействия между ядром СУБД
Омега и СУБД Postgres95. Реализован
прототип шлюза Омега-Postgres.
Реализована технология доступа к
системе МВС-100 через Internet.
Создана WWW страница, посвященная
суперкомпьютеру МВС-100,
установленному в Челябинском
государственном университете:
http://www.csu.ac.ru/mvs/.
Дополнена WWW страница, посвященная
данному проекту:
http://www.csu.ac.ru/~sok/grants/rfbr/1997/k_omega.html.
Результаты,
полученные в ходе второго года
работ по данному проекту
докладывались на двух
всероссийских и двух международных
конференциях, и находятся в русле
современных научных исследований в
области параллельных баз данных,
проводимых в России и за рубежом.
Проект Омега зарегистрирован на WWW
Сервере Лаборатории Параллельных
Информационных Технологий НИВЦ
МГУ: http://parallel.srcc.msu.su/in_russia/organizations.html
и на WWW Сервере Института
программных систем РАН:
http://www.botik.ru/~t-system/Parallel-Russia/.
1. Sokolinsky L.B. Interprocessor Communication Support in the Omega Parallel Database System // Proceedings of the 1st International Workshop on Computer Science and Information Technologies (CSIT'99), Moscow, Russia, January 18-22, 1999. MEPhI Publishing. 1999. P. 98-104.
2. Соколинский Л.Б. Эффективная организация легковесных процессов в параллельной СУБД Омега для МВС-100 // Фундаментальные и прикладные аспекты разработки больших распределенных программных комплексов: Тез. докл. Всероссийск. науч. конф. (21-26 сентября 1998 г., г. Новороссийск). -М.: Изд-во МГУ. 1998. C. 132-138.
3. Соколинский Л.Б., Цымблер М.Л. Проект создания параллельной СУБД Омега на базе суперкомпьютера МВС-100/1000 // Телематика'98: Тез. докл. Всероссийск. науч.-метод. конф. (8-11 июня 1998 г., г. Санкт-Петербург). -СПБ.: Республ. науч. центр КТСВШ. 1998. C. 154-155.
4. Zymbler M.L. Computer Aided Design Facilities for Prototyping the Omega DBMS // CSIT'99, Proceedings of the 1st International Workshop on Computer Science and Information Technologies, January 18-22, 1999, Moscow, Russia. MEPhI Publishing. 1999. P. 76-81.
5. Лымарь Т.Ю. Уточнение стоимостной модели оптимизации запросов с учетом распределения процессоров // Алгоритмический анализ некорректных задач: Тез. докл. Всерос. науч. конф. -Екатеринбург: УрГУ. 1998. C. 149-150.
6. Sokolinsky L., Axenov O., Gutova S. Omega: The Highly Parallel Database System Project // Proceedings of the First East-European Symposium on Advances in Database and Information Systems (ADBIS'97), St.-Petersburg. September 2-5, 1997. Vol. 2. P. 88-90.
7. Научный отчет за 1997 г. по гранту РФФИ No. 97-07-90148 "Разработка высоко-параллельной масштабируемой системы управления базами данных для мультипроцессорной вычислительной системы без совместного использования ресурсов" // http://www.csu.ac.ru/~sok/grants/rfbr/1997/k_rep1997.html
8. Кузнецов С.Д. Операционные системы для управления базами данных // СУБД. 1996. No. 3. С. 95-102.
9. Stonebraker M. Operating System Support for Database Management // CACM. July 1981. Vol. 24. No. 7. P. 412-418.
10. Лацис А.О. Операционная среда ROUTER для транспьютерных систем // http://www.csu.ac.ru/mvs/router.doc.ru.html
11. Соколинский Л.Б. Система управления файлами. Отчет OMEGA03. // http://www.csu.ac.ru/~sok/papers/omega_rep/filesys.html
12. Соколинский Л.Б. Структура системного окружения СУБД Омега. Отчет OMEGA02. // http://www.csu.ac.ru/~sok/papers/omega_rep/structure.html
13. Соколинский Л.Б., Лымарь Т.Ю. О выборе оптимального плана выполнения запроса в параллельной системе баз данных // Проблемы оптимизации и экономические приложения: Тезисы докладов международной конференции. -Омск: Омск. гос. ун-т. 1997. С.146.
14. Лымарь Т.Ю. Уточнение стоимостной модели оптимизации запросов с учетом распределения процессоров // Алгоритмический анализ некорректных задач: Тезисы докладов всероссийской конференции. Екатеринбург: УрГУ. 1998. С. 149-150.
15. Соколинский Л.Б. Принципы разработки СУБД Омега. Отчет OMEGA01. // http://www.csu.ac.ru/~sok/papers/omega_rep/principles.html