Господа-аналитики, ничего сложного, делаем 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