Управление ресурсами. Сервер объектов и сервер страниц

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

Клиент посылает SQL-запрос на сервер. При получении запроса сервер его оптимизирует, выбирает подходящий план доступа, используя все имеющиеся индексы, и выполняет запрос. Результат запроса — это набор реляционных кортежей, которые возвращаются клиенту. Кортежи, возвращаемые сервером клиентам — это таблицы в первой нормальной форме, за исключением крупных объектов (например, blob).

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

Рис.43. Унификация

Рис.44. Взаимодействие клиента и сервера

Архитектура сервера объектов представлена на рис.45. Сервер объектов может получать запросы или на один объект (используя, к примеру, идентификатор объекта), или на набор объектов. Как показано на рис.45., связь между клиентом и сервером базируется на объектах, и кэш объектов, расположенный в оперативной памяти, поддерживается как на клиенте, так и на сервере (Диспетчер буфера объектов). Сами же объекты хранятся на диске, физически объединенные в страницы, но управление ими полностью осуществляется сервером, при этом клиенту практически ничего не известно об этом представлении.

Рис.45. Механизм взаимодействия клиента и сервера объектов

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

С другой стороны, серверы объектов имеют множество недостатков, что затрудняет их реализацию. К примеру, обработка запросов в случае обновления данных существенно усложняется, поскольку:

1. или измененные на клиенте данные должны передаваться на сервер перед исполнением там любого запроса,

2. или запросы должны параллельно исполняться на клиенте и на сервере, а полученные результаты — объединяться.

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

Вторая стратегия порождает серьезные проблемы, связанные с обработкой распределенных запросов. Когда объект одновременно существует и на сервере, и на клиенте, возникает практический вопрос, связанный с объектно-ориентированными языками программирования, для работы которых требуется среда реального времени. Исполнение методов на сервере означает, что программа, реализующая этот метод, сама должна храниться в базе данных, а СУБД должна ”понимать” требования среды исполнения всех языков программирования, объекты которых размещаются в базе данных. Наконец, поскольку объекты хранятся на страницах жесткого диска сервера, сервер объектов должен упаковывать и распаковывать эти объекты для обмена ими с клиентами. Это увеличивает рабочую нагрузку сервера и может привести к появлению узких мест.

Производительность сервера объектов может измениться и за счет необходимости передавать полные объекты через API-интерфейс, что может значительно снизить скорость работы в случае больших объектов.

Альтернативой архитектуре сервера объектов является архитектура сервера страниц (рис.46.), где передача между клиентом и сервером осуществляется постранично. Сервер в архитектуре сервера страниц выполняет минимальные функции, такие как восстановление и хранение страниц. Объекты существуют только на клиенте.

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

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

Сравнение сервера страниц и сервера объектов, показывает, что сервер в архитектуре сервера страниц менее функционален, чем в архитектуре сервера объектов, однако реализовать его намного проще.

Рис.46. Механизм взаимодействия клиента и сервера страниц

КОНТРОЛЬНЫЕ ВОПРОСЫ ПО ВОСЬМОМУ РАЗДЕЛУ

1. Перечислите побудительные мотивы к началу исследований по созданию ООСУБД.

2. Каковы особенности объектной модели данных.

3. Каковы достоинства и недостатки ООСУБД.

4. В чем основные отличия ООСУБД от ОРСУБД.

5. Приведите способы преобразования иерархии типов в реляционную модель данных.

6. Опишите способы взаимодействия сервера и клиента, используемые в ООСУБД

ВОПРОСЫ РАСПРЕДЕЛЕННЫХ БАЗ ДАННЫХ