Как устроена база данных например mysql?

#cpp #mysql #база_данных #postgresql #архитектура

Я так понимаю есть файл базы к примеру test.db

В test.db есть pages(страницы - я так понимаю это набор битов, разделение для быстрого
доступа) по 8кб(допустим). Если файл базы огромный, как база быстро переключается на
нужную страницу (на нужную область памяти).

К примеру есть текстовый файл с 1 миллион строк. Как мне быстро переключатся на нужную
строку? к примеру сейчас я на 10 строке, оп уже на 200 тысячной и т.д.. без цикла?
То есть как организован данный функционал для быстрого переключения на нужную страницу
в базе? (или на строку в файле? если такое возможно)

Надеюсь поймете что я имею ввиду!
    

Ответы

Ответ 1

Могу в общих чертах описать как базы хранит в файлах PostgreSQL.

Постгрес хранит таблицы и индексы в отдельных файлах. Максимальный размер файла =
1GB (также называется сегментом), если таблица/индекс выходит за эти пределы, то она
дробится на несколько файлов по 1GB. В сегментах размещаются странички размером по
8kB (эта цифра, как и ограничение в 1GB может меняться на этапе компиляции). При работе
с данными эти странички выгружаются в память и при необходимости повторного чтения
берутся уже оттуда.

Непосредственно строки (tuples в терминологии постгреса) хранятся в этих страничках
следующим образом:

В начале каждой странички имеется заголовок. Из интересного для нас на данный момент
там хранится указатель на начало свободного места в страниче и указатель на его окончание.
После загловка лежат идентификаторы строк, хранящихся в страничке. Каждый идентификатор
представляет из себя указатель на начало строки и её размер. Постгрес наделяет каждую
строку в базе уникальным идентификатором (CTID), он как раз и состоит из номера странички
+ идентификатора строки в ней. Это позволяет, имея CTID, быстро и без проблем найти
строку на диске.

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

Вот приблизительное графическое представление:


Ответ 2

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

Все данные фиксированной длины вроде INT, FLOAT размещаются прямо в структуре записи.
Плюс в записи имеется динамический участок, длиной 65536 байт в котором размещаются
данные не фиксированной длины вроде VARCHAR, здесь же хранятся NULL-значения. Если
вы создадите несколько столбцов VARCHAR, которые полностью выберут этот динамический
участок в 65536 байт, MySQL вам просто не даст создавать новые столбцы (Попробуйте
ради интереса создать UTF-8 VARCHAR длиной 65536 - под  UTF8-символ в MySQL отводится
либо 3, либо 4 байта, в зависимости от кодировки). Тяжелая артиллерия вроде BLOB, TEXT
полей хранится вообще отдельно. Поэтому вы всегда можете вычислить адрес вашей записи,
просто маппите данные в память, знаете где начало участка памяти, а адрес любой строки
можете вычислить зная размер фиксированного участка. В нем же хранится адрес динамического
участка и BLOB/TEXT-значений.

Есть отличная книга "MySQL. Оптимизация производительности.  Бэрон Шварц, Петр Зайцев,
Вадим Ткаченко, Джереми Д. Зооднай, Дерек Дж. Баллинг, Арьен Ленц". Переведена на русский
язык и является отличным введением в архитектуру MySQL.