Хранение данных в СУБД. Структура и особенности Storage
1. Storage и файловая организация
Storage отвечает за физическое хранение данных в базе. В большинстве СУБД один файл базы данных соответствует одной таблице. Чтобы эффективно работать с файлами, особенно в многопользовательской среде, используется пейджинг — разбиение файлов на блоки фиксированного размера, называемые страницами (pages).
Размер страниц зависит от СУБД:
Размер | База данных |
|---|---|
4 КБ | SQLite, ORACLE, RocksDB |
8 КБ | MSSQL Server, PostgreSQL |
16 КБ | MySQL |
Пейджинг позволяет точно определить, где находятся нужные данные: если известно, что значение хранится на определённой странице в определённой ячейке, его легко и быстро извлечь.
2. Структура страницы (page)
Что хранится в одной странице
Хедер страницы:
checksum— контрольная сумма (определяет, не повреждена ли страница)offset— указатель на начало свободного пространства
Записи (records):
Если все записи фиксированной длины (например, 32 байта), перемещение между ними эффективно и предсказуемо.
Если записи переменной длины (например,
varchar(255)), тогда для длинных значений может создаваться Overflow Page — специальная страница, куда переносится "перелив" данных. В PostgreSQL такая технология называется TOAST (The Oversized-Attribute Storage Technique).
Хедеры записей (tuple headers):
У каждой записи в пределах страницы есть собственный хедер с указателем на реальные данные внутри страницы.
В PostgreSQL хедер страницы имеет фиксированную длину — 24 байта.
Управление пространством в странице
Специальные указатели pd_lower и pd_upper показывают границы:
Где заканчиваются хедеры
Где начинаются записи
С их помощью можно определить оставшееся свободное место в странице.
Проблема фрагментации и решение
При удалении записей остаются "дыры". Например, две записи по 4 байта удалены, но вставить одну на 8 байт может быть затруднительно без сдвига остальных.
Чтобы не блокировать работу других процессов и не смещать вручную, используется VACUUM — встроенный сборщик мусора PostgreSQL, который освобождает место и перераспределяет записи.
3. Строковые и колоночные базы данных
Строковые БД (row-store)
Хранят строки целиком. Пример:
Такой подход удобен для операций с полными строками (например, SELECT * FROM).
Колоночные БД (column-store)
Хранят значения по колонкам. Пример:
Подход идеально подходит для аналитических задач, агрегаций и выборок по отдельным колонкам, так как:
Улучшается сжатие
Повышается скорость чтения нужных данных
Недостаток: при необходимости собрать полную строку из разных колонок потребуется дополнительная операция "сборки", что может быть затратным.