Подсистема хранения данных

Эта статья находится в разработке!

Определение:

Подсистема хранения данных (англ. database engine, storage engine) — компонент СУБД, управляющий механизмами хранения баз данных, или библиотека, подключаемая к программам и дающая им функции СУБД.

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

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

В некоторых СУБД подсистема хранения неотделима от неё самой, но ряд подсистем могут встраиваться или подключаться к разным СУБД, например, системы семейства MySQL[1]. Некоторые известные подключаемые подсистемы хранения: SQLite[2], DBM[3] (ключ — значение).

Структура

Определение:

Структура данных — это абстрактная конструкция, в которой данные размещаются четко определенным образом.

Типы памяти

Тип	Характеристика	Величина
Оперативная память	Объём	16 - 256 ГБ
	Цена	~5 $/ГБ
	Быстродействие	~10+ ГБ/с
	Время доступа	1-10 μ/с
SSD	Объём	0.5 - 8 ТБ
	Цена	~0.1 $/ГБ
	Быстродействие	0.500-6 ГБ/с
	Время доступа	0.1-0.2 мс
Жёсткие диски	Объём	4 - 12 ТБ
	Цена	~0.03 $/ГБ
	Быстродействие	10-200 МБ/с
	Время доступа	5-100 мс

СУБД могут хранить данные в оперативной памяти, на SSD, на жёстком диске.

Многие СУБД для хранения данных всё ещё оптимизируют под особенности жёсткие дисков. Хотим сократить общее количество обращений к диску и по возможности сделать их последовательными.

Особенности жёстких дисков

• Большое время поиска
• Скорость чтения
  • Последовательный доступ – средняя
  • Случайный доступ – низкая
• Сократить число обращений
  • Сделать их последовательными

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

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

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

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

Определенный тип структуры данных может быть очень эффективным в одних операциях и очень неэффективным в других.

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

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

В некоторых СУБД администраторы баз данных имеют возможность выбирать из вариантов структур данных для содержания пользовательских данных по соображениям производительности. Иногда структуры данных имеют выбираемые параметры для настройки производительности базы данных.

Организация данных

• Файл – одна или несколько таблиц (чаще всего);
• Таблица – несколько страниц;
• Страница – несколько записей.

Какие проблемы?

Записи длиннее страницы. Не все СУБД это позволяют (записи длиннее страницы не поддерживаются (исключение - колонки BLOB, CLOB, которые могут храниться отдельно))

Модули системы хранения

Схема доступа к данным

Диспетчер диска

• Каталог страниц
• Оптимизация последовательностей страниц

Диспетчер страниц

• Доступ к страницам
• Распределение памяти
• Выгрузка данных

Диспетчер записей

• Доступ к записям

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

1. Вначале СУБД определяет, какая ей требуется запись, и передает диспетчеру записей запрос на выборку этой записи. (В целях этого простого описания предполагается, что СУБД обладает способностью заблаговременно и точно определять, какая именно запись ей потребуется. На практике чаще всего возникает необходимость сделать выборку набора из нескольких записей и выполнить поиск среди этих записи в оперативной памяти, чтобы найти ту конкретную запись, которая действительно требуется. Но, в принципе, это означает лишь то, что последовательность шагов 1—3 иногда приходится повторять для каждой записи из этого набора);
2. Диспетчер страниц свою очередь определяет, какая страница содержит требуемую запись, и передает диспетчеру диска запрос на выборку этой страницы;
3. Наконец, диспетчер диска определяет физическое местонахождение желаемой страницы на диске и выдает необходимый запрос на выполнение операции ввода-вывода на диске.

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

Страничная организация памяти

Определение:

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

Все современные СУБД умеют использовать.

Память разбита на равные страницы

• Прямое отображение в память
• Загрузка и выгрузка всей страницы
• Для IA32 и AMD64 обычно 4КБ (для маленьких страниц), 2МБ или 4МБ (для больших страниц)

Обработка быстрее чем чтение

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

Последовательности страниц

• Хранят данные одного типа. Обычно данный одной таблицы или индекса, для которых типичны к следующей/предыдущей странице.
• Частые переходы к следующей/предыдущей странице
• Желательно хранить последовательно

Преимущества страничной памяти

• Легко выделять физическую память — списки свободных ячеек;
• Естественный подход — все ячейки одного размера;

Недостатки страничной памяти

• Внутренняя фрагментация;
  • Процессам может быть нужны размеры, некратные размеру страницы;
  • По сравнению с размером адресного пространства, размер страницы очень мал;
• Накладные расходы при обращении к памяти;
  • вначале к таблице страниц, а затем уже к памяти:
    • Решение: аппаратный КЭШ для обращений к таблице страниц (TLB translation lookaside buffer – буфер внутри процессора);
• Большой объем памяти, требуемый для хранения таблиц страниц.

Список страниц

Схема списка страниц

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

• Диспетчер диска – последовательности
• Диспетчер памяти – предвыборка

Идентификатор записи (RID)

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

• Id страницы
• Id записи внутри страницы

Не должен меняться со временем, поскольку используется одновременно во многих местах для ссылки на эту запись, иначе нам придётся хранить в памяти и на диске отображение из старых номеров в новые и каждый раз проверять не изменился ли Id (не дешево) или нужно будет найти все места, где идентификатор записи использовался и все поменять.

Хранение данных на странице

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

Когда записи не помещаются, создаём страницу переполнения и переносим на неё примерно половину записей, что даст пространство для роста на соответствующей странице.

Как избежать цепочек

Чтобы не возникало связного списка страниц переполнения, запишем в исходную страницу указатель на место, где находится конкретная запись (исходную страницу всегда знаем, поскольку идентификатор записи - это в первую очередь идентификатор страницы).

Сжатие данных

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

• Больше вычислений
• Меньше ввода-вывода
• Часто – быстрее

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

Пример

• Сжатие по полям
• Инкрементальное сжатие
• Префиксное сжатие

Литература

• Дейт К. Введение в системы баз данных (Приложение Г)
• Кнут Д. Искусство программирования. Том 3. Сортировка и поиск
• Silberschatz A., Korth H. F., Sudarshan S. Database System Concepts