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

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

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

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

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

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

- для разгрузки  сервера, выполняющего активное  обновление данных (OLTP) от сложных  запросов, связанных с поддержкой  принятия решений (decision-support);

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

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

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

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

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

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

Исторически первым появился метод синхронного внесения изменений в несколько БД, называемый двухфазной фиксацией (2РС, two- phase commit). Этот механизм реализован сейчас практически всеми производителями СУБД. Суть метода двухфазной фиксации состоит в том, что при завершении транзакции серверы БД, участвующие в ней, получают команду «приготовиться к фиксации транзакции». После получения подтверждений от всех серверов транзакция фиксируется на каждом из них. Таким образом, в любой момент времени обеспечивается целостность данных в распределенной системе. Платой за это являются требование доступности всех участвующих серверов и линий связи во время проведения транзакции, а также невозможность работы приложений-клиентов при недоступности, например, удаленного сервера. Кроме того, необходимо высокое быстродействие линий связи для обеспечения приемлемого времени реакции у приложения-клиента.

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

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

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

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

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

Надо отметить, что асинхронная репликация не делает линии связи более надежными или скоростными. Она лишь перекладывает задачи трансляции данных и обеспечения их целостности «с плеч» прикладной программы и пользователя на системный уровень.

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

Вместе с тем асинхронная репликация транзакций принципиально обеспечивает целостность информации, так как объектом обмена данными здесь является логическая единица работы - транзакция, а не просто данные из измененных таблиц.

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

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

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

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

В отличие от операционной системы, которая должна обеспечивать выполнение произвольных процессов, ВП подразделяются на несколько классов, каждый из которых спроектирован для наиболее оптимального выполнения задач определенного вида. Например, ВП CPU работают на потоки обслуживания клиентов, реализующие оптимизацию и логику выполнения запросов; ВП АIO выполняют операции асинхронного обмена с диском; ВП TLI контролируют сетевое взаимодействие.

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

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

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

- снизить  общее потребление памяти, поскольку  участвующим в разделении процессам, то есть виртуальным процессорам, нет нужды поддерживать свои  копии информации, находящейся в  разделяемой памяти;

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ЗАКЛЮЧЕНИЕ

 

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

В последнее время наибольшее распространение получили реляционные базы данных (слово «реляционная» происходит от английского relation – отношение). Концепции реляционной модели данных связаны с именем известного специалиста в области систем 6aз данных Е. Кодда. Именно поэтому реляционную модель данных в литературе часто называют моделью Кодда.

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