теория
Почему GROUP BY Аркадия положил реплику, хотя она спокойно держит тысячи заказов в минуту? Потому что «сколько данных» — не главный вопрос. Главный — какой формы касания.
Операционная нагрузка — — это множество мелких точечных касаний: найти заказ по номеру, списать остаток, обновить статус. Строка за строкой, по индексу, каждая транзакция трогает байты десятками. Под это строковые базы и построены: запись целиком лежит рядом, индекс ведёт к ней за миллисекунды.
Аналитическая нагрузка — — противоположна по геометрии: один запрос гладит миллионы строк подряд, но из каждой ему нужны две-три колонки. Средняя цена по категории за три года — это «пройди всю историю, возьми только цену, категорию и дату». В строковой базе ради трёх колонок с диска поднимается вся строка — с адресом доставки, комментарием покупателя и статусом оплаты. Девяносто процентов прочитанного выбрасывается.
Хуже того: скан вымывает из кэша горячие страницы — те самые, которыми живут заказы (мы видели эту болезнь в восьмом модуле, когда рабочий набор выпал из памяти). Один честный аналитический запрос — и операционная база задыхается не от объёма, а от чужой формы.
просто переворачивает раскладку: на диске рядом лежат не поля одной строки, а значения одной колонки. Скану «цена + категория + дата» больше не нужно поднимать ничего лишнего — он читает три плотных ленты байтов. А раз в ленте подряд лежат похожие значения (цены, даты, повторяющиеся категории), она сжимается в разы — и скан ускоряется ещё на порядок, потому что диск читает меньше байтов.
Один и тот же миллион рядов может быть непосильной ношей для одной раскладки и лёгкой прогулкой для другой. Форма хранения должна повторять форму нагрузки — размер тут ни при чём.