Итоговый научный отчет по гранту РФФИ No. 97-07-90148 (1997-1999 г.)
Название проекта: Разработка высоко-параллельной масштабируемой системы управления базами данных для мультипроцессорной вычислительной системы без совместного использования ресурсов
Руководитель: Соколинский Леонид Борисович
Оглавление
Аппаратная архитектура системы Омега.
Программная структура системы Омега.
Операционное окружение СУБД Омега.
Подсистема передачи сообщений.
Система управления файлами (СУФ).
Стоимостная модель для оптимизации запросов.
Технология коллективной разработки системы Омега.
Web-репозиторий проекта Омега.
Для параллельной СУБД Омега была предложена оригинальная иерархическая аппаратная архитектура [13].
Первый уровень иерархии образуют процессорные модули типа TRAM. Каждый TRAM модуль состоит из вычислительного и коммуникационного процессоров, разделяющих общую память. Коммуникационный процессор имеет четыре внешних серийных линка, играющих роль внешних каналов ввода-вывода и соединяющих процессорный модуль с другими процессорными модулями и дисковыми подсистемами. Дисковая подсистема представляет собой специальную интерфейсную плату со стандартным коммуникационным процессором, к которой по SCSI интерфейсу может быть подключено до 7 накопителей на жестких магнитных дисках. Коммуникационный процессор дисковой подсистемы имеет четыре серийных линка для соединения с процессорными модулями.
Второй уровень иерархии образуют так называемые омега-кластеры. Омега-кластер представляет собой систему из четырех процессорных модулей и одной дисковой подсистемы, соединенных между собой. Топология соединений внутри омега-кластера является стандартной и обладает следующими свойствами: длина пути от дисковой подсистемы до любого процессорного модуля равна 1; длина пути между любыми двумя процессорными модулями не должна превышать 2 (имеется в виду, конечно, длина наикратчайшего пути); каждый процессорный модуль имеет один свободный линк для связи с другими омега-кластерами. На аппаратном уровне омега-кластер имеет архитектуру с разделяемыми дисками. За каждым процессорным модулем кластера логически закрепляется отдельный физический диск дисковой подсистемы. Таким образом, на логическом уровне кластер образует систему, состоящую из узлов без совместного использования ресурсов.
Третий уровень иерархии образует уже система в целом, которая строится как совокупность омега-кластеров, соединенных между собой в стиле "без совместного использования ресурсов". Топология межкластерных соединений не фиксируется и может варьироваться от простой линейки до гиперкуба. Одна вычислительная система может содержать сто и более омега-кластеров, объединяя таким образом до тысячи процессоров с совокупной оперативной памятью в десятки гигабайт.
Программная структура СУБД Омега имеет два уровня [18]. Первый уровень составляет так называемый слой операционного окружения ядра СУБД. Во второй уровень входят собственно ядро СУБД и утилиты.
Подобная двухуровневая организация системы обеспечивает возможность переноса СУБД Омега с платформы МВС-100 на МВС-1000 и другие сходные аппаратные платформы. Операционное окружение СУБД Омега позволяет полностью абстрагироваться от специфики архитектуры аппаратной платформы. При переносе СУБД Омега на другую аппаратную платформу все изменения локализуются в пределах слоя операционного окружения. Перенос ядра и утилит СУБД заключается в простой перекомпиляции исходных текстов в контексте новой аппаратной платформы.
Первоначально в качестве операционной среды СУБД Омега предполагалось использовать UNIX-подобную распределенную ОС HELIOS. Однако проведенные исследования показали, что большинство сервисов, предоставляемых ОС HELIOS, оказываются недостаточно эффективными с точки зрения СУБД. В соответствие с этим в рамках проекта Омега была спроектирована и реализована специальная операционная среда, представляющая собой, фактически, небольшую распределенную операционную систему [1, 18]. Данная операционная среда включает в себя следующие основные подсистемы: менеджер легковесных процессов (нитей управления) [10], подсистему передачи сообщений [8] и систему управления файлами [16, 19].
Одной их серьезных проблем, возникающих при программировании с явным использованием техники легковесных процессов, является проблема синхронизации по отношению к общим ресурсам.
В рамках проекта Омега была предложена новая модель организации параллельных процессов на базе парадигмы "производитель-потребитель". В данной модели процессы ассоциируются с потоками данных и являются средством структуризации программы. Данная модель позволяет обеспечить автоматическую синхронизацию и эффективную диспетчеризацию параллельных процессов. В модели предлагается концепция кванта времени, не зависящая от наличия аппаратного прерывания по таймеру. Данная модель детально описывается в работах [1, 10].
На базе указанной модели для МВС-100 был разработан и реализован менеджер нитей (легковесных процессов). Менеджер нитей обеспечивает возможность организации параллельных нитей управления в соответствии с дисциплиной, определенной в модели производитель-потребитель. Менеджер нитей поддерживает два класса нитей: системные нити и пользовательские нити.
Менеджер нитей поддерживает для нитей систему статических приоритетов, назначаемых пользователем при создании нитей. Реальное управление нитями выполняется на основе динамических приоритетов. Алгоритм вычисления динамических приоритетов описан в работах [1, 10].
Одним из критических параметров, влияющих на производительность СУБД для массивно-параллельных платформ, являются затраты на межпроцессный (межпроцессорный) обмен сообщениями. Однако для многих ОС общего назначения стоимость операции обмена может составлять несколько тысяч инструкций на одно сообщение. В ОС Helios для МВС-100 латентная часть передачи одного сообщения между процессорными узлами составляет около 3000 байт. Вследствие этого система передачи сообщений ОС Helios не может использоваться в параллельной СУБД для МВС-100, так как она не удовлетворяет требованию эффективности. В ОС Router латентная часть передачи сообщения была сокращена до 400 байт. Однако использование функций передачи сообщений ОС Router требует явной синхронизации нитей управления по отношению к линкам. При наличии большого количества обменов по линкам, а для параллельной СУБД это типичная ситуация, это ведет к сложному, запутанному и опасному программированию. Отладка программы, в этом случае, становится очень сложным делом.
Отсюда возникает необходимость разработки системы обмена сообщениями СУБД Омега, которая, с одной стороны, подобно ОС Helios для любых двух узлов многопроцессорной системы предоставляла любое количество виртуальных каналов для межпроцессорного обмена сообщениями (каждому обмену - свой канал) и, с другой стороны, была бы по эффективности сравнима с ОС Router.
Система передачи сообщений должна оптимальным образом учитывать иерархическую аппаратную архитектуру системы Омега. В соответствие с этим система сообщений была разделена на две независимые подсистемы - кондуктор и маршрутизатор.
Маршрутизатор обеспечивает межпроцессорный обмен между узлами, принадлежащими различным Омега-кластерам. Реализация маршрутизатора базируется на специально разработанном протоколе обмена сообщениями. Данный протокол характеризуется тем, что инициализация передачи сообщения от одного узла другому требует только двух элементарных обменов (элементарный обмен примерно эквивалентен передаче одного байта информации). Это является важным показателем с точки зрения эффективности, так как при межкластерном обмене сообщениями длина пути между узлами может оказаться относительно большой и, соответственно, затраты на один элементарный обмен - достаточно высокими. Указанный протокол детально описан в работе [8].
Маршрутизатор поддерживает любое количество асинхронных виртуальных каналов между любыми двумя узлами. Для идентификации каналов используется понятие порта (канал, соединяющий два узла, имеет одинаковые номера портов с обеих сторон). В реализации передачи сообщений посредством каналов используется копирование данных типа "память-в-память" и динамическое выделение памяти. Однако это не сказывается на производительности маршрутизатора критическим образом, так как межкластерные обмены в системе Омега относительно редки.
На языке Си была написана реализация маршрутизатора для системы Омега. Маршрутизатор показал хорошую производительность на тестовых примерах. Время , затрачиваемое Омега-маршрутизатором на передачу сообщения, в среднем, на порядок меньше времени, затрачиваемого ОС Helios. Интерфейс и структура реализации маршрутизатора детально описаны в работе [8].
Кондуктор обеспечивает средства для организации обменов в пределах одного Омега-кластера. Внешняя организация кондуктора близка к организации маршрутизатора, однако кондуктор использует принципиально иной внутренний протокол. В соответствии с этим протоколом инициализация передачи сообщения от одного узла другому требует трех элементарных обменов, и при передаче сообщения не использует копирование данных типа "память-в-память". Данный протокол оказывается достаточно эффективным для внутрикластерных обменов сообщениями, так как в этом случае длина пути между узлами не больше двух, вследствие чего, стоимость одного элементарного обмена относительна низка. Другой особенностью реализации кондуктора является то, что при создании нового виртуального канала не требуется динамического выделения памяти.
На языке Си была выполнена реализация кондуктора для системы Омега. Кондуктор, в среднем, показывает более высокую производительность на внутрикластерных обменах, чем маршрутизатор, однако проигрывает последнему, когда длина пути между узлами оказывается большой. Детально интерфейс и структура реализации кондуктора описаны в работе [8].
Средства для работы с файлами, предоставляемые операционными системами общего назначения, как правило, оказываются неэффективными для использования в СУБД. Не является исключением и ОС Helios для МВС-100. В ОС Router средства для работы с файлами фактически отсутствуют. В [19] были сформулированы два основных требования к СУФ системы Омега:
- СУФ должна предусматривать возможность внутрифайловой кластеризации по значению некоторого поля;
- СУФ должна поддерживать буферизацию страниц на основе единого внутреннего буферного пула. При этом должны поддерживаться выборка страницы с упреждением и возможность задания последовательности вытеснения страниц из буферного пула.
Ни одна из имеющихся операционных систем для МВС-100 не предоставляет указанных возможностей. В соответствие с этим возникла необходимость разработки специальной системы управления файлами (СУФ) для системы Омега.
СУФ является частью ядра СУБД Омега и функционирует на каждом рабочем узле. Основным назначением СУФ является поддержка понятия файла, как набора записей фиксированной длины. Данные файлы используются на более высоких уровнях системной иерархии для представления отношений (таблиц), индексов и других объектов хранимой базы данных.
СУФ строится как иерархия следующих трех подсистем: менеджер дисков, менеджер страниц и менеджер файлов [16, 19].
Менеджер дисков обеспечивает представление виртуального диска в виде набора пронумерованных страниц по 4К. Основными операциями менеджера дисков являются следующие: считать страницу с диска в буфер; записать страницу из буфера на диск. Более детально менеджер дисков описан в [16, 19].
Менеджер страниц обеспечивает представление базы данных (точнее ее части), хранящейся на данном виртуальном диске, в виде совокупности наборов страниц, представляющих собой связные списки. Менеджер страниц позволяет создавать и удалять наборы страниц, добавлять страницы в набор, удалять страницы из набора, осуществлять последовательный просмотр набора страниц, а также прямую выборку и выборку с упреждением страницы с указанным идентификатором. Интерфейс и реализация менеджера страниц детально описаны в [16, 19].
Менеджер файлов обеспечивает представление базы данных в виде файлов, представляющих собой наборы неструктурированных записей одинаковой длины (запись имеет только одно информационное поле info). Интерфейс и реализация менеджера файлов детально описаны в [16, 19].
На языке Си была выполнена реализация СУФ для МВС-100. Тестовые испытания показали хорошую производительность СУФ по всем параметрам. Данная СУФ может использоваться и для других задач на МВС-100, требующих интенсивных файловых обменов.
Для менеджера страниц был разработан оригинальный механизм вытеснения страниц из буферного пула [16, 19]. Данный механизм базируется на введении для образов страниц статического и динамического рейтингов. Статический рейтинг - это целое число от 0 до 20. Статический рейтинг определяется пользователем при выполнении операции выборки страницы fetch или при выполнении операции выборки с упреждением prefetch. Статический рейтинг остается неизменным на протяжении всего времени нахождения образа страницы в буферном пуле. При вытеснении страницы из буфера значение статического рейтинга теряется. Динамический рейтинг - это некоторая функция от статического рейтинга, принимающая значения в интервале от 0 до 1 (1 в интервал не входит). Значение динамического рейтинга может меняться во время нахождения страницы в буфере. Способ вычисления динамического рейтинга задается системой. Суммарный рейтинг страницы получается как сумма статического и динамического рейтингов. Если необходимо освободить место в буферном пуле, то вытесняется страница, имеющая минимальный суммарный рейтинг. Если таких страниц несколько, то вытесняется страница, дольше всего находящаяся в буферном пуле. Данный механизм дает возможность пользователю для любых двух страниц явно задать последовательность их вытеснения из буферного пула. Эта возможность является принципиально важной для организации восстановления базы данных после сбоя. Использование динамического рейтинга позволяет реализовывать различные стратегии вытеснения страниц. В качестве эксперимента были реализованы стратегии FIFO и LRU.
Мультипроцессорная система МВС-100, на которой выполняется проект, не имеет дисковой подсистемы (по причине финансовых ограничений). В соответствие с этим в рамках проекта был разработан и реализован специальный эмулятор дисковой подсистемы [16, 19]. Эмулятор реализует виртуальные (электронные) диски, используя оперативную память процессорного модуля. Виртуальные диски разбиваются на страницы по 4 Кбайта. Каждой странице присваивается уникальный в пределах диска номер. При реализации эмулятора дисковой подсистемы была использована технология клиент-сервер. Клиентскую часть эмулятора представляет менеджер дисков, запускаемый на каждом рабочем узле. Серверная часть запускается на некотором выделенном узле, играющем роль дисковой подсистемы (обычно это нулевой узел кластера). Был разработан специальный протокол для обмена данными между клиентами и сервером.
После приобретения и установки реальной дисковой подсистемы необходимо будет переписать только серверную часть и реализацию клиента. Интерфейс клиента (менеджера дисков) при этом останется неизменным (в части функций чтения и записи страниц), что позволит ограничиться минимальными переделками в исходных текстах системы в целом.
Исполнитель запросов [20] СУБД Омега представляет собой виртуальную машину, способную выполнять физические запросы, то есть запросы, выраженные в терминах физической алгебры.
На уровне физической алгебры любая "параллельность" в выполнении запроса реализуется только явно. В частности, аргументами и результатами операций физической алгебры являются фрагменты отношений. Параллельные операции над отношениями, базирующиеся на их фрагментации, реализуются на более высоких уровнях системной иерархии.
Физический запрос представляется в виде дерева, в узлах которого помещаются физические операции. Для унификации представления узла дерева запроса используется концепция потока и скобочная модель.
Поток представляет собой реализацию отношения на уровне физической алгебры. Аргументами и результатами операций физической алгебры являются потоки.
В этом смысле поток является обобщением понятий хранимого файла, временного файла, склада, канала Омега-кондуктора и канала Омега-маршрутизатора. Потоки реализуют универсальный механизм обмена данными между процессом и диском, процессом и каналом кондуктора или маршрутизатора, а также между процессом и другим процессом.
Поток представляет собой виртуальный файл типа FIFO. Поток можно открывать, закрывать, устанавливать в начальное состояние. В поток можно помещать (записывать) записи и из потока можно извлекать (считывать) записи по правилу FIFO (первым записан, - первым считан).
Все промежуточные результаты в дереве запроса оформляются как потоки типа "склад" или "временный файл".
Синхронизация операций осуществляется автоматически на базе модели поставщик-потребитель [1, 10]. В контексте данной модели, потоки ассоциируются с корнем (выходной поток) и листьями (входные потоки) дерева запроса. Для каждого внутреннего узла дерева запроса определяются один или два входных потока и один выходной поток, абстрагирующие данный узел от других узлов.
Данная модель отличается от итераторной модели, используемой в большинстве параллельных СУБД. Фактически, итераторная модель представляет собой частный случай модели поставщик-потребитель при длине склада равной единице.
Проблему поиска оптимального плана выполнения запроса можно условно разбить на две взаимосвязанные подзадачи: определение оптимального порядка выполнения операций и распределение операций по процессорам. В работах [12, 14] была построена стоимостная модель, позволяющая определить оптимальный порядок выполнения операций. Эта модель не учитывала распределения операций по процессорам. К настоящему моменту модель уточнена таким образом, чтобы ее действие распространялось на задачу распределения процессоров. Для этого в функцию стоимости реляционной операции введена зависимость от количества процессоров, отводимых на выполнение операции; соответствующим образом изменена функция стоимости плана выполнения запроса.
Эффективная разработка больших программных систем не возможна без использования современных технологий программирования. В соответствие с этим была разработана и внедрена оригинальная технология разработки программ [2, 9] для МВС-100. Средства программной поддержки указанной технологии включают в себя следующие основные компоненты: систему контроля версий CVS, документатор DOC++ и компилятор C фирмы Portland Group (PGCC) для i860. Все три программных продукта являются разработками независимых фирм. Краткое описание данных систем приводится в [2].
Схематично технологический цикл можно описать следующим образом. Пусть программист 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 для коллективной разработки больших программных систем различного назначения.
В процессе работы над проектом был накоплен большой объем информации о параллельных СУБД. Данная информация была структурирована и представлена в виде Web-репозитория [3], доступного через Internet http://www.cgu.chel.su/~sok/grants/rfbr/1997/k_omega.html.
Составными частями данного репозитория являются аннотированный библиографический каталог [6] и словарь-справочник [4] по базам данных и системному программированию. Данные библиографический каталог и словарь-справочник использовались в проекте Омега в качестве информационной поддержки. Их экспериментальные версии доступны по адресам: http://reindeer.math.cgu.chel.su/oracle/bibl и http://reindeer.math.cgu.chel.su/oracle/dict.
1. Sokolinsky L. Operating System Support for a Parallel DBMS with an Hierarchical Shared-Nothing Architecture // Proc. of the Third East-European Conf. on Advances in Databases and Information Systems (ADBIS'99).Maribor, Slovenia, September 13-16. 1999. P. 38-45
2. Соколинский Л.Б. Структура средств компьютерной поддержки процесса прототипирования параллельной СУБД Омега для мультипроцессорной вычислительной системы МВС-100/1000 // Программные продукты и системы. 1999. No.2. C. 15-19.
3. Соколинский Л.Б. Web-репозиторий как средство организации научной информации в сети Интернет // Интернет и современное общество: Тез. 2-й Всеросс. науч.-метод. конф. (29 ноября - 3 декабря 1999 г., Санкт-Петербург). -СПб.: Изд-во С.-Петербур. ун-та. 1999. C. 52-54.
4. Соколинский Л.Б., Сбитнев К.В. Internet версия электронного толкового словаря по программированию и базам данных // Научный сервис в сети Internet: Тез. докл. Всероссийск. науч. конф. (20-25 сентября 1999 г., г. Новороссийск). -М.: Изд-во МГУ. 1999. С. 234-239.
5. Цымблер М.Л., Соколинский Л.Б., Федрушков В.В. Использование Internet-технологий в коллективной разработке больших программных систем // Научный сервис в сети Internet: Тез. докл. Всероссийск. науч. конф. (20-25 сентября 1999 г., г. Новороссийск). -М.: Изд-во МГУ. 1999. С. 207-210.
6. Соколинский Л.Б., Апанасенко Е.В. Технологические аспекты разработки Internet версии аннотированного библиографического каталога по программированию и базам данных // Телематика'99: Тез. докл. Всероссийск. науч.-метод. конф. (7-10 июня 1999 г., Санкт-Петербург). -СПб: Вузтелекомцентр. 1999. C. 138-139.
7. Соколинский Л.Б., Цымблер М.Л. Использование МВС-100 в качестве машины баз данных // Информационный бюллетень Ассоциации математического программирования. No. 8. Екатеринбург: УрО РАН. 1999. C. 251-252.
8. 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. Vol. 2. (http://msu.jurinfor.ru/CSIT99/CSIT99.html)
9. 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. Vol. 2. (http://msu.jurinfor.ru/CSIT99/CSIT99.html)
10. Соколинский Л.Б. Эффективная организация легковесных процессов в параллельной СУБД Омега для МВС-100 // Фундаментальные и прикладные аспекты разработки больших распределенных программных комплексов: Тез. докл. Всероссийск. науч. конф. (21-26 сентября 1998 г., г. Новороссийск). -М.: Изд-во МГУ. 1998. C. 132-138.
11. Соколинский Л.Б., Цымблер М.Л. Проект создания параллельной СУБД Омега на базе суперкомпьютера МВС-100/1000 // Телематика'98: Тез. докл. Всероссийск. науч.-метод. конф. (7-10 июня 1998 г., Санкт-Петербург). -СПб: Вузтелекомцентр.1998. C. 154-155.
12. Лымарь Т.Ю. Уточнение стоимостной модели оптимизации запросов с учетом распределения процессоров // Алгоритмический анализ некорректных задач: Тез. докл. Всерос. науч. конф. (Екатеринбург, 2-6 февраля 1998 г.). -Екатеринбург: УрГУ. 1998. C. 149-150.
13. 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.
14. Соколинский Л.Б., Лымарь Т.Ю. О выборе оптимального плана выполнения запроса в параллельной системе баз данных // Проблемы оптимизации и экономические приложения: Тезисы докладов международной конференции. Омск: Омск. гос. ун-т. 1997. C. 146.
15. Соколинский Л.Б. Разработка параллельной системы управления базами данных для мультипроцессорной вычислительной системы МВС-100 // Информационный бюллетень Ассоциации математического программирования. No.7. Екатеринбург: УрО РАН. 1997. C. 210-211.
16. Соколинский Л.Б., Цымблер М.Л. Принципы реализации системы управления файлами в параллельной СУБД Омега для МВС-100 // Вестник Челябинского университета. Серия математика, механика. 1999. No.2(5). C. 78-96.
17. Соколинский Л.Б. Принципы разработки СУБД Омега. Отчет OMEGA01. ЧелГУ, 1997.
18. Соколинский Л.Б. Структура системного окружения СУБД Омега. Отчет OMEGA02. ЧелГУ, 1997.
19. Соколинский Л.Б. Система управления файлами. Отчет OMEGA03. ЧелГУ, 1998.
20. Соколинский Л.Б. Исполнитель физических запросов СУБД Омега. Отчет OMEGA04. ЧелГУ, 1999.