Проблема, Существующие решения, Денормализация - Программа расчета агрегатов по накапливающимся данным для построения отчетов

пример сложной схемы бд

Рисунок 1. Пример сложной схемы БД

Пример проблемной ситуации, которую этот проект должен разрешить представлен на рис. 1.

Организатор проводит события со сложной ценовой политикой (несколько разных типов билетов -- EventRegistration). События группируются в категории. Партнеры проводят кампании по продвижению событий в обмен на комиссии. Пользователи размещают заказы, в которые может входить несколько билетов разных типов. Пользователи могут приходить сами, а могут перейти с одной из кампаний по продвижению.

Запрос, подсчитывающий доход партнера от определенной организации вынужден будет объединить JOINом почти все таблицы между Organization и Partner. Его сложность составит примерно, где N -- количества рядов в таблицах. А ведь актуальное значение этой величины партнер желает видеть в карточке организации.

Существующие решения
Денормализация
пример использования денормализации

Рисунок 2. Пример использования денормализации

Денормализация проводится с целью оптимизировать производительность операций чтения из базы данных путем хранения избыточных, дублирующих данных или группировки данных [7]. Например, если в таблице Order хранить ключи (id) Organization и Event, то уже не придется загружать из базы данных Ticket и Event, чтобы найти заказы для определенной организации. Таким образом, добавляя избыточные связи разработчик может значительно сократить цепочку JOINов, однако у этого подхода есть несколько ограничений и слабых сторон.

Ограничения:

    - Отношения "один ко многим" можно "пропустить" таким образом только в одном направлении (от многих к одному), потому что хранение список всех ссылающихся на данный элементов не даст никакого выигрыша, лишь потратив дисковое пространство - Отношения "многие ко многим" вообще нельзя исключить из цепочки JOINов таким образом, потому что они по сути являются двумя "один ко многим" связями - Появление новой прямой связи накладывает дополнительное ограничение. Так, например, в изначальной схеме возможность включить в заказ билеты на несколько событий не исключена. Если же в заказе хранить указатель на событие, то возникнет явное ограничение -- в заказе могут быть билеты лишь на одно событие.

Слабые стороны:

    - Денормализация дает прирост в производительности на чтение в обмен на серьезное усложнение схемы. Усложнение схемы усложнит разработку, особенно при недостаточной документации. Не всегда очевидно, какое значение первично, а какое -- дубликат. [1] - Разработчик ответственен за целостность данных. Дубликаты необходимо должны обновляться вместе с оригиналами.

На рисунке 2 изображена сильно денормализованная схема с рисунка 1. Эта схема иллюстрирует все вышеописанное.

Прошлый пример с получением прибыли партнера с организации теперь имеет сложность O(N). Однако все упомянутые недостатки также хорошо видны. К тому же, если потребуется добавить какие-либо условия на таблицы, исключенные из JOINа, то весь выигрыш будет утерян. Например, если партнера будет интересовать прибыль только с событий определенного месяца. Самый худший, но вполне реальный случай -- если партнера заинтересуют события из определенной категории. Даже оптимистичное O(N) -- это full table scan, то есть все равно медленно.

Таким образом, повышая производительность, денормализация угрожает архитектуре, не решая полностью проблему масштабирования.

Дополнительная проблема -- денормализация действующей базы данных. Для этого потребуется не только миграция схемы, но еще и дополнительный код, который заполнит новые столбцы данными. Такой код нелегко писать и тестировать, что создает высокий риск длительного даунтайма. К тому же сам процесс изменения структуры таблицы может занимать огромное количество времени на многих СУБД. Добавление или удаление стоблца для таблицы с 6 миллионами строк может занять несколько часов, в течение которых таблица будет находиться в режиме "только чтение", потому что СУБД попросту создает новую таблицу и копирует в нее все данные из старой.

Если схема не была разумно денормализована до внедрения проекта (а так часто случается в стартапах), каждая операция по денормализации будет крайне нетривиальной, а доведение схемы до оптимального состояния может потребовать неопределенное количество шагов.

Похожие статьи




Проблема, Существующие решения, Денормализация - Программа расчета агрегатов по накапливающимся данным для построения отчетов

Предыдущая | Следующая