🫙 Про чтение в SQL [ч. 1]

Господа-аналитики, ничего сложного, делаем 90% своей работы, все в порядке. А вот как работает все под капотом не было особо сильного понимания. Решил глянуть парочку источников... 🔥 Будем говорить в контексте работы с нераспределенными базами данных. К ним относятся: PostgreSQL, MySQL, Oracle, MS SQL. Увидел формулировку ниже, решил покопать ⌨️ Основная идея повышения скорости работы нераспределённой базы данных заключается в уменьшении количества операций чтения/записи с жёсткого диска

👀 У ИТМО нашел страничку, где описаны объемы, производительности, стоимости, в целом можно собрать какие-то выводы, что оперативка быстрее и лучше, но дороже, в целом понятно, почему хочется меньше жесткого диска)

Но RAM выполняет функцию буфера, а данные хранятся на диске.

Предположим, у нас есть упрощенная табличка в нераспределенной базе данных people со следующей структурой:

`CREATE TABLE people ( last_name varchar(32), first_name varchar(32), second_name varchar(32), sex char(1), birthday date );

Допущение, что в среднем фамилия имя и отчество состоят из 7 RU символов, а кодировка используется Unicode, тогда средняя строка займет на диске:

(7 * 2 + 1) * 3 + 2 * 1 + 4 = 51 байт

💅 Есть еще определенная метадата, которая будет добавлять +32 байта, тогда средняя строчка займет 83 байта с учетом метадаты. Блок - это минимальная единица чтения и записи базы данных (страница данных в файле таблицы). Один блок во многих учебных материалах идет в 4 кб (4096 байт) 👩‍💻 У постгре, например, он стоит в 8 кб по стандарту=> В одном блоке содержится 📛

4096 / 83 = 49 строк и 29 байт остатка

⚠ Важно: база читает не одну строку, а весь блок целиком.

В таблице у нас 1000 записей, значит суммарно у нас будет блоков:

1000 / 49 ~ 20.4 блоков (округляем до 21)

Хотим сделать фильтрацию в SQL 🔽 `select * from people where last_name IN('Иванов', 'Петров', 'Сидоров');

❓ Мы не знаем где находятся записи, поэтому блоки будем считывать последовательно ([1, 2, 3, ... 21] блок, а может наши данные находятся в 12, 15 и 21 блоке).

🙊 Чем ближе нужные строки друг к другу, тем быстрее запрос. Если они лежат в одном блоке, база считает всё за один проход, а если раскиданы по разным, то придётся читать каждый блок отдельно 🐢 🙅‍♂️ Если отсортировать записи в блоке по ключу, то, дойдя до последнего совпадения, можно просто остановить поиск, так как дальше нужных значений уже не будет.

Чтобы не читать лишние блоки и быстрее находить нужные записи можно пользоваться индексными структурами, про которые я хочу написать в последующих постах, поговорим о стоимости запросов и о том, где они хороши, а где нет. Все что нужно — это 🐳

А я то думал, что когда был в 💙 и строил витрины с сегментациями, сортировками, думал, что все просто, но еще нужно много всего подучить 🧑‍🎓

@zasql_python``