Коротко — компромисс сводится к выбору между меньшим объёмом хранения и гибкостью (нормализация) и скоростью выполнения аналитических запросов / простотой исполнения (денормализация). Ниже — объяснение с конкретными примерами и численными оценками.
1) Примеры структур
- Нормализованная (реляционная, фактовая таблица + размерности):
- fact_logs: $‘even{t}_{i}dPK‘,‘tsTIMESTAMP‘,‘use{r}_{i}dINTFK‘,‘endpoin{t}_{i}dINTFK‘,‘statu{s}_{i}dSMALLINT‘,‘byte{s}_{s}entBIGINT‘$ - dim_user: $‘use{r}_{i}dPK‘,‘emailVARCHAR‘,‘tenan{t}_{i}dINT‘,\dots$ - dim_endpoint: $‘endpoin{t}_{i}dPK‘,‘pathVARCHAR‘,‘serviceVARCHAR‘$ - dim_status: $‘statu{s}_{i}dPK‘,‘codeINT‘,‘descVARCHAR‘$
- Денормализованная (широкая строка, все поля вместе):
- events_wide: $‘even{t}_{i}dPK‘,‘tsTIMESTAMP‘,‘use{r}_{e}mailVARCHAR‘,‘tenan{t}_{i}dINT‘,‘endpoin{t}_{p}athVARCHAR‘,‘serviceVARCHAR‘,‘statusINT‘,‘byte{s}_{s}entBIGINT‘$
2) Последствия для скорости запросов
- При аналитике типовые запросы — агрегации по времени/эндпоинту/статусу. В нормализованной схеме требуется join fact → dim (по целым ключам). Если размеры dimension малы и ключи — целые, joins дешевы, но остаётся I/O: нужно сканировать факт-таблицу.
- В денормализованной схеме joins отсутствуют → меньше CPU на джоины и меньше случайных обращений к страницам, поэтому простые агрегирования обычно быстрее.
- Пример: пусть количество строк в факте за день $N=10^8$. Оценим объём данных на строку:
- нормализованная: ключи и числа ≈ $‘ts‘8байт+‘use{r}_{i}d‘4+‘endpoin{t}_{i}d‘4+‘status‘2+‘byte{s}_{s}ent‘8+накладные20$ ≈ $\approx 46$ байт/строка.
- денормализованная: добавляем строки для email/paths (средняя длина) ≈ $‘email‘64+‘path‘64$ → примерно $\approx 150$ байт/строка.
- Суммарно: нормализ. объём ≈ $N\times 46$ байт = $4.6$ ГБ (для $N=10^8$); денорм. объём ≈ $N\times 150$ байт = $15$ ГБ.
- Если дисковая/сетевая пропускная способность $T=1$ ГБ/с, простой полный скан даст время:
- нормализ.: $\frac{4.6\text{ГБ}}{1\text{ГБ/с}}=4.6\text{с}$ - денорм.: $\frac{15\text{ГБ}}{1\text{ГБ/с}}=15\text{с}$
3) Последствия для объёма хранения
- Нормализация уменьшает дублирование полей (строковые значения хранятся в одном месте в dim), поэтому сырой объём основной таблицы меньше.
- Денормализация увеличивает объём, но в колоннарных форматах (Parquet/ORC) повторяющиеся строки хорошо сжимаются: эффективность компрессии для повторяющихся строк может давать фактор сжатия $c$, поэтому эффективный объём денормализации может быть значительно меньше теоретического. Пример: если колонка `endpoint_path` имеет всего $10^3$ уникальных значений на $10^8$ строк, компрессия/строковое кодирование снизит стоимость хранения этой колонки почти до размера словаря + битных кодов.
- Итого: без учёта сжатия — денормализация ≈ $\times 3$ объёма; с хорошей компрессией — разница может упасть до $\times 1.2\text{–}1.5$.
4) Другие факторы
- Частые вставки/стриминг: нормализованная схема проще поддерживать консистентность при обновлениях dim; денормализация усложняет обновления (нужно менять много строк).
- Индексы/сортировки/партиционирование: нормализованная факт-таблица легче партиционируется по времени и индексируется по целым ключам; в колоннарных хранилищах лучше проектировать широкой денормализацией только если выгоды операций перевешивают стоимость хранения.
- Материализованные представления / предварительные агрегаты: часто лучший компромисс — хранить нормализованную факт-таблицу + набор денормализованных/материализованных таблиц для «горячих» отчётов. Это даёт баланс между экономией места и скоростью запросов.
5) Практические рекомендации
- OLAP для логов: обычно использовать звёздную модель (факт + компактные измерения с суррогатными ключами) — меньше дублирования в факте и быстрые joins по целым ключам.
- Денормализовать (или хранить кеш/материализованные агрегаты) для часто выполняемых сложных запросов/дашбордов.
- Использовать колоннарное хранилище и кодирование словаря для строковых dimension-полей — это снижает стоимость денормализации.
- Измерять: сравнивать реальные байты на диск/скорость скана/латентность для ваших N и распределений cardinality, прежде чем решать.
Короткая формула выбора: если критична скорость ad‑hoc агрегации и джойны создают узкое место → денормализация/предагрегаты; если важны хранение и гибкость при изменениях размеров — нормализация (и материализованные представления для ускорения горячих запросов).