Почему обычные базы медленные на аналитике

В прошлом уроке мы развели две нагрузки: транзакции трогают одну строку по ключу, аналитика читает тысячи строк, но берёт из каждой пару колонок. Допустим, «Гонец» скопировал заказы в отдельный PostgreSQL только для отчётов. Приложению он больше не мешает. Станет ли от этого быстрым сам отчёт? Нет. Разберём почему: дело не в том, что PostgreSQL плохая база, а в том, как он раскладывает данные по диску.

Картотека с карточками

Представь картотеку заказов. На каждый заказ заведена карточка, и на ней записаны все одиннадцать полей: номер, клиент, зона, курьер, статус, расстояние, цена, четыре времени. Карточки стоят в ящиках по порядку поступления.

Кассиру такая картотека удобна. Клиент спрашивает про заказ 20 000, кассир находит нужный ящик по алфавитному указателю, достаёт одну карточку и видит на ней всё сразу.

А теперь бухгалтеру нужна выручка по зонам. Ему важны два поля на каждой карточке: зона и цена. Но вытащить из картотеки только эти два поля нельзя. Он достаёт карточку целиком, смотрит на два поля, откладывает. И так сорок одну тысячу раз. Девять полей из одиннадцати он держал в руках зря.

Так и устроены строковые базы.

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

PostgreSQL хранит таблицу в файле, нарезанном на страницы по 8 КБ. На странице лежат строки целиком, одна за другой: все колонки заказа рядом. Базы, которые так хранят данные, называют строковыми (row-store).

Учебная таблица orders «Гонца» в PostgreSQL занимает 506 страниц, это 4 МБ. Средняя строка весит 96 байт, из них 24 байта служебный заголовок, который PostgreSQL приписывает каждой строке. На одну страницу помещается около 80 заказов.

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