Функции и архитектура субд
Термин «база данных» обозначает информацию, которой управляет СУБД. Предполагается, что СУБД: 1) Обеспечивает пользователю возможность создавать новые базы данных и определять их схему с помощью специального языка, который называется языком определения данных. 2) Позволяет запрашивать данные и изменять их с помощью языка манипулирования данными. 3) Поддерживает хранение очень больших массивов данных, измеряемых гигабайтами и более, в течение долгого времени, защищая их от повреждения, неавторизованного использования, и, обеспечивая модификацию базы данных, и доступ к данным посредством запросов. 4) Контролирует доступ к данным одновременно множеством пользователей, не позволяя запросу одних влиять на запросы другого и, не допуская одновременного доступа, который может случайно испортить данные.
Первые коммерческие СУБД (60е годы) возникли из систем, выполнявших пункт 3 (см. выше), и существенно использовали файловые системы для хранения данных. Недостатком этих СУБД является то, что файловая система не гарантирует защиту от потери данных. Файловая система непосредственно не выполняют пункт 2, то есть не поддерживают язык запросов на данные файлов. Поддержка пункта 1 ограничена созданием структуры каталогов для файлов.
Обзор основных компонентов СУБД.
Диспетчер транзакций
Модификация схемы
Выборка данных
Модиф. данных
Процессор запросов
Диспетчер памяти
Данные, метаданные
Метаданные это информация о структуре данных. Например, имена таблиц, имена атрибутов, типы данных атрибутов, описание того какие атрибуты имеют индексы.
Диспетчер памяти
Задачи диспетчера памяти - получать требуемую информацию из хранилища данных и изменять в нем информацию по требованию расположенных выше уровней системы.
Диспетчер памяти состоит из двух компонентов: диспетчера буферов и диспетчера файлов.
Диспетчер файлов контролирует расположение файлов на диске и получает блоки, содержащие файлы по запросу диспетчера буфера.
Диспетчер буфера управляет основной памятью (оперативной). Он получает блоки данных с диска, посредством диспетчера файлов и выбирает страницу ОП для хранения конкретного блока. Он может временно сохранять дисковый блок в основной памяти, возвращать его на диск, когда одной памяти нужна для другого блока. Страницы также возвращаются на диск по требования диспетчера транзакций.
Процессор запросов
Процессор запросов обрабатывает запросы и запрашивает изменение данных и метаданных. Его задача найти наилучший способ выполнения требуемой операции и дать соответствующие указания диспетчеру памяти.
Процессор запросов превращает инструкцию, написанную на языке высокого уровня, (как правило декларативном) в последовательность запросов на хранимые данные типа отдельных записей базы данных или частей индекса. Наиболее сложным действием является вывод лучшего плана выполнения запроса.
Пример: Найти баланс счетов Иванова. Схема базы данных: имеется два файла клиенты и счета. Простой дорогостоящий план – это прочитать весь файл клиенты для поиска Иванова. Если оптимизатору известно, что атрибут ФИО является уникальным, то поиск будет прекращен после нахождения первой записи, отвечающей критерию. В этом случае, в среднем, будет прочитано половина страниц файла. Затем нужно будет просмотреть файл счета для клиента с найденным номером. Более подходящий план будет построен, если атрибут ФИО имеет индекс. Типичный индекс типа B-tree позволит просмотреть все три дисковых блока для нахождения требуемого клиента. При наличии индекса на атрибуте клиент в файле счета можно найти один (или хотя бы один) счет клиента хотя бы за три дисковых операции. Если у клиента несколько счетов, то все они будут находиться на одной из соседних страниц индекса. Поскольку один клиент обычно не имеет большого числа счетов, то для выполнения рассмотренного запроса потребуется 6 – 10 обращений к диску. Select sum (value) FROM Клиенты Join Счета On ID-client=client Where FIO=’Иванов’.
Диспетчер транзакций
Транзакция – это последовательность операций с базой данных, рассматриваемая как единое целое. Транзакция либо успешно выполняется и СУБД фиксирует commit изменение базы данных, произведенное этой транзакцией во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии базы данных. Например, Прием на работу сотрудника и изменение численности отдела следует выполнять в рамках транзакции, чтобы гарантировать согласованное состояние данных. В противном случае, если после добавления записи в файл «сотрудники», или перед изменением численности отдела в файле «отделы» произойдет сбой, то данные будут находиться в несогласованном состоянии.
Параллелизм
Этот термин означает возможность одновременной обработки СУБД, многих транзакций с доступом к одним и тем же данным, причем в одно и то же время. Без управления параллелизмом возможны конфликтные ситуации, хотя каждая из параллельно выполняемых транзакций правильна сама по себе. Конфликтная ситуация выражается в том, что в результате могут быть получены данные, которых не было бы, если бы транзакции выполнялись последовательно. Можно выделить следующие конфликтные ситуации: 1) проблема потери результатов обновления 2) проблема незафиксированной зависимости 3) проблема несовместимого анализа (Транзакция A суммирует балансы трех счетов, а транзакция B переводит сумму в 10 условных единиц со счета 3 на счет 1.
Счет 1=40=>50, Счет 2=50, Счет 3=30=>20. Z=120.
Транзакция А |
Время |
Транзакция B |
Извлеч. счет 1 Sum=40 |
t1 |
-- |
Извлеч. счет 1 Sum=40 |
T2 |
-- |
-- |
T3 |
Извлеч. счет 3 |
-- |
T4 |
Обновление счет 3: 30->20 |
-- |
T5 |
Извлеч. счет 1 |
-- |
T6 |
Обновление счет 1: 40->50 |
Извлеч. счет 3 |
T7 |
commit |
Sum=110 |
T8 |
|
)
Блокировка
Описанные выше проблемы могут быть разрешены с помощью методики управления параллельным выполнением процессов под названием «блокировка». Ее идея состоит в том, что в случае, когда для выполнения некоторой транзакции необходимо чтобы некоторый объект не изменялся непредсказуемо без ведома этой транзакции, такой объект блокируется. То есть запрещается доступ к этому объекту со стороны других транзакций.
Обычно поддерживается два типа блокировок: X блок (блокировка записей) и S блок (блокировка чтения).
X блокировка называется также блокировка без взаимного доступа, а S блокировка – с взаимным доступом.
Если транзакция А блокирует картеж с помощью X блокировки, то есть без взаимного доступа, то запрос другой транзакции B с блокировкой этого картежа будет отменен (то есть любой). Если транзакция A блокирует картеж с помощью S блокировки, то запрос другой транзакции B на X блокировку будет отвергнут, а на S блокировку принят.
Протокол доступа к данным
Транзакция извлекающая картеж сначала должна наложить S блокировку на этот картеж.
Транзакция предназначенная для обновления картежа прежде всего должна наложить X блокировку на этот картеж.
Если запрашиваемая блокировка со стороны транзакции B отвергается из-за конфликта с блокировкой со стороны транзакции A, то транзакция B переходит в состояние ожидания. Это состояние будет продолжаться до тех пор, пока транзакция A не снимет блокировку.
X блокировки сохраняются вплоть до конца выполнения транзакции
Тупиковая ситуация возникает тогда, когда две или более транзакции одновременно находятся в состоянии ожидания, причем для прекращения работы каждой из транзакции ожидает прекращение выполнения другой транзакции (снятие блокировки). Не всякая система в состоянии обнаружить состояние тупика и найти из него выход. Выход из тупиковой ситуации заключается в выборе одной из двух блокирующих друг друга транзакции «жертвы» и отмены результатов ее выполнения.
Для обнаружения тупиковой ситуации СУБД может использовать хронометраж и состояние тупика оценивается по превышению некоторого времени. Некоторые системы позволяют автоматически перезапустить транзакции, которые привели к тупику. Другие системы отправляют сообщение в программу, из которой была выполнена транзакция жертва.
Протокол двухфазной блокировки
С управлением транзакциями в многопользовательской СУБД связано понятие сериализации. Под сериализацией параллельно выполняющей транзакции понимается такой порядок планирования их работы, при котором суммарный эффект смеси транзакций эквивалентен эффекту их некоторому последовательному выполнению.
Способность к упорядочению является общепризнанным критерием правильности управления обработки транзакции.
Для заданного набора транзакций любой порядок их выполнения называется графиком запуска. Два графика называются эквивалентными, если при их выполнении будет получен одинаковый результат. Рассмотренные примеры, которые приводили к проблемам демонстрировали чередующиеся выполнение транзакции, которая не была эквивалентна их последовательному выполнению. Проблему можно решить принудительным упорядочиванием.
Есвараном была доказана теорема двухфазной блокировки, которая формулируется следующим образом: если все транзакции подчиняются протоколу двухфазной блокировки, то для всех возможных чередующихся графиков запуска существует возможность упорядочивания. При этом протокол двухфазной блокировки формулируется следующим образом: 1) перед выполнением каких либо объектом, транзакция должна заблокировать этот объект. 2) после снятия блокировки транзакция не должна накладывать никаких других блокировок.
В соответствие с протоколом каждая транзакция может быть разделена на две фазы: фаза нарастания, в которой выполняются все необходимые блокировки не освобождается ни одного из элементов данных, и фаза сжатия, в которой снимаются все выполненные ранее блокировки и не может быть затребовано ни одной новой. Если СУБД поддерживает расширение уровня блокировки, то их выполнение допускается только в фазе нарастания. Снижение уровня блокировки допускается только в фазе сжатия.
Если A и B являются любыми транзакциями некоторого графика запуска, допускающего возможность упорядочивания, то либо A логически предшествует B, либо наоборот. То есть либо B использует результаты транзакции A, либо A использует результаты транзакции B.
Свойства транзакции
ACID.
A – атомарность. Требуется, чтобы были выполнены все операции транзакции, либо не одна из них.
B – непротиворечивость. В процессе выполнения транзакции согласованность данных может нарушаться, но данные будут согласованы до начала выполнения транзакции и до ее завершения.
Изолярность. Одновременное выполнение двух транзакций не должно привести к результату, которого не было бы, если бы транзакции выполнялись последовательно.
Долговременность. Результат транзакции не может быть утрачен, даже в результате сбоя системы, если транзакция была завершена.