СУБД структуры «сервер-клиент»

Построение распределенных систем важно, особенно в условиях бессистемного оснащения предприятий компьютерной техникой, когда многие уже работают (или им необходимо работать) с системами, состоящими из множества компьютеров разного типа (серверов, мини-компьютеров, больших машин).

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

Содержательная сторона задачи обычно требует обмена данными между группами АРМ, так как изменения в какие-либо данные могут вносить в одной группе, а использоваться – в другой. На практике обмен информацией реализуется регламентной передачей файлов – через модемное соединение или «с курьером».

То, что данные доставляются к месту назначения не системными средствами, а путем экспорта/импорта файлов, требует участия человека в процессе обмена, а это влечет за собой невысокую оперативность поступления данных и требует использования внешних механизмов контроля целостности и непротиворечивости. В результате возрастает вероятность появления ошибок. Кроме того, реализация всех алгоритмов обмена данными и контроля в этом случае возлагается на прикладных программистов, проектирующих APM. Объем работ по программированию и отладке подпрограмм обмена соответствует числу различных APM. Это также приводит к повышению вероятности сбоев в работе системы.

В современных технологиях APM объединены в локальную сеть. АРМ клиента выдает запросы на выборку и обновление данных, а СУБД исполняет их. Запросы клиента в соответствии с требованиями задачи сгруппированы в логические единицы работы (транзакции). Если все операции с базой данных, содержащиеся внутри транзакции, выполнены удачно, транзакция в целом также выполняется успешно (фиксируется). Если хотя бы одна из операций с БД внутри транзакции осуществлена неудачно, то все изменения в БД, происшедшие к этому моменту из-за транзакции, отменяются (происходит откат транзакции). Такое функционирование обеспечивает логическую целостность информации в базе данных.

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

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

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

Именно в этом сечении – между репликационными серверами – связь может быть медленной или недостаточно надежной. Передаваемые данные в составе транзакций при недоступности узла-получателя записываются в стабильные очереди на диске и затем передаются по мере возможности.

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

Система, хранящая вторичные данные, может быть любой из ряда систем, доступных через шлюз: будь то Oracle, Informix, DB2, RMS или ISAM и т.д. Система, хранящая первичные данные, требует наличия менеджера журнала транзакций (Log Transfer Manager – LTM). Интерфейс LTM является открытым, и в скором будущем, возможно, подобные модули будут созданы для нестандартных источников данных.

Вообще тиражирование данных может найти самое разнообразное применение:

• для разгрузки сервера, выполняющего активное обновление данных от сложных запросов, связанных с поддержкой принятия решений;

• для консолидации данных от подразделений в центре;

• для обмена данными по медленным или ненадежным линиям связи;

• для поддержания резервной базы данных;

• для построения сети равноправных узлов, обменивающихся данными.

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

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

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

Этому требованию в наибольшей степени отвечают компьютеру с симметричной многопроцессорной (SMP) или массивно-параллельной (MPP) архитектурой, на которых при увеличении количества процессоров обеспечивается практически линейный рост производительности. Обработка нескольких запросов, вложенных циклов внутри одного запроса, загрузка и сортировка данных, создание индексов и т.д. – все это выполняется параллельно на различных процессорах. Более того, одновременно реализуется эффективная динамическая балансировка загрузки системных ресурсов (процессоров, оперативной и дисковой памяти).