CC BY
39
ПРИНЦИПЫ РЕАЛИЗАЦИИ СИСТЕМЫ УПРАВЛЕНИЯ ФАЙЛАМИ В ПАРАЛЛЕЛЬНОЙ СУБД ОМЕГА ДЛЯ МВС-100
J1 Б Соколинский , M JT Цымблер *
Челябинский государственный университет
В статье описывают!я принципы разработки и программная структура сис «кмы управления файлами (СУФ) ядра параллельной СУБД Омега для отечественного < уперкомпьютера МВС 100 Формулируются требования к СУФ Дается описание об щей ипрунпуры СУФ и ее компонент Предлагается стратегия вытеснения страниц, основанная на их динамических и статичетих рейтингах Описываются алгоритмы простои выборки страниц и выборки с упреждением Предлагается эффективный про токол для взаимодействия с дисковой подсистемой Описывается архитектура зму лятора дисновои подсистемы Описанная СУФ реализована на MDC 100 и допускает перенос на МВС 1000 при минимальных доработках
Ключевые слова система баз данных управление фаилами, алгоритм вытес нения страниц, параллельная СУБД, мультипроцессорные системы с массовым парад д< ли 1М0М
1. Введение
Высокопроизводительные параллельные системы баз данных в насто ящее время являюхся одним из основных приложений многопроцессорных вычислительных систем с массовым параллелизмом [1] Хотя в данной об-ии 1и дос 1игнух существенный прогресс и уже имеются промышленно экс-п 1Уагируемые сисюмы (см , например, [2, 3, 4]), в области параллельных баз данных остается мною открытых вопросов и нерешенных проблем [5] Одной из т аких проблем является выбор аппаратной архитектуры для параллельной СУБД
В соответствии с классификацией Стоунбрейкера [6] аппаратная архитектура параллельных СУБД традиционно делилась на три класса ар хитектура с разделяемой памятью, архитектура с разделяемыми дисками и архитектура без совместною использования ресурсов Сравнительный анализ данных архиюктур показал, что каждая из них имеет свои преимущества и недостатки [б, 7] Так, например, системы с разделяемой памятью имеют наилучшие показатели по производительности Однако такие сис те
Работа выполнена при поддержке Ро< (шш ксн о фонда фундаментальных исследова ним (грант N 97 07 90148)
принципы реализации системы управления файлами
177
мы плохо масштабируются и отличаются относительно высокой стоимостью. Системы без совместного использования ресурсов, наоборот, хорошо масштабируются, но для таких систем трудно достичь хорошего баланса загрузки [8].
В соответствии с этим в настоящее время сложилась тенденция к использованию систем с гибридной или иерархической архитектурой [9; 10]. Гибридные архитектуры обладают большим многообразием, чем традиционные, и в настоящее время являются еще недостаточно исследованными.
В работе [11] была предложена двухуровневая иерархическая архитектура без совместного использования ресурсов. Данная архитектура использовалась при разработке параллельной СУБД Омега на платформе суперЭВМ МВС-100.
Отечественная суперЭВМ МВС-100 [12; 13], разработанная в НИИ "Квант", ИНМ им. М.В. Келдыша РАН и ИММ УрО РАН, представляет собой многопроцессорную систему с модульной архитектурой. В соответствии с таксономией Флинна [14] МВС-100 относится к классу MIMD архитектур.
Основу МВС-100 составляют процессорные модули стандартной структуры [13].
Каждый модуль представляет собой двухпроцессорную ЭВМ, состоящую из вычислительного и коммуникационного процессоров (рис. 1). Коммуникационный и вычислительный процессоры разделяют общую статическую память SRAM объемом 16 - 32 Мб. Помимо этого коммуникационный процессор имеет свою собственную, более быструю динамическую память DRAM объемом 4 Мб. Синхронизация коммуникационного и вычислительного процессоров реализована аппаратно. Единственными внешними устройствами процессорного модуля являются скоростные двунаправленные каналы-линки, имеющиеся у коммуникационного процессора. Коммуникационный процессор имеет четыре липка. С помощью этих линков процессорные модули соединяются друг с другом и с дисковой подсистемой. Система может включать в себя сотни вычислительных модулей, образующих ссиь процессорных элементов. Полученная таким образом сеть связана одним своим линком с управляющей ЭВМ (Host-машиной), представляющей собой IBM PC-совместимую рабочую станцию.
В качестве операционной системы на МВС-100 используется ОС Router разработки ИПМ им. М.В. Келдыша РАН. В качестве операционной системы Host-машины обычно используется ОС UNIX/Linux. ОС Router, поставляемая с МВС-100, не предоставляет фактически никаких средств для работы с файлами дисковой подсистемы. Отсюда возникает необходимость разработки специальной системы управления файлами для СУБД Омега.
Рис 1 Структура процессорного модуля МВС 100
Статья ор1 анизована следующим образом Раздел 2 содержит обзор аппаратом и программной архитектуры системы Омега В разделе 3 опи сывается общая структура СУФ и приводятся требования к ней Раздел 4 содержит изложение принципов проектирования и реализации менеджера дисков, описание эмулятора дисковой подсистемы и описание протоко л а обмена с дисковой подсистемой В разделе 5 описываются принципы проектирования и реализации менеджера страниц, а также приводятся ап-горитмы простой выборки страниц и выборки с упреждением Раздел 6 посвящен принципам разработки менеджера файлов Раздел 7 содержих заключение
2. Архитектура системы Омега
2 1 Аппаратная архитектура cmcifmbi Омега
Аппаратная архитектура системы Оме1 а представляет собой двухуровневую иерархическую архитектуру бе? совместного использования ресурсов
11а первом уровне иерархии процессорные модули объединяю 1ся в Омега кластеры стандартной струк туры Возможная структура Оме! а-кла стера для МВС-100 изображена на рис 2 Омега-кластер состоит из четырех процессорных модулей, объединенных в кольцо Каждый процессорный модуль соединен одним линком с дисковой подсистемой Дисковая подсисте ма представляет собой особый модуль, включающий в себя коммуникационный процессор, который посредством SCSI-шины соединен с четырьмя
Рис 2 Структура Омега-кластера
(ПМ - процессорный модуль; МДП - модуль дисковой подсистемы)
Рис 3 Возможная конфигурация еж теVIII Омега ("простая линейка'')
дисковыми накопителями (по одному на каждый процессорный модуль) 0ме1 а-кластер имеет четыре свободных линка для связи с другими Омега-клас т ерами.
На втором уровне иерархии Омега-кластеры связываются в единую вычислительную систему Топология межкластерных соединений не фиксируется и может быть различной в различных Омега-системах. На рис. 3 приведен пример возможной топологии соединений, называемой "простой линейкой" Наличие двух НовЬ-машин в системе мотивируется соображениями охказоустойчивости системы в целом. Описанная архитектура является отказоустойчивой по любому аппаратному компоненту (процессор, лише, дисковый накопитель, НоБ1;-машина и др.)
2 2 Программная архитектура системы Омега
Программная структура системы Омега (рис. 4) имеет два уровня абстракции Первый уровень абстракции составляет так называемый слой
операционного окружения ядра СУБД. Во второй уровень входят собственно ядро СУБД и утилиты.
Операционное окружение СУБД Омега включает в себя следующие подсистемы: модуль топологии, менеджер нитей (легковесных процессов), Омега-кондуктор, Омега-маршрутизатор и систему управления файлами
В качестве промежуточного слоя между аппаратной платформой и операционным окружением используется ОС Router. ОС Router представляв! собой распределенную операционную систему класса toolset. ОС Router обеспечивает следующие основные функции
— загрузка программ пользователя с Host-машины на процессорные модули,
— обмен данными между программой и Host-машиной в виде некоторого подмножества системных функций ввода/вывода UNIX,
— обмен сообщениями по линкам между программами, запущенными на различных вычислительных процессорах.
Модуль топологии инкапсулирует аппаратные особенности топологии МВС-100 и позволяет рассматривать его как совокупность Омега-кластеров Адресом процессорного узла, таким образом, является пара адрес кластера и номер узла в кластере Реализация модуля топологии является аппарат но зависимой
Менеджер нитей обеспечивает поддержку легковесных процессов (нитей или потоков управления) Поддерживается два типа нитей: системные и пользовательские Системные нити порождаются в итерационном окружении Пользовательские нити порождаются в ядре СУБД и в утилитах. Управления нитями и их синхронизация осуществляются на основе модели производитель - потребитель, описанной в работе [15].
Омега-кондуктор обеспечивает эффективную реализацию внутриклас-терных обменов сообщениями на базе механизма виртуальных каналов. Протокол обмена базируется на фиксированной сильносвязанной топологии внутрикластерных соединений [16]. Данный протокол оптимизирован для выполнения большого количества параллельных обменов короткими сообщениями
Омега-маршрутизатор обеспечивает эффективную реализацию меж-клас хорных обменов сообщениями на базе механизма виртуальнхэхх каналов Протокол обмена оптимизирован для случая сравнительно небольшого количества параллельных обменов длинными сообщениями [16].
Ядро СУБД
Аптаратно-не зависимый уровень
Операционное окружение
-кондуктор
Л- маршрутизатор
Менеджер дисков
Модуль топологии | Менеджер нитей
Аппаратиэ-зависимьш уровень
JI
ОС Router
Jl
Аппаратный уровень
Рис. 4. Программная структура СУБД Омега
3. Общая структура СУФ
СУФ является частью ядра СУБД Омега и функционирует на каждом рабочем узле. Основной целью СУФ является поддержка понятия файла как набора записей фиксированной длины. Данные файлы используются на более высоких уровнях системной иерархии для представления отношений (таблиц), индексов и других объектов хранимой базы данных.
Основными требованиями к СУФ являются следующие:
— СУФ должна поддерживать файлы, состоящие из записей фиксированной длины. Каждый файл должен иметь идентификатор, уникальный в пределах диска. Каждая запись файла должна иметь идентификатор, уникальный в пределах диска.
— СУФ должна предусматривать возможность введения внутрифайловой кластеризации на более высоких уровнях системной иерархии. Межфайловая кластеризация в системе Омега не поддерживается.
— СУФ должна поддерживать буферизацию страниц на основе единого внутреннего буферного пула. Доступ к содержимому файла возможен только через буфер.
— СУФ должна поддерживать виртуальную архитектуру без еовмесгно-ю использования ресурсов. Это означает, что за каждым процессорным узлом Омега-кластера закрепляется отдельный виртуальный диск (дисковый пул). Процессорный узел не вправе обращаться к чужим виртуальным дискам (дисковым пулам).
— СУФ не должна предоставлять средств для работы с дисками, не принадлежащими данному Омега-кластеру.
— СУФ не должна поддерживать фрагментацию и репликацию файлов. Репликация и фрагментация реализуются на более высоких уровнях системной иерархии. Это означает, что каждый фрагмент или реплика отношения (таблицы), с точки зрения СУФ, реализуется в виде отдельного независимого файла.
СУФ включает в себя менеджер дисков, менеджер страниц и менеджер файлов (рис. 5).
Менеджер дисков обеспечивает представление виртуального диска в виде набора пронумерованных страниц по 4Кбайта. В будущем предполагается добави гь возможность указывать для файла желаемый размер страницы, исходя из имеющихся вариантов (например, 4, 24, или 32 Кбайта).
Менеджер страниц обеспечивает представление базы данных (точнее, ее части), хранящейся на данном виртуальном диске, в виде совокупности наборов страниц, представляющих собой связные списки. Он позволяет создавать и удалять наборы страниц, добавлять страницы в набор, удалять их из набора, осуществлять последовательный просмотр набора страниц, а также прямую выборку страницы с указанным идентификатором
Менеджер файлов обеспечивает представление базы данных в виде файлов наборов неструктурированных записей одинаковой длины (запись имеет только одно информационное поле т/о). Он позволяет создавать и удалять файлы, добавлять в файл новые записи, удалять записи из файла,
Рис. 5. Общая структура СУФ
изменять содержимое записи (значение поля гп/о), осуществлять прямой доступ к записи по ее идентификатору, а также создавать итераторы, выдающие без повторений указатели на все записи файла.
4. Менеджер дисков
Менеджер дисков реализует интерфейс ввода-вывода для организации обменов с дисковой подсистемой. Он позволяет абстрагироваться от аппаратных особенностей дисковой подсистемы кластера и рассматривать ее как виртуальное устройство, состоящее из некоторого числа логических дисков со страничной организацией.
Количество дисков берется равным количеству процессорных модулей класюра. За каждым процессорным модулем закрепляется свой диск Процессор не может обращаться к "чужим" дискам. Данный подход моде-лируе 1 архитектуру без совместного использования ресурсов.
Ра шер страницы диска является параметром генерации системы Омега и берется равным 4 Кбайтам.
•1 1 Эмулятор дисковой подсистемы
Аппаратная платформа, на которой выполнялась реализация прототипа системы Омега, представляет собой мультипроцессор МВС-100 в конфигурации и 4 четырех процессорных модулей без дисковой подсистемы. Поэтому при разработке прототипа СУБД Омега возникла необходимость создания эмулятора дисковой подсистемы.
Для создания виртуальных дисков могу г использоваться следующие два подхода:
- использование оперативной памяти одного из процессорных модулей ~ для создания электронных дисков,
— использование дисков Нов^машины.
Эмулятор дисковой подсистемы (ЭДГ1) на базе электронного диска бу-дс1 значительно превосходить ЭДП на базе дисков НовЬ-машины по эффективности доступа Это может ощутимым образом сказаться на эффективности процесса отладки и профилирования системы в целом. Отрицательной с гороной использования электронных дисков является их энергозависимая природа При сбоях и рестартах системы информация на электронных дисках будет теряться, что, в свою очеоедь, осложнит процесс отладки.
Исходя из этого, был выбран промежуточный вариант, предполагающий совместное использование и электронных дисков процессорного модуля, и магнитных дисков Нояк-машины. При инициализации ЭДП происходит автоматическое считывание базы данных с диска Нок1-машины и загрузка ее в электронные диски некоторого выделенного процессорного модуля. При нормальном завершении работы системы происходит обратный сброс базы данных с электронного диска на диск Ноэ^машины. В процессе работы ЭДП могут выполняться промежуточные сбросы на диск НоБС-машины
Для моделирования дисковой подсистемы на имеющейся конфигурации МВС-100 был выделен процессорный модуль, являющийся корневым.' Данный модуль непосредственно связан но линку с ШЫ-машиной. Процессорный модуль дисковой подсистемы не используется как вычислительный модуль Таким образом, фактически моделировался Омега-кластер с тремя процессорными модулями и одной дисковой подсистемой.
Эмулятор дисковой подсистемы инкапсулирует в себе аппаратные особенности дисковой подсистемы. Данный подход позволяет при переходе на аппаратную конфигурацию с реальной дисковой подсистемой оставить практически неизменным интерфейс менеджера дисков, что, в свою очередь, дает возможность ограничиться небольшими переделками при переносе системы в целом.
4 2. Принципы проектирования менеджера дисков
Менеджер дисков реализует архитектуру виртуальных каналов. Это означает, что по линку, соединяющему процессорный модуль с дисковой подсистемой, параллельно может производиться любое количество операций чтения/записи.
Основные операции, входящие в интерфейс менеджера дисков, изображены на рис. 6.
При проектировании менеджера дисков была использована технология клиент - сервер. Клиентская часть менеджера дисков запускается на каждом рабочем узле. Серверная часть запускается на модуле дисковой подсистемы.
Сервер обслуживает запросы клиентов на выполнение операций с дисковой подсистемой Клиенты и сервер обмениваются сообщениями, которые состоят из двух частей, заголовка и информационной части гп/о. Заголовок сообщения имеет следующие поля: идентификатор операции, тип операции, номер страницы, номер узла клиента. Информационная часть не имеет структуры, это байтовый массив, длина которого совпадает с размером
Л Записать страницу на диск в асинхронном режиме 7
in1/*No канала*/ds_write(int Лномер страницы*/ void * Г указатель на буфер *t)
Л Считать страницу с диска в асинхронном режиме 7
in! Г No канала*/ ds_read(int /*номер страницы 7 void * Г указатель на Ьуфер
/* Проверить завершение write/read операции 7 1П1Г1 да 0 нет 7 ds_d one(int Г No канала*/)
Г Сброс содержимого виртуального диска в файл на host машине */ void ds_dump(char*/* имя файла*/)
Г Загрузка содержимого виртуального диска из файла на host машине 7 void ds_reset(char */* имя файла 7)
Рис 6 Основные функции интерфейса менеджера дисков
страницы Передача сообщения выполняется в два этапа сначала передает ся заголовок, а затем - часть info
4 3 Принципы реализации менеджера дисков
При выполнении клиентом операций с!з_геас1 и с^-'я/т^е дескрипго ры этих операций добавляются в таблицу операций Таблица операций ор-I авизована как очередь и имеет следующие поля идентификатор операции, номер страницы, номер узла клиента, указатель на буфер и состояние операции Таблица операций обрабатывается системной нитью клиента Фактор функция системной нити [15] пишется таким образом, чтобы нить активизировалась только при завершении асинхронных операций чтения/записи по линкам, все остальное время нить находится в неактивном сосюянии
Сервер оформляется как самостояIельный процесс, который обрабатывав! аналогичную таблицу операций стороне дисковой подсистемы Этот процесс циклически выполняет следующую последовательность действий
\) ожидание заголовка сообщения от клиента,
2) обработка заголовка (создание нового элемента таблицы операций),
3) просмотр таблицы операций и выполнение необходимых действий (чтение страницы с диска, сброс диска и т п ),
4) инициация операции чтения заголовка на освободившихся линках
Клиент и сервер для обмена данными используют следующий специальный протокол обмена сообщениями
' Сервер находится в постоянном ожидании гтоступления заголовка сообщения от клиента (все сообщения имеют заголовки одинаковой структуры) При получении заголовка сервер действует в зависимости от типа операции, указанной в заголовке сообщения
В случае операции "запись страницы" немедленно запускается чтение информационной части сообщения от клиента и в таблицу операций сервера помещается запись о том, что операция выполняется.
Если указана операция "чтение страницы", то в таблицу операций сервера просто помещается запись о том, что соответствующая операция выполняется.
Если необходимо выполнить операцию восстановления (сброса) диска, то запись в таблицу операций сервера помещается только в том случае, если на данный момент в ней отсутствуют записи об операциях чтения страницы (записи страницы) от данного клиента.
После этого сервер обрабатывает текущий элемент очереди из таблицы операций, в зависимости от типа операции, а затем удаляет эту запись из очереди.
Операции "сброс диска" и "восстановление диска" выполняются немедленно, после чего клиенту высылается заголовок с кодом "операция завершена" .
В случае операции "запись страницы", заголовок с кодом 1 "операция завершена" посылается клиенту юлько после завершения выполнения соответствующей операции
В случае операции "чтение страницы" сервер прочитывает страницу с диска, затем посылает заголовок с кодом "приготовиться к чтению информационной части", после чего происходит посылка самой информационной части.
Клиент находится в постоянном ожидании поступления ответа от сервера. При получении ответа клиент действует в зависимости от типа инициированной операции.
В случае операции "запись страницы" линк блокируется по записи; немедленно запускается передача информационной части на сервер; соответствующая запись добавляется в таблицу операций.
В случае операции "чтение страницы" линк блокируется по чтению; запускается чтение информационной части с сервера; соответствующая запись добавляется в таблицу операций.
Для операций "сброс диска" и "восстановление диска" добавление со-отвехствующих записей в таблицу операций происходит только в том случае, если на данный момент в ней отсутствуют записи об операциях чтения и записи схраницы от данного клиента (в противном случае происходит аварийный выход из функций с^ с!итр или с^.геэе!;)
5. Менеджер страниц
Менеджер страниц обеспечивает представление хранимой базы данных в виде совокупности наборов страниц Набор страниц представляет собой связный список страниц Страница состоит из заголовка и одного информационного поля info
Менеджер страниц должен удовлетворять следующим основным требованиям.
— Должна поддерживаться таблица размещения наборов страниц - SAT (page Set Allocation Table) SAT размещается в непрерывной области, начиная с нулевой страницы диска.
— Должен поддерживаться особый набор страниц - ССП (список свободного пространства).
— Должна поддерживаться возможность добавления в набор непрерывного блока страниц (например, по 64 страницы).
— Должна поддерживаться буферизация страниц на основе единого буферного пространства Должна поддерживаться таблица подкачки (индекс буферного пула), содержащая номера всех страниц, находящихся в данный момент в буфере Алгоритмы вытеснения и подкачки страниц должны эффективно работать для полностью заполненного буфера (это штатная ситуация в случае систем баз данных - страница вытесняв 1ся из буфера только тогда, когда это действительно необходимо для загрузки некоторой другой страницы).
— Доступ к содержимому страницы может быть осуществлен только через ее образ в оперативной памяти.
— Должен поддерживаться УИС (уникальный идентификатор страницы). Он должен быть уникальным в пределах диска УИС должен обеспечивать прямой доступ к странице. В простейшем случае в качестве УИС может использоваться номер страницы на диске
— Должна поддерживаться выборка страниц с упреждением.
5 1 Принципы проектирования менеджера страниц
Дооуп к содержимому страницы обеспечивается специальным оператором выборки страницы pg_fetch, который выдает указатель на образ страницы в буфере
Если в процессе работы с содержимым страницы прямо или косвенно вызывалась операция диспетчеризации th_schedule менеджера нитей [15], го перед продолжением работы с образом страницы рекомендуется вторично выполнить операцию pg_fetch. Это связано с тем, что во время передачи управления другой нити могло произойти открепление и вытеснение из буфера образа данной страницы в результате выполнения "параллельного" pgjfetch.
Оператор pg,fetch является синхронным в том смысле, что он возвращает управление только после того, как страница загружена в буфер (с возможным предшествующим вытеснением какой-либо другой страницы). Если после загрузки страницы в буфер заранее известно, какую страницу придется читать следующей (а в случае баз данных это, как правило. известно), можно воспользоваться оператором выборки с упреждением pg^prefetch Данный оператор осуществляет загрузку страницы в буфер в асинхронном режиме Перед доступом к странице, после оператора pg prefetch, должен быть выполнен оператор pg_fetch для того, чтобы гарантировать завершение загрузки страницы в буфер
Открытие набора страниц осуществляется с помощью операции pg_open Для каждого открытого набора вводится атрибут текущая страница. При открытии набора данный атрибут устанавливается в значение NIL, что соответствует пустой ссылке.
Оператор выборки страницы pg fetch устанавливает указатель текущей страницы на указанную страницу. Данная страница набора закрепляется в буфере, то есть она не может быть вытеснена из буфера ни при каких условиях При выполнении следующего оператора pg_fetch над данным набором указатель текущей страницы переустанавливается на новую страницу При этом предыдущая текущая страница набора открепляет сп от буфера, то есть она при необходимости может быть вытеснена из буфера
С каждой страницей, находящейся в буфере, связывается некоторое значение, называемое рейтингом страницы. Различаются статический и динамический рейтинги. Статический рейтинг задается пользователем при загрузке страницы в буфер. Динамический рейтинг является функцией от статического рейтинга и вычисляется менеджером страниц. Если возникает необходимость освободить в буфере место для новой страницы, то из буфера вытесняется страница с наименьшим динамическим рейтингом Значение динамического рейтинга страницы может изменяться со временем.
Г Создать пустой набор страниц*/
intr>=0 OK иначе ошибка 7 pg_createSet(mt Л идентификатор набора 7) Г Удалить набор страниц*/
int/*>=0 OK иначе ошибка 7 pg_dropSet(int /* идентификатор набора Г Открыть набор страниц*/
т1Л>=0 ОК иначе ошибкй 7 pg_open(int Л идентификатор набора 7) Г Закрыть набор страниц 7
int/*>-0 OK иначе ошибка 7 pg_close(int Г идентификатор набора 7) Г Добавить п страниц в конец набора */
mt/*>=0 идентификатор первой добавленной страницы иначе ошибка*/ pg_append(int Л идентификатор набора 7 int Л количество страниц 7) Г Удалить страницу из набора 7 irit/*>—О OR иначе ошибка*/
pg_delete(int/* идентификатор набора 7 int Г идентификатор страницы *I) F Выборка страницы 7
void * Г указатель на образ страницы в буфере 7
pg_fetch(int Л идентификатор набора */ int Л идентификатор страницы или NIL*/ int /* статический рейтинг *!) Г Выборка страниць с упреждением */ int Л >=0 ОК иначе ошибка 7
pg_prefetch( nt Г идентификатор набора 7 int /* идентификатор страницы 7 int Г статическии реитинг *t) Г Установка атрибута образа страницы modified 7 int Л >=0 OK иначе ошибка*/
pg setModified(intГ идентификатор страниць 7 char/* новое значение атрибута
Рис 7 Основные функции интерфейса менеджера с 1раниц
5 2 Интерфейс менеджера страниц
Основу интерфейса менеджера страниц составляют функции, изображенные на рис 7
Функция pg_fetch обеспечивает прямой доступ к содержимому указанной с i раницы Данная функция проверяет наличие указанной страницы в системном буфере и выдает указатель на образ страницы в буфере Если указанная страница в буфере отсутствует, то производится ее подкачка Если при лом в буфере нет места, то происходит вытеснение из буфера на диск образа неиспользуемой страницы, имеющей наименьший динамический рейтинг Если буфер полностью заполнен и все образы страниц явля ются в данный момент используемыми, то операция переходит в состояние ожидания
После выполнения операции pgJetch указанная страница становится текущей страницей указанного набора и помечается как используемая Предыдущая текущая страница при этом помечается как неиспочьзуемая ( открепляется)
Выполнение операции pgJetch со значением параметра "идентификатор страницы", равным NIL, приводит к откреплению предыдущей текущей страницы В качестве результата в этом случае выдается NULL
Рис 8 Иерархия модулей и объектов менеджера страниц
Функция pg prefetch обеспечивает опережающую загрузку страницы в буфер в асинхронном режиме Если в буфере отсутствует свободное место, происходит вытеснение на диск некоторой неиспользуемой страницы с наименьшим динамическим рейтингом
5 3 Принципы реализации менеджера страниц
Иерархия модулей и объектов, представляющих реализацию менеджера страниц, изображена на рис 8
Реализация основных операций менеджера страниц строится на базе следующих объектов
— Buf (Buffer) - буфер для буферизации страниц,
— Dir (Buffer Directory) - избыточный индекс буферизованных страниц (индекс для Buf),
— List (Space List) список свободного пространства (ССП),
— DD (Disk Directory) - заголовок диска,
— SAT (Set Allocation Table) таблица размещения наборов,
— Set (Open Page Set Descriptor Table) - таблица дескрипторов открытых наборов
5.3.1. Объект Buf (менеджер буферного пула)
Менеджер буферного пула обеспечивает резервирование и освобождение непрерывных участков памяти в буферном пуле на основе списка свободного пространства (CCII). Минимальной единицей выделения памяти является блок размером 4Кбайта.
Интерфейс менеджера буферного пула включает в себя две основные операции:bf_alloc - выделить блок из ССП, bf_free - вернуть блок в ССГ1.
Конкретным представлением буферного пула является байтовый массив, место поД который выделяется при инициализации подсистемы путем однократного динамического выделения памяти. Размер данного массива является параметром системы и хранится в файле настроек. Никаких дополнительных динамических выделений памяти под буферное пространство в дальнейшем не происходит.
Менеджер буферного пула поддерживает внутренний список свободных блоков буферного пула, хранящийся в памяти. Данный список представляет собой байтовый массив: char _xbf[N], где N - общее количество блоков в буферном пуле. Элемент _xbf[i] принимает значение 1 тогда и только тогда, когда блок с номером i является свободным. Поиск свободного блока линейный. Для ускорения поиска используется следующая простая оптимизация. Поддерживается указатель top на вершину списка («первый с конца занятый элемент»+1). Выделение свободного блока всегда осуществляется по указателю top. Если свободного места в хвосте буферного пула нет, то производится сквозной поиск в массиве _xbf[ ] первого элемента, равного 1 Указатель top пересчитывается при каждом выполнении операции освобождения блока.
5.3/2 Объекта Dir
Обьект Dir реализует избыточный индекс буферного пула Избыточность понимается в том смысле, что индекс Dir содержит количество позиций, превышающее количество страниц, которое может быть размещено в буферном пуле Данная избыточность по существу используется в реализации метода pg.prefetch (см. ниже). Кроме того, избыточность индекса Dir может быть использована при определении стратегии вытеснения путем анализа "истории" загрузки страниц в буфер (в частности, при достаточных размерах Dir могут быть обнаружены и оптимизированы циклы подкачки)
Индекс Dir используется также для организации асинхронных операций загрузки, сохранения и замещения образа страницы в буферном пуле. Это достигается тем, что с каждым элементом Dir может быть связан код
Г Вычисление индекса элемента 7
1П1Л>=С • индекс элемента иначе ошибка 7drJDir(int Г идентификатор набора 7 ¡ШЛидвнтиАикатоо страницы 7), т н
Г Вставить новый элемент 7
int Л индекс нового элементаЧйМпвОЦт! г идентификатор набора 7, int Г идентификатор страницы 7) Найти "жертву" 7 int Г >=0 - индекс жертвы, иначе - ошибка 7 dr_findVictim(void),
Рис. 9. Основные методы объекта Dir
одной из перечисленных операций. Вводится специальная системная нить _dr_sys с приоритетом (TELMINNICE +1). Данная системная нить периодически просматривает свою внутреннюю таблицу _dr_sysT. Таблица _dr „sysT содержит отображение операций из Dir в соответствующие асинхронные операции менеджера диска. Техника реализации системной нити _drj3ys близка к технике реализации системной нити кондуктора [16].
Метод dr JnsDir добавляет в Dir новый элемент с указанными значениями атрибутов Если в Dir нет свободных позиций, то производится поиск неиспользуемого элемента с минимальным динамическим рейтингом. Новый элемент вставляется на место найденной "жертвы"
Метод drJind Victim производит поиск в Dir элемента с наименьшим динамическим рейтингом среди элементов, содержащих непустую ссылку в поле pBuf, имеющих статус DRJNfOTUSING или DRJPREFETCHING и такт операции, равный NIL. Если такие элементы в Dir отсутствуют, то выдается код ошибки PGJENOMEM (см. рис. 9).
Конкретное представление объекта Dir включает в себя две таблицы: собственно таблицу Dir и хеш-таблицу _dr_HT.
Таблица Dir реализуется в виде статического массива, элементы которого имеют тип dr_elem_t. Размер массива Dir должен быть равен кМ, к»1 (по умолчанию к=8). Здесь М - длина буферного пула в страницах. Таким образом, Dir содержит избыточное количество элементов, в том смысле, что не все элементы связаны с образами страниц в буфере, - часть элементов не используется.
Прямой доступ к элементам Dir обеспечивается использованием хеш-таблицы Для разрешения коллизий используется метод цепочек. Память для элементов цепочки выделяется динамически. При удалении соответствующего элемента из Dir элемент цепочки не удаляется, вместо этого в поле iDir помещается значение NIL, означающее, что данный элемент цепочки свободен. При этом освободившийся элемент перемещается в направлении конца цепочки так, чтобы он стал первым свободным элементом в цепочке (см. рис. 10).
typedef struct{
int pageSet, Г идентификатор набора*/ ,
int page, Л идентификатор страницы*/
' int reit, Л рейтинг элемента 7
char updated/ признак модификации образа*/
int status, Л статус (состояние) элемента
DR_NOTUSING - не используется, образ страницы может отсутствовать буфере
©REUSING - используется, образ страницы обязательно присутствует в 6 уф ере
DR PREFETCHING - выборка с упреждением
DR_FETCHING выборка 7
pg_page_t* pBuf; Г указатель на образ страницы в буфере 7
int opcode, Г КОП (код операции)
OP LOAD-загрузить
Такт 1 считывает страницу page в буфер pBuf.
OP_SAVE - сохранить
Такт 1 записывает содержимое буф ера рВ1^ на страницу раде.
OPREPLACE • заместить
Такт 1 записывает содержимое буфера pBuf на страницу arg,
Такг2: считывает страницу радев буфер рВиГ*/
int arg. Л аргумент операции 7
int time. /*такт операции
==0 - операция не выполнялась,
>0 - выполняется указанный такт,
== NIL (-1) выполнение операции завершено */
} dr_elem_t,
Рис. 10. Структура элемента таблицы Dir
I* Выделить непрерывный блок7
int)1* ¡>=0- номер первой страницы блока иначе - нет места на диске*'/ ls_alloc(ifttn/*flnHHa блока в страницах'/),
/* Вернуть страницу в ССП7
void ls_free(int Г ноиер страницы 7),
/* Вернуть все страницы диска в ССП 7 void ls_clear(void)
Рис. 11. Ос новные методы объекта List
5.3.3. Объект List (менеджер ССП)
Менеджер списка свободного пространства (ССП) обеспечивает выделение непрерывных блоков страниц и утилизацию освобожденных страниц на виртуальном диске. Менеджер ССП реализуется в виде объекта List.
Конкретным представлением объекта List является внутренний индекс CCII, хранящийся в заголовке диска. Индекс ССП представляет собой байтовый массив char _xsl[N], где N - общее количество страниц на диске. Значение элемента _xsl[i] равно 1 тогда и только тогда, когда страница с номером i принадлежит ССП (см. рис. 11).
Поиск непрерывного блока страниц в CCII - линейный. Для ускорения поиска используется следующая простая оптимизация. Поддерживается указатель top («первый, занятый с конца»+1). Выделение блока страниц
всегда осуществляется по указателю top Если свободного места в хвосте ССП нет, то в С СП производится сквозной поиск блока нужной длины При возвращении страницы в ССП всегда пересчитывается указатель top
5 3 4 Объект DD
Объект DD предоставляет методы для работы с заголовком диска Заголовок диска занимает нулевую страницу диска В заголовке диска хра нит с я список свободного пространства, таблица размещения наборов и другая служебная информация
Заголовок диска загружается в оперативную память с помощью метода dd JoadDirectory Сохранение изменений образа заголовка диска осуществляется с помощью метода dd_saveDirectory
5 3 5 Объект SAT
Объект SAT реализует таблицу размещения наборов Данная таблица хранится в заголовке диска и считываете« в оперативную память каждый раз при инициализации менеджера страниц Элементы таблицы SAT содержат следующую информацию идентификатор набора, идентификатор первой страницы набора, идентификатор последней страницы набора и дру-i ую служебную информацию
Конкретным представлением обьекта SAT является статический массив
5 3 6 Объект Set
0бъек1 Set реализует т аблицу дескрипторов открытых наборов Таблица Set представляется в виде статического массива записей, организо ванною в виде хеш-таблицы Для разрешения коллизий используется метод открытой адресации
5 3 7 Алгоритмы простой выборки и выборки с упреждением
Реализация алгоритма выборки с упреждением (операция pg_prefetch)(pnc 12) обеспечивает асинхронный характер выполнения операции выборки с упреждением Схема реализации алгоритма простой выборки (операция pg fetch) изображена на рис 13
Операция выборки страницы выполняется в синхронном режиме Если указанная страница уже находится в буфере, например, в результате выполнения операции выборки с упреждением, то операция выборки страницы немедленно завершается Если образ указанной страницы в буфере отсутствует, го операция выборки завершится только после считывания данной страницы с диска
intpg_prefetch(int pageSet int page intreit)( int tDir victim
pg_page_t *pBuf /"указатель на образ страницы в буфере */
if (page <0) return PG_EWRONGPWAM if((iDir=dr_iDir(pageSet page)) = NIL)
/■дескриптор страницы отсутствует в Dir V iDir = d r_insDir(p ag eSet pag e) Dir(iDir) reit = reit
if (Dir|iDir] status 1= DR_ NOTUSING)
return iDir Dir[iDir] status - DR_PREFCTCHING
if (Dtr[iDir| pBuf 1= NULL) /* образ страницы присутствует в буфере 7 return iDir
Г Образ страницы отсутствует в буф ере 7 DirjiDir] updated - FALSE pBuf = (pg_page_t) bf_alor()
if (pBuf i= NJLt)( Г удалось найти свободный блок в Buf 7 Dir[iDir] pBuf-pBuf
DirfiDirj opcode - OP_LOAD P КОП загрузить 7 Dir[iDirj time-О Г такт операции 7 _dr_insSysT(iDir DS_READ Dir[iDir] page Oir|iOir| pBuf)
P вставить запись в _dr_sysT 7 ) else ( P He удалось наити свободный блоке Buf 7
victim = dr_fmdVictim() 1
if (v dim <0) re'urn PG_ENOMEM I
Dir[iDirj pBuf-pBuf Dir|viUim] rBuf Dirjvictim] pBuf = MULL Dir(victimj s<atuo - DR_NOTUSING
if (Dir[vctim| updated == TRUE){ /* Жертва обновлялась нужно roхранить 7 Dir[iDir] opcode - OP_REPLACE Л КОП заменить 7 Dir[iDirj arg D rjvictm] page Л что заменить 7 DirjiDir] time = О /"такт оперзции7 dr insSysT(iDir DS_WRITE Dr|Dir)arg Dir(iDir] pBuf) P вставить запись в dr svsT* ) eise j /"Жертва не обновлялась можно не сохранять 7 DirjiDir] opcode - OP_LOAD Г КОП загрузить 7 Dir[iDir| time - О f такт операции*/ _dr insSysT (¡Dir DS_READ Dir[iDir] page Dir| Dir] pBuf)
)
)
return iD r )
Г'ш 12 Схема реализации лги орил ma выборки ( упреждением
6. Менеджер файлов
Менеджер файлов обеспечивает, представление БД в виде совокупнос-1 и файлов Файл - это последовательный набор записей одинаковой длины Запись coctohi из заюловка и одного информационною поля info Заголовок записи размещается в конце записи, то есть после поля mfo В этом случае указатель на запись можег быть преобразован в указатель на mfo, что позволяет скрыть от пользователя структуру заголовка
Реализация хранимых записей осуществляется с использованием техники, описанной в [17] Каждый файл размещается в отдельном наборе страниц Соответствие между файлами и наборами страниц хранится в
ivoid * pg_fetch(int pageSel intpage mt rait) { iru iDir Л номер дескриптора образа 8 Oir */
prevPage Л номер страницы предыдущего fetch для данного набора 7 iSalr Г номер дескриптора набора в Set 7 iSet= psJSet(pageSet) prevPage = Set[iSetJ curPage iDir~dr iDir(pageSet prevPage) if (prevPage i= NIL){
while (D r[iDir] time 1= MIL}
th schedule() '(prevPage -- page)
return PirfiDir] pBuf
else
Dir[iOir] status = DR_N0TU3NG
}
Set[iSet] curPage = page
if (page = NIL) return NULL
iDir = pg_prefetch(pageSet page reit)
if (Oir== NIL) return NULL
Dr[iDir] status = DR_FETCHING
while (DirJiDir) time ь NIL)
th schedule() Dir[iO r] status = DR_USING
return 6 r|iDir] pBuf }
Рис 13 Схема реализации алгоритма простои выборки
FAT (File Allocation Table) FAT размещается в непрерывной области диска, начиная с нулевой страницы
Поддерживается УЙД (уникальный идентификатор записи), который является уникальным в пределах диска Его значение остается неизменным па протяжении всего времени жизни записи УИД обеспечивает прямой доступ к записи (обращение к любой записи по ее УИД требует не более одной операции чтения/записи страницы) В качестве УИД используется пара («УИС», «номер байта от конца страницы, содержащий адрес первого байга записи на странице»)
7. Заключение
В данной работе изложены принципы разработки и программная ст рук Iура сис темы управления файлами (СУФ) ядра параллельной СУБД Омега для о к. чес г венного суперкомпьютера МВС-100 Сформулированы требова ния к СУФ и дано описание ее общей С1руктуры Приведены описания всех основных программных компонент СУФ
Предложен механизм вытеснения страниц, основанный на их динами ческих и статических рейтингах Данный механизм позволяет реализовы вать практически любые стратегии вытеснения страниц
Даны описания алгоритмов простой выборки страниц и выборки с упреждением Предложен эффективный Протокол для взаимодействия с дис
Л Создать пустой файл 7
int /*>=0 - OK, иначе - ошибка 7fl_createFile(int Л идентификатор файла 7, int/* длина info 7),
Л Удалить файл V
int Л >=0 - OK, иначе - ошибка 7 fl_dropFile(int Г идентификатор ф айла */), Г Открыть файл 7
int Г >=0 - OK, иначе - ошибка 7 fl_open(mt/* идентификатор файла*/,
char Л режим О (FL_READ) ■ только чтение, 1 (FL_WRITE) - запись и чтение 7);
Л Закрыть файл 7
int Л >=0 - OK, иначе - ошибка 7fl_close(int Л идентификатор файла*/), Л Добавить запись в конец ф айла 7
int Л >=0 - УИД первой добавленной записи, иначе - ошибка 7fl_append(int Г идентификатор файла*/), Л Пометить запись на удаление 7
int /* >=0 - OK, иначе - ошибка 7fl delete(int/* идентификатор файла 7, int Л УИДзаписи 7);
Л Удалить всезап^си с пометкой на удаление 7
int !" >=0 - OK иначе ошибка 7 flj»ack(irit/* идентификатор файла 7, int Л УИД записи 7),
Л Выборка записи 7
void*/* oNULL - указатель на info записи, иначе - ошибка 7 fl_fetch(mt/* идентификатор файла*/, int Г УИД записи 7),
Рис. 14. Основные функции менеджера файлов
ковой подсистемой. Описана архитектура эмулятора дисковой подсистемы.
Описанная СУФ реализована на МВС-100 в системе программирования Си. Предложенная архитектура системы управления файлами допускает перенос полученной реализации на платформу МВС-1000 при минимальных доработках исходных текстов. ■
Описанная реализация СУФ, прежде всего, ориентирована на использование в системах баз данных, однако она может быть использована и в других задачах, требующих интенсивных обменов с дисками.
Список литературы
1. Девитт Д., Грэй Д. Параллельные системы баз данных: будущее высокоэффективных систем баз данных // СУБД. 1995. №2. С. 8 31.
2. Ваги С. К. et al. DB2 Parallel Edition // IBM System Journ. 1995. Vol. 34, №2. P. 292 322.
3. Page J. A Study of a Parallel Database Machine and its Performance the NCR/Teradata DBC/1012 11 Advanced Database Systems: 10th British National Conference on Databases. BNCOD 10, Aberdeen, Scotland, July 6 - 8, 1992, Proceedings. Lecture Notes in Computer Science. Vol. 618. Spring«, 1992. P. 115 - 137.
4. Tandem Database Group NonStop SQL: A Distributed, High-Performance, High. Availability Implementation of SQL // High Performance Transaction Systems, 2nd Int.
Workshop. Pacific Grove, California, USA, September 28 - 30, 1987, Proceedings. Lecture Notes in Computer Science. Vol. 359. Springer, 1989. P. 60 - 104.
5. Valduries P. Parallel Database Systems: Open Problems and New Issues // Distributed and Parallel Databases. 1993. Apr. Vol. 1; №2. P. 137 165.
ПРИНЦИПЫ РЕАЛИЗАЦИИ СИСТЕМЫ УПРАВЛЕНИЯ ФАЙЛАМИ 199
6. Stonebiaker М. The case for shared nothing // Database Eng. 1986. Vol. 9, №1. P. 4 -
9
7. Valduries P. Parallel Database Systems: the case for shared-something // Proc. of 9th International Conference on Data Engineering, Vienna, Austria, Apr. 19 - 20, 1993, P. 460 465.
К Bhide A , Stonebiaker M. A Performance Comparison of Two Architectures for Fast TiaiiMti tion Ртосешпд // Proceedings of the 4th International Conference on Data Engineering, Los Angeles, CA, Febr. 1988. P. 536 - 545.
9, Bouganim L., Florescu D., Valduriez P. Dynamic Load Balancing m Hierarchical Parallel Database Systems // VLDB'96: Proceedings of 22th International Conference on Very Large Data Bases, Mumbai (Bombay), India, Sept. 1996. P. 436 - 447.
10. Xu Y., Dandamudi S.P. Performance Evaluation of a Two-Level Hierarchical Parallel Database System // Proceedings of the Int. Conf. Computers and Their Applications, Tempe, Arizona, Mar. 1997. P. 242 - 247
11 Sokolinsky L., Axenov O., Gutova S. Omega: The Highly Parallel Database System Pru-ie(t // Proceedings of the First East-European Symposium on Advances in Database and Information Systems (ADBIS'97), St.-Petersburg, Sept. 2 - 5, 1997. Vol. 2. P. 88 -90
12 Zabiodin A.V., Levin V.K., Korneev V.V. The Massively Parallel Computer System MBC-WO // Proceedings of PaCT-95. Lecture Notes in Computer Science. Vol. 964. 1995. P 342 356
13 Голыитейн M Л. Мультипроцессорная вычислительная система на базе транспьютерной идеологии // Алгоритмы и программные средства параллельных вычислений [Сб науч. тр ] Екатеринбург: УрО РАН, 1995. С. 61 - 68.
14. Flynn М J., Rudd K.W. Parallel architectures // ACM Computing Surveys. 1996. Mar. Vol 28, №1 P 67 - 70.
15. Соколинский Л Б Эффективная организация легковесных процессов в параллельно й СУБД Омега для МВС-100 /'/ Фундаментальные и прикладные аспекты разработки больших распределенных программных комплексов: Тез. докл. Всерос. науч. конф. (21 26 сентября 1998 г., г. Новороссийск). М.: Изд-во Моск. ун-та, 1998.
С. 132 138.
16. Sokolinsky L.B. Interprocessor Communication Support tn the Omega Parallel Database System // CSIT'99, Proceedings of the 1st International Workshop on Computer Science and Information Technologies, Jan. 18 - 22, 1999, Moscow, Russia. МЕРЫ Publishing. 1999. Vol. 2. (http://msu.jurinfor.ru/CSIT99/CSIT99.html).
17. Date C.J. An Introduction to Database Systems (6th edition). Reading, Mass.: Addison-Wesley, 1995. 839 p.
Summary
The paper describes a structure and implementation principles of a File Management System (FMS) for the parallel Omega DBMS. This DBMS is designed for the MVS-100 massively parallel computer system. The paper specifies requirements for the FMS and describes its structure and components. The paper proposes a page replacement strategy based on the static and dynamic page rating. The paper gives a specification of fetch and prefetch algorithms. The paper suggests some effective protocol for interaction with the Disk Subsystem The paper describes Disk Subsystem Emulator's architecture. FMS described in this paper is implemented under the MVS-100 and can be ported to the MVS-1000 after minimal rework.
