Денормализация данных: когда и зачем нарушать правилаДенормализация — это намеренное введение избыточности данных в таблице. Звучит как ересь, не так ли? Мы же так долго их номрализовывали! Однако, в мире больших данных и высоких нагрузок этот подход имеет место быть.
Часто нормализацию сознательно нарушают для повышения производительности системы, так как большое количество JOIN приводит к медленному выполнению запросов. Таким образом денормализация становится необходимой для ускорения доступа к данным и оптимизации запросов. Она ускоряет чтение данных, что особенно важно для построения дашбордов.
Когда применять денормализацию?🔵Есть часто выполняемые сложные запросы с множеством соединений — денормализация может значительно ускорить их выполнение за счёт хранения предварительно агрегированных данных в одной таблице.
🔵Для систем бизнес-аналитики (BI) и хранилищ данных денормализация — обычная практика. Она позволяет быстрее выполнять сложные расчеты и агрегации.
🔵В распределенных базах данных JOIN-ы между таблицами, хранящимися на разных узлах, могут быть очень дорогостоящими. Денормализация помогает избежать этих сложных операций.
Давайте рассмотрим пример. Представим, у нас есть интернет-магазин с миллионами заказов. В нормализованной схеме информация о заказе, клиенте и товарах хранится в разных таблицах:
orders:
| order_id | customer_id | order_date |
|----------|-------------|------------|
| 1 | 101 | 2024-09-01 |
customers:
| customer_id | name | email |
|-------------|-------|----------------|
| 101 | Алиса | alice@email.ru |
order_items:
| order_id | product_id | quantity |
|----------|------------|----------|
| 1 | 201 | 2 |
products:
| product_id | name | price |
|------------|----------|-------|
| 201 | Ноутбук | 50000 |
Для получения полной информации о заказе нам приходится объединять все эти таблицы:
SELECT
o.order_id,
c.name AS customer_name,
c.email AS customer_email,
p.name AS product_name,
oi.quantity,
p.price,
oi.quantity * p.price AS total_price,
o.order_date
FROM orders o
JOIN customers c ON o.customer_id = c.customer_id
JOIN order_items oi ON o.order_id = oi.order_id
JOIN products p ON oi.product_id = p.product_id
WHERE c.name = 'Алиса';
При высокой нагрузке это может стать узким местом. В денормализованной версии мы можем хранить все нужные нам столбцы и расчёты (н-р, order_id, customer_name, customer_email, product_name, quantity, price, total_price, order_date). Когда вся информация доступна в одной таблице, это значительно ускоряет запросы на чтение:
SELECT
order_id,
customer_name,
customer_email,
product_name,
quantity,
price,
total_price,
order_date
FROM orders o
WHERE customer_name = 'Алиса';
Важно понимать и помнить, что у этого подхода есть и свои
минусы:
🔵Избыточность данных: мы храним одну и ту же информацию в нескольких местах, что увеличивает объем хранилища.
🔵 Сложность обновления: при изменении данных (например, имени клиента) нужно обновлять информацию во всех связанных записях.
🔵Риск несогласованности: если обновление происходит не атомарно, может возникнуть ситуация, когда данные в разных местах не соответствуют друг другу.
Чтобы минимизировать эти риски, можно использовать различные техники. Например,
материализованные представления позволяют создавать денормализованные таблицы, которые автоматически обновляются при изменении исходных данных.
В конечном счете, выбор между нормализацией и денормализацией зависит от конкретных требований вашей бизнес-задачи. Главное — понимать последствия своего выбора и быть готовым вносить изменения по мере роста и изменения системы.
А вы сталкивались с необходимостью денормализации в своих проектах? Какие подходы использовали для поддержания согласованности данных?
#dwh
