Вот допустим есть у нас суровый enterprise, он занимается финансовыми транзакциями и предоставляет отчеты сотрудникам и клиентам. Тогда какой подход к архитектуре БД выбрать?

Я понимаю так. Нам нужны две базы: первая предназначена для высокоскоростных транзакций (нормализация, оптимизация для CRUD,...), в общем, OLTP, вторая — оптимизированная для сложных отчетов (денормализация, OLAP,...). Данные по транзакциям из первой переливаются во вторую.

Я прав? Кто как делает? Что можно почитать на эту тему?

Здравствуйте, TG, Вы писали:

TG>Я понимаю так. Нам нужны две базы: первая предназначена для высокоскоростных транзакций (нормализация, оптимизация для CRUD,...), в общем, OLTP, вторая — оптимизированная для сложных отчетов (денормализация, OLAP,...). Данные по транзакциям из первой переливаются во вторую.
Не совсем, это просто способ горизонтального масштабирования, когда OLTP запросов оказывается слишком много, а OLAP слишком долгими.
Если это не сильно нагруженная система все можно крутить в одной СУБД.

TG>Я прав? Кто как делает? Что можно почитать на эту тему?
Частично. Через бэкапы. В доках на используемую тобой СУБД как делается бэкап/востановление данных.

Вообще вопрос не в предназначении/оптимизации, а в том, что смешанная нагрузка создаёт дополнительные накладные расходы, которые в некоторых случаях могут быть на порядки больше раздельного выполнения.
Второй момент в том, что сложные отчеты плохо переносят меняющиеся данные. И третья особенность сложных отчетов в том, что они как правило, не требуют реалтайм данных. Вполне достаточно чего-то, к примеру на ноля часов дня. Поэтому зачастую не заворачиваются с какими-то сложными способами организации реплики, а просто из бэкапов OLTP останавливают экземпляр под OLAP. Тут и корректность бэкапов всегда проверяется, и организация второй базы требует минимум усилий, и сделать можно не один экземпляр под OLAP, а столько сколько в конкретный момент нужно.

Технически под OLAP можно использовать экземпляр Active Data Guard или Readable AlwaysOn, если они используются. Или любой иной способ репликации. Но это бывает редко, поскольку возвращает нас к проблеме смещаной нагрузки и проблемам со сложными отчетами.

Здравствуйте, m2l, Вы писали:

m2l> Поэтому зачастую не заворачиваются с какими-то сложными способами организации реплики, а просто из бэкапов OLTP останавливают экземпляр под OLAP.

Обычно/общепринято OLAP подразумевает наличие истории изменения данных, чтоб анализировать данные в разрезе времени и прочих метрик, что просто выполнением отчетов/запросов на реплике не достичь.

Реплика позволит "крутить" отчеты/анализ только на тот момент, когда "срез" данных был сделан.

Здравствуйте, m2l, Вы писали:

TG>>Я прав? Кто как делает? Что можно почитать на эту тему?
m2l>Частично. Через бэкапы. В доках на используемую тобой СУБД как делается бэкап/востановление данных.

Не подходят бекапы ибо долго.

m2l>Вообще вопрос не в предназначении/оптимизации, а в том, что смешанная нагрузка создаёт дополнительные накладные расходы, которые в некоторых случаях могут быть на порядки больше раздельного выполнения.

Какие дополнительные накладные расходы?

Я-то как раз думал, что дело в оптимизации: для быстрых транзакций используем нормализованные таблицы, а для отчетов — денормализованные. И тогда создание второй БД с помощью бекапов первой — не вариант, т.к. требуется трансформация данных.

Здравствуйте, TG, Вы писали:


TG>Я-то как раз думал, что дело в оптимизации: для быстрых транзакций используем нормализованные таблицы, а для отчетов — денормализованные. И тогда создание второй БД с помощью бекапов первой — не вариант, т.к. требуется трансформация данных.

Если надо трансформировать — то разворачивайте полноценный OLAP на базе основной базы.
На периоды наименьшей нагрузки можно запланировать нарезку срезов, создание кубов и т.п. и потом уже по готовым кубам строить OLAP отчетность.

Здравствуйте, TG, Вы писали:

TG>Я-то как раз думал, что дело в оптимизации: для быстрых транзакций используем нормализованные таблицы, а для отчетов — денормализованные. И тогда создание второй БД с помощью бекапов первой — не вариант, т.к. требуется трансформация данных.

Пляши от ситуации и требований, а не наоборот.

Например, иногда если просто надо часто и по много запускать те же самые или подобные отчеты, которые уже есть в твоей enterprise системе, то их тупо выносят на реплику/бэкап, чтоб не нагружать основную систему/базу.

Если нужно что-то более продвинутое в плане анализа данных, то тогда нужно думать об отдельной структуре данных, начиная от денормализованного варианта существующей схемы данных (как малокровный вариант), до хранилищ данных, olap структур, data lake'ов, haddop'ов всяких и прочее. В этих случаях нужно озаботится трансформацией данных при загрузки данных из основной/ых системы/м в аналитическую.