Для чего нужна денормализация БД?

Денормализация БД: цели и применение

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

Основные цели денормализации

1. Повышение производительности запросов

Основная причина денормализации. Нормализованные таблицы требуют множественных JOIN операций, которые замедляют выполнение запросов. Денормализация позволяет получить нужные данные за один запрос:

-- Нормализованный подход (требует JOIN)
SELECT o.id, o.date, c.name, c.email
FROM orders o
JOIN customers c ON o.customer_id = c.id;

-- Денормализованный подход (одна таблица)
SELECT id, date, customer_name, customer_email
FROM orders;

2. Снижение сложности запросов

Упрощение логики приложения за счёт хранения готовых данных вместо их вычисления на лету:

• Хранение агрегатов (количество заказов, сумма, среднее значение)
• Кэширование результатов сложных вычислений
• Предвычисленные значения для часто используемых метрик

3. Оптимизация для чтения (Read-Heavy сценарии)

В системах, где чтение намного превышает запись (например, аналитические системы, BI, отчёты), денормализация критична для скорости.

4. Снижение нагрузки на приложение

Чем меньше логики в приложении для получения и агрегирования данных, тем проще поддерживать код и ниже вероятность ошибок.

Примеры денормализации

Пример 1: Копирование атрибутов

-- Нормализованная схема
users (id, name, email)
orders (id, user_id, total_price)

-- Денормализованная схема
orders (id, user_id, user_name, user_email, total_price)

Пример 2: Предвычисленные агреваты

-- Вместо подсчёта COUNT каждый раз
CREATE TABLE orders_summary (
  user_id INT,
  order_count INT,
  total_spent DECIMAL,
  last_order_date DATE
);

Пример 3: Хранение истории

-- Вместо JOIN с историческими данными
CREATE TABLE product_prices (
  product_id INT,
  current_price DECIMAL,
  price_history JSONB  -- хранение всех исторических цен
);

Когда использовать денормализацию

• OLAP системы (Online Analytical Processing) — хранилища данных, витрины
• Высоконагруженные read-heavy системы — соцсети, новостные ленты
• Real-time аналитика — дашборды, метрики
• Микросервисы — локальные копии данных других сервисов
• NoSQL БД — MongoDB, Firestore предполагают денормализацию

Когда НЕ использовать денормализацию

• OLTP системы (Online Transaction Processing) с частыми INSERT/UPDATE
• Ограниченное хранилище — каждый байт на счету
• Требуется консистентность — высокие требования к актуальности данных
• Простые запросы — когда JOIN не критичен

Проблемы и риски денормализации

1. Проблема синхронизации (Data Anomalies)

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

-- Если поменялось имя пользователя, нужно обновить везде
UPDATE users SET name = John WHERE id = 1;
UPDATE orders SET user_name = John WHERE user_id = 1;
UPDATE invoices SET user_name = John WHERE user_id = 1;

2. Увеличение объёма данных

Дублирование ведёт к растущему использованию диска и памяти.

3. Усложнение логики обновления

Требуется тщательное управление триггерами и процедурами обновления.

4. Нарушение нормализации

Легко внести аномалии при обновлениях.

Стратегии управления денормализацией

1. Триггеры и хранимые процедуры

CREATE TRIGGER update_order_customer_name
AFTER UPDATE ON users
FOR EACH ROW
UPDATE orders SET user_name = NEW.name WHERE user_id = NEW.id;

2. Materialized Views

CREATE MATERIALIZED VIEW user_orders_summary AS
SELECT u.id, u.name, COUNT(o.id) as order_count
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
GROUP BY u.id;

3. Event-driven обновления

Использование очередей сообщений (Kafka, RabbitMQ) для асинхронной синхронизации денормализованных данных между сервисами.

4. Кэширование уровня приложения

Redis, Memcached для хранения вычисленных значений с TTL.

Заключение

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