Применение SPMD-технологии при построении сетевых баз данных с циркулирующей информацией

Принцип работы БД с циркулирующей информацией

Рекомендации по организации вычислений неотделимы от модификации самих методов вычислений, традиционно продолжающих линию минимизации количества операций (привлекательной на уровне счетчиков—вычислителей, работающих с арифмометром или, в лучшем случае, с однопроцессорной ЭВМ 60-х годов). Распараллеливание выдвигает другой критерий эффективности: минимизация длины критического пути в информационно-логическом графе решаемой задачи или максимизация коэффициента загрузки исполнительных устройств системы.

Желание уйти от рекомендаций общего характера приводит к рассмотрению классов задач или отдельных "представительных" задач и к демонстрации их возможностей параллельного решения по SPMD-технологии, привлекающей все большее внимание как разработчиков ВС, так и математиков-программистов. По этой технологии вычислительный процесс организуется так, что единственная программа одновременно запускается на всех исполнительных устройствах — на процессорах ВС, на ЭВМ вычислительного комплекса, на рабочих станциях (РС) ЛВС. В этой программе — монопрограмме — "упрятаны" не только сама конфигурация алгоритма обработки, но и механизмы распределения данных, обрабатываемых по одному и тому же алгоритму, синхронизация исполнителей при обработке общих данных, возможность обработки данных по разным ветвям алгоритма (не путать с векторным способом обработки массивов!), универсальность монопрограммы, инвариантной относительно количества участвующих исполнителей и объемов обрабатываемой информации. При этом важно, что при организации совместных действий исполнительных устройств отсутствуют обращения к операционной системе.

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

Предлагается способ преобразования централизованной сетевой базы данных из традиционно одноканальной в многоканальную систему массового обслуживания на основе применения SPMD-технологии. Способ заключается в организации встречного движения информации к пользователям, рабочие станции которых располагают копией системы управления базой данных. Целью рассматриваемых построений является минимизация времени обслуживания.

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

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

Здесь мы реально наталкиваемся на "однобокость" развития методов обработки больших массивов информации. Совершенствуя алгоритмы обработки, мы предполагаем "статичность", "пассивность" системы памяти. Память (совокупная память всей системы) должна стать активной, способствовать процессу хотя бы на основе вероятностных предположений, должна реализовать встречные предложения, способные обеспечить снижение среднего времени выполнения запросов пользователей.

Такой способ активизации памяти, основанный не на покое БД, а на ее движении хотя бы внутри ЛВС, рассмотрим далее.

Мы отдаем предпочтение ЛВС и не исключаем другие применения, так как линии передачи данных, используемые в этих сетях, обладают наибольшим темпом развития, совершенствования, ростом пропускной способности. Именно их современные возможности в первую очередь вселяют надежду на реальность идеи активизации памяти, основанной на оперативном обмене данными.

Традиционно, базы данных, реализованные в ЛВС, делятся на централизованные и распределенные.

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

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

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

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

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

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

Основная идея, предлагаемая в настоящей работе, заключается в активизации совокупной памяти ЛВС, в которой располагается БД. Разбитая на сегменты БД предлагает встречный обмен, встречное предложение своих сегментов рабочим станциям, реализуя различные дисциплины таких предложений. Таким образом, сегменты БД циркулируют среди рабочих станций ЛВС. Такие сетевые БД, в которых производится ротация сегментов, находящихся в памяти каждой РС, назовем ротационными.

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