Аналитическая база данных и оперативная - это разные инструменты
Почему одна база данных не может хорошо делать и транзакции, и аналитику - и что с этим делать.
Когда в компании появляется первая аналитическая задача - "давайте посмотрим продажи за квартал в разрезе регионов" - её обычно решают на той же базе данных, где живёт оперативная система. Это логично: данные там есть, разработчики знают схему, делать дополнительную инфраструктуру незачем.
Через некоторое время аналитические запросы начинают тормозить, оперативная система жалуется на нагрузку, а аналитики ждут результата по нескольку минут. Первая реакция - добавить индексов или увеличить сервер. Это помогает ненадолго.
Проблема не в мощности. Проблема в том, что два класса задач устроены принципиально по-разному.
В чём разница
Оперативные системы - CRM, ERP, учётные системы - работают с отдельными записями. Добавить заказ, обновить статус, найти клиента по номеру. Запросы обрабатывают несколько строк, нужна высокая скорость ответа, важна согласованность данных в момент операции. Такие системы оптимизированы под транзакции.
Аналитические задачи устроены иначе. Посмотреть выручку по всем клиентам за год, сравнить показатели разных периодов, агрегировать миллионы строк. Запросы читают большие объёмы данных, скорость отдельной транзакции не важна, зато важна скорость обработки больших таблиц целиком.
Эти два класса нагрузки плохо совместимы на одной базе данных - особенно при росте объёмов. Оптимизация под одно ухудшает другое.
Как выглядит правильное решение
Стандартный ответ - разделить хранилища. Оперативная система остаётся на своей базе данных, оптимизированной под транзакции. Для аналитики создаётся отдельное хранилище данных, которое получает информацию из оперативных систем через процесс загрузки - и оптимизировано под большие аналитические запросы.
Это не означает немедленно покупать крупное хранилище данных. Для многих компаний на начальном этапе достаточно реплики читающей базы данных или относительно небольшого отдельного аналитического сервера. Главное - физическое разделение нагрузки.
Что это даёт с точки зрения бизнеса
Первый эффект - стабильность оперативной системы. Аналитические запросы перестают конкурировать с транзакциями. Работа с CRM не тормозит из-за того, что кто-то в это время строит отчёт за два года.
Второй эффект - свобода для аналитиков. На отдельном хранилище можно строить сложные запросы без риска положить оперативную систему. Можно хранить историю данных в нужном объёме, не ограниченном размером транзакционной базы.
Третий эффект - возможность объединять данные из разных систем. Оперативная база данных содержит только свои данные. Аналитическое хранилище может содержать данные из CRM, ERP, биллинга, внешних источников - рядом, в одном месте, в согласованном формате.
Когда пора разделять
Несколько признаков того, что пора думать об отдельном аналитическом хранилище:
- Аналитические запросы занимают минуты и мешают работе оперативной системы.
- Аналитики не могут получить данные за несколько лет - история не хранится или хранится плохо.
- Для ответа на бизнес-вопрос нужно вручную собирать данные из нескольких выгрузок.
- Разработчики боятся давать аналитикам доступ к оперативной базе - слишком рискованно.
- Объём данных растёт, и прогноз на два-три года выглядит неудобно.
Разделение хранилищ - это не архитектурный каприз. Это практический ответ на то, что разные задачи требуют разных инструментов.