 |
Функции и архитектура СУБД
|
|
|
|
Термин «база данных» обозначает информацию, которой управляет СУБД. Предполагается, что СУБД: 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 блокировку принят.
Протокол доступа к данным
1. Транзакция извлекающая картеж сначала должна наложить S блокировку на этот картеж.
2. Транзакция предназначенная для обновления картежа прежде всего должна наложить X блокировку на этот картеж.
3. Если запрашиваемая блокировка со стороны транзакции B отвергается из-за конфликта с блокировкой со стороны транзакции A, то транзакция B переходит в состояние ожидания. Это состояние будет продолжаться до тех пор, пока транзакция A не снимет блокировку.
4. X блокировки сохраняются вплоть до конца выполнения транзакции
Тупиковая ситуация возникает тогда, когда две или более транзакции одновременно находятся в состоянии ожидания, причем для прекращения работы каждой из транзакции ожидает прекращение выполнения другой транзакции (снятие блокировки). Не всякая система в состоянии обнаружить состояние тупика и найти из него выход. Выход из тупиковой ситуации заключается в выборе одной из двух блокирующих друг друга транзакции «жертвы» и отмены результатов ее выполнения.
Для обнаружения тупиковой ситуации СУБД может использовать хронометраж и состояние тупика оценивается по превышению некоторого времени. Некоторые системы позволяют автоматически перезапустить транзакции, которые привели к тупику. Другие системы отправляют сообщение в программу, из которой была выполнена транзакция жертва.
|
|
|
