 |
Объемы современных баз данных и устройства для их размещения
|
|
|
|
ФИЗИЧЕСКАЯ ОРГАНИЗАЦИЯ БАЗ ДАННЫХ
ФИЗИЧЕСКИЙ ДОСТУП К БАЗЕ ДАННЫХ
Объемы современных баз данных и устройства для их размещения
Система физического доступа к базе данных представлена на рис. 1.
Пользователь взаимодействует с системой базы данных, запуская инструкции. Стратегический селектор преобразует пользовательскую команду в наиболее эффективную форму для выполнения. Преобразованное требование активизирует буферный диспетчер, контролирующий перемещение данных между оперативной памятью и диском. Диспетчер файлов поддерживает буферный диспетчер, управляя размещением данных на диске и структурами данных. Кроме пользовательских данных диск содержит словарь данных.
Стратегический селектор – программное обеспечение, преобразующее требование пользователя в эффективную для исполнения форму.
Управление буферами (диспетчер дисков) – программное обеспечение, контролирующее перемещение данных между оперативной памятью и диском.
Диспетчер файлов – программное обеспечение, управляющее размещением данных на диске и структурами данных.
Словарь данных – часть СУБД, определяющая структуру пользовательских данных и возможности их использования.
Оперативная память – запоминающее устройство, расположенное в узле процессора; используется для запоминания данных, доступных для оперирования.
Быстродействие системы управления базами данных в значительной степени определяется использованными физическими структурами данных и тем, насколько система эффективно оперирует этими структурами. При удачном физическом устройстве базы данных данные можно извлекать, обновлять, манипулировать за достаточно короткое время.
|
|
|
Чтобы достичь этого следует выполнить важные задачи настройки и администрирования базы данных. К их числу относят:
§ выбор способа размещения файлов на диске;
§ определение требуемого объема дисковой памяти;
§ распределение информации на диске.
Выбор способа размещения файлов на диске. Большинство СУБД позволяют администратору системы выбрать один из способов размещения файлов базы данных на дисках: на «чистых» дисках или в файловой системе.
Достоинством хранения информации на «чистых» дисках является то, что внешняя память используется более эффективно и, как правило, увеличивается производительность обмена с дисками. Экономия внешней памяти от 10 до 20% достигается на основе устранения необходимости организации самой файловой системы. К достоинствам работы с дисками через файловую систему относят:
1. использование файловой системы обладает большей гибкостью, так как дает администратору стандартные средства обслуживания файлов: утилиты резервного копирования, архивации, восстановления, а также возможность пользования другими программами работы с файлами (редакторами, антивирусными программами, утилитами контроля качества носителя и т. д.);
2. в некоторых случаях выполнение операций ввода/вывода через файловую систему обеспечивает оптимизацию, которую СУБД не может реализовать. В частности, в системе UNIX происходит кластеризация данных в более крупные физические единицы, чем в большинстве СУБД, что часто приводит к повышению производительности.
Определение требуемого объема дисковой памяти. При определении требуемого объема дисковой памяти следует учитывать, что для обработки данных СУБД использует большой объем служебной информации, размещаемой на дисках. К служебной информации относится: описание схемы базы данных, табличные индексы, временные таблицы, заранее выделенное пространство для хеш-таблиц и индексов, пространство для сортировки, файлы журнала, архивы и др.
|
|
|
Если точная информация об объеме служебной информации для БД отсутствует, то исходят из предположения, что для ее размещения требуется объем дисковой памяти, превосходящий объем размещаемых данных.
Распределение информации на Дисках. Рациональным и экономичным способом распределения информации на дисках является обеспечение основных задач обработки данных одним или несколькими дисками. Примером такого распределения является использование четырех дисков: одного - для операционной системы и области подкачки (swap), другого - для данных, третьего - для журнала транзакций и четвертого - для индексов.
Технически возможно разместить несколько функциональных дисковых областей на одних и тех же (физических или логических) дисках. Так практически всегда делается на СУБД, работающих на ПЭВМ. Однако совместное хранение разнородной информации на одних и тех же дисках приводит к перегрузке подсистемы ввода/вывода и, соответственно, к потере производительности. Перегрузка возникает из-за существенных временных затрат на позиционирование головок на диске.
В каждой СУБД по-разному организованы хранение и доступ к данным, однако, существуют некоторые файловые структуры, которые имеют общепринятые способы организации и применяются практически во всех СУБД.
В процессе работы с БД, важными являются вопросы хранения и методы доступа к данным. Основные проблемы, связанные с физическим хранением данных, вызваны медленностью доступа и поиска, а также низкой скоростью передачи. Основной целью повышения производительности системы является минимизация числа дисковых операций ввода-вывода данных.
Функции СУБД
К числу функций СУБД принято относить следующие:
ü управление данными во внешней памяти;
ü управление буферами оперативной памяти;
ü управление транзакциями;
ü журнализация и восстановление БД после сбоев;
ü поддержание языков БД.
Функция непосредственное управление данными во внешней памяти включает обеспечение необходимых структур внешней памяти как для хранения данных, непосредственно входящих в БД, так и для служебных целей, например, для убыстрения доступа к данным (обычно для этого используются индексы). В некоторых реализациях СУБД активно используются возможности существующих файловых систем, в других работа производится вплоть до уровня устройств внешней памяти. В развитых СУБД пользователи в любом случае не обязаны знать, использует ли СУБД файловую систему, и если использует, то как организованы файлы. В частности, СУБД поддерживает собственную систему именования объектов БД.
|
|
|
Управление буферами оперативной памяти. СУБД обычно работают с БД значительного размера; по крайней мере, этот размер обычно существенно больше доступного объема оперативной памяти. Если при обращении к любому элементу данных будет производиться обмен с внешней памятью, то вся система будет работать со скоростью устройства внешней памяти. Практически единственным способом реального увеличения этой скорости является буферизация данных в оперативной памяти. При этом, даже если операционная система производит общесистемную буферизацию (как в случае ОС UNIX), этого недостаточно для целей СУБД, которая располагает гораздо большей информацией о полезности буферизации той или иной части БД. Поэтому в развитых СУБД поддерживается собственный набор буферов оперативной памяти с собственной дисциплиной замены буферов.
Существует отдельное направление СУБД, которое ориентировано на постоянное присутствие в оперативной памяти всей БД. Это направление основывается на предположении, что в будущем объем оперативной памяти компьютеров будет настолько велик, что позволит не беспокоиться о буферизации. Пока эти работы находятся в стадии исследований.
Управление транзакциями. Транзакция - это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД. Поддержание механизма транзакций является обязательным условием даже для однопользовательских СУБД, гораздо более важно в многопользовательских СУБД.
|
|
|
Журнализация. Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Обычно рассматриваются два возможных вида аппаратных сбоев: так называемые мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера (например, аварийное выключение питания), и жесткие сбои, характеризуемые потерей информации на носителях внешней памяти. Примерами программных сбоев могут быть: аварийное завершение работы СУБД (по причине ошибки в программе или в результате некоторого аппаратного сбоя) или аварийное завершение пользовательской программы, в результате чего некоторая транзакция остается незавершенной. Первую ситуацию можно рассматривать как особый вид мягкого аппаратного сбоя; при возникновении последней требуется ликвидировать последствия только одной транзакции.
Понятно, что в любом случае для восстановления БД нужно располагать некоторой дополнительной информацией. Другими словами, поддержание надежности хранения данных в БД требует избыточности хранения данных, причем та часть данных, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД.
Журнал - это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД. В разных СУБД изменения БД журнализуются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения БД (например, операции удаления строки из таблицы реляционной БД), иногда - минимальной внутренней операции модификации страницы внешней памяти; в некоторых системах одновременно используются оба подхода.
Во всех случаях придерживаются стратегии "упреждающей" записи в журнал (так называемого протокола Write Ahead Log - WAL). Эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.
|
|
|
Самая простая ситуация восстановления - индивидуальный откат транзакции. Для этого не требуется общесистемный журнал изменений БД. Достаточно для каждой транзакции поддерживать локальный журнал операций модификации БД, выполненных в этой транзакции, и производить откат транзакции путем выполнения обратных операций, следуя от конца локального журнала. В некоторых СУБД так и делают, но в большинстве систем локальные журналы не поддерживают, а индивидуальный откат транзакции выполняют по общесистемному журналу, для чего все записи от одной транзакции связывают обратным списком (от конца к началу).
Поддержка языков БД. Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Чаще всего выделялись два языка - язык определения схемы БД (SDL - Schema Definition Language) и язык манипулирования данными (DML - Data Manipulation Language). SDL служил главным образом для определения логической структуры БД. DML содержал набор операторов манипулирования данными, т.е. операторов, позволяющих заносить данные в БД, удалять, модифицировать или выбирать существующие данные.
В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language).
|
|
|
