Аналитическая база данных против операционной: когда их нужно разделять
Почему одна база данных не может хорошо обслуживать и транзакции, и аналитику - и как понять, что настало время разделить их.
Когда компания только начинает собирать данные, одна база данных выглядит разумным выбором. Вся информация в одном месте, запросы строить просто, ничего лишнего. Это работает, пока компания небольшая.
Потом начинается интересное. Аналитики запускают тяжёлые отчёты прямо в рабочей базе - и это замедляет основное приложение. Или наоборот: транзакционная нагрузка не даёт построить нормальный отчёт, потому что пока запрос выполняется, данные уже изменились.
Это не проблема конкретной базы данных и не ошибка архитектора. Это фундаментальное противоречие между двумя разными задачами.
Зачем операционной базе одно, а аналитической другое
Операционная база данных (OLTP - Online Transaction Processing) оптимизирована для быстрых операций чтения и записи: добавить заказ, обновить остаток, записать платёж. Тысячи коротких транзакций в секунду. Критически важна скорость отдельной операции.
Аналитическая база данных (OLAP - Online Analytical Processing) оптимизирована для другого: просканировать миллионы строк, агрегировать, сравнить периоды, найти паттерны. Меньше транзакций, но каждая работает с большими объёмами данных. Критично время выполнения сложного запроса.
Эти задачи оптимизируются противоположными методами. Операционная база хранит данные построчно - быстро обновлять отдельные записи. Аналитическая хранит по столбцам - быстро агрегировать один атрибут по всем строкам. Один инструмент не может быть одновременно хорош в обоих режимах.
Когда это начинает причинять боль
Признаки того, что разделение необходимо:
Аналитические запросы замедляют основное приложение. Это первый симптом - можно попробовать оптимизировать, но стратегически проблема останется.
Отчёты строятся на устаревших данных. Чтобы не нагружать операционную базу, аналитики работают с ночными выгрузками - и видят вчерашнюю картину.
Аналитики боятся сломать что-то своими запросами. Это уже культурная проблема, которая говорит о том, что архитектура не даёт команде работать нормально.
Невозможно хранить историю изменений. Операционная база хранит текущее состояние. Для аналитики нужна история: как изменился показатель, что было месяц назад, где тренд.
Что происходит при разделении
Разделение предполагает наличие двух слоёв с разными задачами.
Операционная база работает как прежде - транзакции, актуальные данные, высокая скорость записи.
Аналитический слой (DWH, data mart или cloud аналитическая база) получает данные из операционной регулярно - через ETL-процессы. Он оптимизирован для чтения, хранит историю, позволяет строить сложные запросы без риска для основного приложения.
Промежуточный вопрос, который часто возникает: нужны ли данные в реальном времени или достаточно ночной синхронизации? Для большинства управленческой отчётности - достаточно. Для операционных дашбордов - нужно думать отдельно.
Практический тест
Задайте своей команде несколько вопросов:
- Влияют ли аналитические запросы на скорость работы основного приложения?
- Насколько свежие данные используются в управленческой отчётности - и устраивает ли вас это?
- Можно ли восстановить историческое состояние данных на конкретную дату?
- Могут ли аналитики работать независимо, не договариваясь с командой разработки о каждом запросе?
Если ответы на эти вопросы вас не устраивают - разделение операционного и аналитического слоёв стоит рассмотреть как архитектурный приоритет на ближайший год.