Объектно-ориентированная СУБД (прототип)

CORBA (Common Object Request Broker Architecture) определяет среду для

различных реализаций ORB (Object Request Broker), поддерживающих общие

сервисы и интерфейсы. Это обеспечивает переносимость клиентов и реализаций

объектов между различными ORB.

Брокер Объектных Заявок обеспечивает механизмы, позволяющие объектам

посылать или принимать заявки, отвечать на них и получать результаты, не

заботясь о положении в распределенной среде и способе реализации

взаимодействующих с ними объектов.

Объектные Службы:

. Служба Уведомления Объектов о Событии (Event Notification Service).

. Служба Жизненного Цикла Объектов (Object Lifecycle Service).

. Служба Именования Объектов (Name Service).

. Служба Долговременного Хранения Объектов (Persistent Object Service).

. Служба Управления Конкурентым Доступом (Concurrency Control Service).

. Служба Внешнего Представления Объектов (Externalization Service).

. Служба Объектных Связей (Relationships Service).

. Служба Транзакций (Transaction Service).

. Служба Изменения Объектов (Change Management Service).

. Служба Лицензирования (Licensing Service)/

. Служба Объектных Свойств (Properties Service).

. Служба Объектных Запросов (Object Query Service).

. Служба Безопасности Объектов (Object Security Service).

. Служба Объектного Времени (Time Service).

Общие Средства заполняют концептуальное пространство между ORB и

объектными службами с одной стороны, и прикладными объектами с другой.

Таким образом, ORB обеспечивает базовую инфраструктуру, Объектные Службы –

фундаментальные объектные интерфейсы, а задача Общих Средств – поддержка

интерфейсов сервисов высокого уровня. Общие Средства подразделяются на две

категории: "горизонтальные" и "вертикальные" наборы средств.

"Горизонтальный" набор средств определяет операции, используемые во многих

системах, и не зависящие от конкретных прикладных систем. "Вертикальный"

набор средств представляет технологию поддержки конкретной прикладной

системы (вертикального сегмента рынка), такого, как здравоохранение,

производство, управление финансовой деятельностью, САПР и т.д.

. Средства поддержки пользовательского интерфейса (User Interface Common

Facilities)

. Средства управления информацией (Information Management Common

Facilities)

. Средства управления системой (System Management Common Facilities)

. Средства управления задачами (Task Management Common Facilities)

. Вертикальные общие средства (Vertical Common Facilities)

. Вертикальные общие средства предназначены для использования в качестве

стандартных для обеспечения интероперабельности в специфических

прикладных областях.

. Поддержка интероперабельности брокеров в стандарте CORBA 2.0

О роли СУООБД в архитектуре OMG можно прочесть в [13].

На основе анализа вышеизложенного, были выбраны в качестве основания

следующие базовые службы СУООБД:

. Служба Долговременного Хранения Объектов – управление хранением объектов

. Служба Управления Конкурентным Доступом и Служба Транзакция – объединены

вместе протоколом согласованного управления.

. Служба Изменения Объектов – управление журнализацией изменений

3.2 Менеджер памяти

Менеджер памяти является ключевым модулем системы.

Его наличие позволяет

. Абстрагироваться от особенностей обращения к различным видам памяти.

. Создавать сколь угодно вложенные друг в друга структуры данных.

. Иметь единый интерфейс на каждом уровне вложенности.

. Организовать кэширование объектов

В состав менеджера памяти входит 3 системы управления:

1. Система управления виртуальной памятью

2. Система управления каналами

3. Система управления кэшированием объектов

3.3 Виртуальная память и каналы

Виртуальная память представляет собой непрерывную для пользователя, с

ней работающего, область памяти, которая может быть вложена в другую

виртуальную память. Виртуальная память состоит из сегментов, связанных

между собой в двунаправленную цепь. Каждому сегменту известно его положение

относительно нижнего логического уровня. Работа с виртуальной памятью

происходит через канал, выделенный для нее. Канал – это набор характеристик

описывающих: где расположена виртуальная память, и в каком ее месте мы

находимся. Количество каналов ограничено, поэтому канал выделяется той

виртуальной памяти, которая нужна в данный момент. Система имеет набор

каналов, которые могут иметь ссылку на виртуальную память, либо быть

незанятыми. Первые 5 каналов – это базовые каналы, отображенные на

физические носители (оперативная память, файл). Вторые 5 каналов – каналы

виртуальной памяти, хранящие каталоги объектов. Остальные каналы

предназначены для работы с объектами. Все каналы основываются на каких-либо

других каналах, образуя, в общем случае, 5 независимых деревьев. Корень –

один из базовых каналов (0..4). Одна и та же виртуальная память не может

быть загружена в два канала. При переходе от верхнего канала к нижнему

выполняется трансляция адреса.

[pic]

Рис 3: Связь каналов с хранилищами объектов

Таблица 2: Параметры канала

|Параметр канала |Семантика |

|NCHAN |Номер текущего канала |

|LOWCH |Нижний канал; в него вложен этот канал |

|CHGCTX |Признак изменения данных заголовка фрагмента |

|TEKADR |Текущая позиция для чтения/записи |

|SYNCADDR |Адрес начала заголовка текущего сегмента в нижнем |

| |канале |

|TEKADR0 |Позиция, соответствующая началу данных фрагмента |

|PREDADDR |Адрес заголовка предыдущего фрагмента (–1, если его |

| |нет) |

|NEXTADDR |Адрес заголовка следующего фрагмента (–1, если его |

| |нет) |

|BUSYLEN |Занятая длина |

|LEN |Выделенная длина |

Таблица 3: Операции доступа к данным виртуальной памяти

|Операция |Семантика (все операции работают с текущим каналом) |

|IBS |Чтение байта из канала |

|OBS |Запись байта в канал |

|GOTO |Переход по адресу в канале |

|@GOTO |Переход по смещению в канале |

|UPSIZE |Выделить доп. память в конце канала и встать на ее |

| |начало |

|DEFRAG |Сделать виртуальную память непрерывной на уровне |

| |нижнего канала (т.е. однофрагментной) |

Начало виртуальной памяти соответствует нулевому значению TEKADR.

Доступ осуществляется через операции позиционирования (GOTO и @GOTO),

чтения байта (IBS) и записи байта (OBS). Остальные функции, реализуются

через них (например, чтение длинного слова). К памяти может быть применена

функция UPSIZE с аргументом, содержащим необходимое количество байт для

выделения. Память может гарантированно выделяться до заполнения всей

выделенной длины. При исчерпании выделенной длины, делается запрос к

нижестоящему уровню о выделении дополнительной памяти. Если такой запрос

применяется к каналу ниже 5-го, соответствующего дисковому файлу, файл

увеличивается в размере, если его выделенная длина исчерпана. Если

увеличение размера файла невозможно из-за нехватки дискового пространства,

то, в случае невозможности выделения памяти за счет упаковки, возбуждается

ситуация NOMEMORY. При попытке доступа за пределы определенной виртуальной

памяти (например, чтение после расположения данных), возникает ситуация

OUTDATA.

3.4 Система управления кэшированием объектов

Самостоятельное кэширование данных – неотъемлемая черта любой СУБД.

Кэш состоит из двух частей: очереди кэшируемых объектов и памяти для

кэшируемых объектов. Память для кэшируемых объектов – это оперативная

память, в которую объект загружается. В этой памяти могут располагаться

только те объекты, идентификаторы которых находятся в очереди кэшируемых

объектов. Удаляемый из очереди объект выгружается в дисковую память. В

данной дипломной работе все создаваемые объекты являются стабильными

(Persistent), т.е. они обязательно сохраняются на диске и могут быть

использованы после открытия базы данных для использования.

Задача управления кэшированием объектов подобна задаче управления

памятью в операционной системе. В операционной системе для организации

процесса обмена между оперативной и внешней памятью информация представлена

набором сегментов (блоки переменной длины) или страниц (блоки фиксированной

длины). Способ управления памятью называется алгоритмом замещения, который

определяет состав сегментов или страниц в более быстродействующей основной

памяти. Таким образом, частота обращений к внешней памяти, а,

следовательно, и быстродействие двухуровневой памяти (уровень внешней

памяти и уровень оперативной памяти) в целом, существенно зависят от

выбранного алгоритма замещения. Наибольшее распространение получила

страничная структура памяти.

В дипломной работе роль страницы играет объект. Минимальную частоту

обращений к ВП (внешней памяти) давал бы алгоритм, замещающий те объекты в

ОП (оперативной памяти), обращение к которым в будущем произойдет через

максимально долгое время. Однако реализовать такой алгоритм невозможно,

поскольку заранее неизвестна информация о будущих обращениях к объектам

программой.

Наиболее популярны следующие пять алгоритмов замещения:

1. Случайное замещение (СЗ): с равной вероятностью может быть замещен любой

объект,

2. Раньше пришел – раньше ушел (РПРУ, или FIFO): замещается объект дольше

всех находившийся в оперативной памяти,

3. Замещение наиболее давно использовавшегося объекта (НДИ),

4. Алгоритм рабочего комплекта (РК): хранятся в памяти только те объекты, к

которым было обращение в течении времени (, назад от текущего момента,

5. Лестничный алгоритм (ЛЕСТН): в списке объектов при обращении к объекту

он меняется местами с объектом, находящемся ближе к голове списка. При

обращении к отсутствующему в ОП объекту объект, находящийся в последней

позиции вытесняется.

Для алгоритма замещения желательно, чтобы он обладал двумя отчасти

противоречивыми свойствами: с одной стороны, он должен сохранять в ОП

объекты к которым обращения происходят наиболее часто, с другой – быстро

обновлять содержимое ОП при смене множества рабочих объектов.

Например, алгоритм РПРУ эффективен только в отношении быстрого

обновления ОП, он не выделяет в списке объектов объекты, обращения к

которым происходят чаще, чем к остальным. Алгоритм НДИ также позволяет

быстро обновлять содержимое ОП. Однако последовательность одиночных

обращений достаточной длины к объектам, находящимся во ВП, вытеснит из ОП

все объекты, к которым, в среднем, обращения происходят чаще всего.

В [1] описывается класс многоуровневых алгоритмов замещения (,

которые позволяют решить эту проблему. Они зависят от конечного числа

параметров и при адаптивном подборе этих параметров соединяют свойство

быстрого обновления части ОП со свойством сохранения в ОП тех объектов,

которые наиболее часто запрашиваются.

В дипломной работе решено использовать алгоритм замещения из класса (,

при следующих параметрах: лимит времени нахождения объекта в ОП

отсутствует, размеры подсписков на всех уровнях одинаковы, параметр l=1

(это соответствует алгоритму замещения НДИ для объектов всех подсписков;

если i – положение объекта в подсписке, и i ( l, то при обращении к нему

применяется алгоритм РПРУ, иначе НДИ).

Неэффективным является подход простого освобождения от объектов,

которые стоят в конце списка кэша, поскольку они могут быть малы по

размеру, а требуется загрузить объект, который занимает значительное

количество памяти. В этом случае, пришлось бы ради одного объекта выгружать

значительное количество других. Что привело бы к значительным потерям

времени при их повторной загрузке.

Для определения подмножества объектов кэша, подлежащих вытеснению,

можно применить алгоритм решения задачи о рюкзаке. Если бы все объекты

имели одинаковую длину, без этого можно было бы обойтись. Хотя алгоритм

решения задачи о рюкзаке NP-сложен, решение можно компактно записать в виде

рекурсивного алгоритма, находящего решение за счет применения принципа

динамического программирования Беллмана. Такой способ наиболее эффективен,

когда размер кэша составляет 32 объекта, поскольку множество выбранных

объектов можно представить битовыми полями в длинном слове. При большем

размере кэша возрастают потери памяти и быстродействия, и возникает вопрос

о месте расположения данных промежуточных вызовов. Рекурсивный вызов в

среде ДССП требует малых затрат ресурсов, а время расчета окупается за счет

времени обмена с внешней памятью, работа с которой много медленнее, чем с

оперативной.

3.5 Система управления журнализацией и восстановлением

Журнализация предназначена во-первых, для обеспечения возможности

отката некорректных действий транзакций, и, во-вторых, для восстановления

базы данных после аппаратного сбоя. В ООБД журнализацию можно проводить на

трех уровнях: инфологическом, даталогическом и физическом. На

инфологическом уровне журнал фиксирует сообщения, циркулирующие в системе.

На даталогическом уровне фиксируется какие примитивы были вызваны на

выполнение сообщениями. На физическом уровне фиксируются низкоуровневые

операции: по какому адресу в какой виртуальной памяти производилась запись,

как изменились границы виртуальной памяти.

Обычные БД хранят мгновенный снимок модели предметной области. Любое

изменение в момент времени t некоторого объекта приводит к недоступности

состояния этого объекта в предыдущий момент времени. Интересно, что при

этом в большинстве развитых СУБД предыдущее состояние объекта сохраняется в

журнале изменений, но возможность доступа к этим данным для пользователей

закрыта.

Для журнализации избран подход, примененный в СУБД Postgres,

разработанной в университете г.Беркли, Калифорния под руководством

М.Стоунбрейкера, как наиболее простой в реализации и предоставляющий

полезные возможности, недоступные в базах данных с обычным типом

журнализации (см. [23]). В этой системе, во-первых, не ведется обычная

журнализация изменений базы данных, и мгновенно обеспечивается корректное

состояние базы данных после перевызова системы с утратой состояния

оперативной памяти. Во-вторых, система управления памятью поддерживает

исторические данные. Запросы могут содержать временные характеристики

интересующих объектов. Реализационно эти два аспекта связаны.

СУБД, имеющие такой вид журнализации, называются темпоральными СУБД.

Основной тезис темпоральных систем состоит в том, что для любого объекта

данных, созданного в момент времени t1 и уничтоженного в момент времени t2,

в БД сохраняются (и доступны пользователям) все его состояния во временном

интервале [t1, t2). Система не только хранит информацию о прошлых

состояниях объекта, но и предоставляет пользователю доступ к ней через язык

запросов.

Т.е. журнал состоит из меток времен и значений объектов. СУБД POSTGRES

является экспериментальной и, в частности, предполагается, что она

функционирует на вычислительной аппаратуре, оснащенной статической

оперативной памятью, не теряющей информации при отключении внешнего

питания. Впрочем, затраты на статическую память компенсируются

быстродействием СУБД и дополнительными возможностями, приобретаемыми при

таком подходе, а именно: возможность получить значение объекта в

произвольный момент времени.

Вообще говоря, каждый объект в системе состоит из трех частей:

Заголовка объекта, данных и истории. В заголовке объекта имеется поле

VALUE, которое содержит ссылку на начало расположения внутри объекта данных

о его состоянии. Объект, с которым пользователь хочет работать,

автоматически загружается системой в кэш, где ему выделяются 4 канала:

1. Канал объекта в кэше

2. Канал объекта на диске

3. Канал данных объекта в кэше

4. Канал истории изменений объекта на диске

Прикладной программист не работает напрямую с каналами. С каналами

работают примитивы доступа к содержимому объекта. Прикладной программист

работает с объектами только через их идентификаторы. А идентификаторам

объектов ставятся в соответствие каналы в системе кэширования объектов.

3.6 Принципы реализации механизма согласованного управления

Область действия операции

Каждый объект обладает поведением, реализуемым через методы

(операции). Если операция работает только с внутренними данными объекта, то

она является локальной, если же она посылает сообщения другим объектам, то

– глобальной. Посланное к другому объекту сообщение порождает на нем

выполнение соответствующей операции. Через транзитивное замыкание можно

представить процесс порождения отношением предок – потомок.

Областью действия операции на объекте являются:

Страницы: 1, 2, 3, 4, 5