Как проектировать схему данных для высоконагруженной системы

Проектирование схемы для high-load системы начинается с реальных паттернов доступа: какие запросы самые частые, какие поля участвуют в фильтрации и сортировке, где будут узкие места по записи и чтению. Обычно сначала проектируют нормализованную схему, затем осознанно добавляют индексы, денормализацию, партиционирование и, при необходимости, шардирование под конкретные рабочие нагрузки.

С чего начинать

Схему для высоконагруженной системы нельзя проектировать в вакууме. Сначала нужно понять:

какие есть сценарии чтения и записи;
какие запросы будут самыми частыми и самыми дорогими;
какой объём данных ожидается через 6–12–24 месяца;
какие требования к latency, доступности, консистентности и восстановлению после сбоев.

Ключевой принцип

Для high-load схемы важнее всего реальные паттерны доступа. Хорошая модель данных строится не только по предметной области, но и по тому, как приложение будет читать и изменять данные. Поэтому вопросы вроде «какие поля идут в WHERE, JOIN, ORDER BY» важны уже на этапе дизайна.

Типичный подход

Сначала нормализация — убрать лишнее дублирование, выделить сущности и связи, сделать модель логически чистой.
Выделить горячие запросы — понять, какие запросы будут критичны по задержке и объёму.
Спроектировать индексы — под реальные фильтры и сортировки, а не «на всякий случай».
Подумать о денормализации — если слишком много JOIN и агрегаций на пути чтения.
Заложить партиционирование — если таблицы быстро растут и запросы обычно бьют по времени или по tenant'ам.
Заранее оценить шардирование — если single-node решения явно не хватит на горизонте роста.

На что особенно смотреть

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

Практическая формулировка

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

Как проектировать схему данных для высоконагруженной системы?