Спорныемоменты технологии

5.2 Спорныемоменты технологии.

Все ООСУБД по определению поддерживают сохранение и разделение объектов. Но,

когда дело доходит до практической разработкиприложений на разных ООСУБД,

проявляется множество отличий в реализации поддержки трех характеристик:

Целостность;

Масштабируемость;

Отказоустойчивость.

Отметим, что ООБД не требуют многих из тех внутренних функций и механизмов,

которые столь привычны и необходимы в реляционных БД.Например, при небольшом

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

объектные СУБД не нуждаются в поддержке сложных механизмоврезервного

копирования/восстановления (исторически сложилось так, что первые ООБД

проектировались для поддержки небольших рабочих групп – порядка десятичеловек –

и не были приспособлены для обслуживания сотен пользователей). Тем не менее

технология БД определенно созрела для крупных проектов.

Дляиллюстрации первой категории рассмотрим механизм кэширования объектов.

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

жеадресное пространство, где работает сама СУБД. Благодаря этому достигается

повышение производительности часто в 10‑100раз по сравнению с раздельными

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

объекты и разрушить базу данных.

Существуют два подхода к организации реакции СУБД для предотвращения потери

данных.Большинство систем передают приложению указатели на объекты, и рано или

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

неправильныпосле перехода объекта к другому пользователю (например, после

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

пунктуален, тоошибки не возникает. Если же приложение попытается применить

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

системы, вхудшем – будет утеряна информация в середине другого объекта и

нарушится целостность базы данных.

Есть метод, лучший, чем использование прямых указателей (Рисунок 3). СУБД

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

система может автоматически разрешить ситуацию (перезагрузить, если это

необходимо,объект) без возникновения конфликтной ситуации.

Существует еще одна причина для применения косвенной адресации: благодаря этому

можноотслеживать частоту вызовов объектов для организации эффективного механизма

свопинга.

Это необходимо для реализации уже второго необходимого свойства баз данных –

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

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

(такая архитектура называется еще “толстыйклиент-тонкий сервер”), лучше

справляется с этой задачей, чем мэйнфреймовая структура, однако ее все равно

нельзя масштабировать до уровня предприятия.Благодаря многозвенной архитектуре

клиент-сервер (N-Tier architecture) происходит равномерноераспределение

вычислительной нагрузки между сервером и конечным пользователем. Нагрузка

распределяется по трем и более звеньям, обеспечивающим

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

“Архитектура клиент-сервер, еще совсем недавно считавшаяся сложной средой,

постепеннопревратилась в исключительно сложную среду. Почему? Благодаря

ускоренному переходу к использованию систем клиент-сервер нескольких звеньев”

(PCMagazine).Разработчикам приходится расплачиваться дополнительными

сложностями, большими затратами времени и множеством проблем, связанных с

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

лишенной оптимизма ноте.

Рисунок 3 Прямая и косвенная адресации.

Третье необходимое качество базы данных – это отказоустойчивость. Именно это

свойство отличает программныйпродукт от “прилады”. Существуют несколько способов

обеспечения отказоустойчивости:

резервное копирование и восстановление;

распределение компонентов;

независимость компонентов;

копирование.

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

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

транзакции – сохранение информации, необходимой для восстановления после сбоя, и

окончанию транзакции –восстановление или, в случае невозможности, принятие

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

СУБД этот механизмобеспечивает восстановление в случае возникновения практически

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

об идеальнойзащите от сбоев.

В мэйнфреймовой архитектуре единственным источником сбоев была центральная ЭВМ.

При переходе к распределенной многозвенной организацииошибки могут вызывать не

только компьютеры, включенные в сеть, но и коммуникационные каналы. В

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

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

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

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

распределенных СУБД свойства:

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

чему пользователю доступны все сервисы СУБД и может производиться

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

так называемый “трехфазный монитор транзакций” (third-party transaction

monitor), благодаря которомутранзакция выполняется не в два, а в три этапа –

сначала посылается запрос о готовности к транзакции.

Что произойдет, если один из компонентов выйдет из строя? Система, созданная в

соответствии только с вышеизложенными доводами,приостановит работу всех

пользователей и прервет все транзакции. Поэтому важно такое свойство СУБД, как

независимость компонентов.

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

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

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

важной информации внутри каждого сегмента. Современныесистемы позволяют

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

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

И, наконец, о копировании (replication) данных. Простейшим способом является

добавление к каждому (основному) серверу резервного. После каждойоперации

основной сервер передает измененные данные резервному, который автоматически

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

недостатков. Во-первых, это приводит к значительным накладным расходам при

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

по себе является потенциальным источником сбоев. Во-вторых, в случае сбоя,

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

будет работать в своем сегменте сети в качестве основного сервера, причем

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

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

Более совершенным является подход, когда создается необходимое (подбираемое в

соответствии с требуемым уровнем надежности) числокопий в сегменте. Таким

образом увеличивается доступность копий и даже (при распределении нагрузки между

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

несколькими серверами одновременно в случае их взаимной недоступности решается

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

имеющем наибольшее число пользователей. При хорошо настроенной схеме кэширования

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

нулю.