Архитектура системы отчетов для лучшей производительности

Question

У нас есть продукт, который работает на Sql Server Express 2005 и использует в основном ASP.NET. База данных насчитывает около 200 таблиц, из которых несколько (4 или 5) могут расти от 300 до 5000 строк в день и сохранять историю 5 лет, поэтому их можно увеличить до 10 миллионов строк.
Мы создали платформу отчетности, которая позволяет клиентам создавать отчеты на основе шаблонов, полей и фильтров.
Мы сталкиваемся с проблемами производительности почти с самого начала, мы стараемся, чтобы отчеты отображались не более 10 секунд, но некоторые из них работают до 25 секунд (особенно для клиентов с большой историей).
Мы продолжаем проверять индексы и пытаемся улучшить запросы, но у нас возникает ощущение, что мы можем сделать очень много. Конечно, тот факт, что запросы генерируются динамически, не помогает в оптимизации. Мы также добавили несколько таблиц, в которых хранятся избыточные данные, но затем у нас возникла дополнительная проблема поддержания этих данных в актуальном состоянии, а также Sql Express имеет ограничение на размер баз данных.
Сейчас мы сталкиваемся с тем, что нам нужно решить, хотим ли мы отказаться от отчетов в реальном времени или, возможно, сократить историю, чтобы иметь более высокую производительность.
Я хотел бы спросить, каков рекомендуемый подход для систем такого типа.
Кроме того, мы должны начать искать сторонние инструменты / платформы? Я знаю, что OLAP может быть вариантом, но можем ли мы заставить его работать на Sql Server Express или, по крайней мере, с лицензией, достаточно дешевой для распространения в тысячах развертываний?

Спасибо

Answer 1

Выполнение запроса в подобном случае можно улучшить, поддерживая денормализованную версию вашей базы данных. SQL Express не предлагает многого в плане BI "из коробки", поэтому лучшим вариантом (в рамках ограничений SQL Express) является разработка решения вручную.

Это означает разработку денормализованной версии вашей базы данных, в которую вы экспортируете данные для составления отчетов. Имейте в виду, что денормализованные базы данных занимают гораздо больше места. Здесь - книга, посвященная проектированию хранилищ данных.

Вам также следует изучить варианты архитектуры, которые бы централизовали данные в полнофункциональной СУБД.

Answer 2

Мы сталкиваемся с проблемами производительности почти с начала

До того, как ваши столы стали большими? Это заставляет меня думать, что у вас есть основные проблемы в вашем приложении для отчетов или SQL-запросах. Это время ожидания происходит только с одним пользователем в системе?

Использовали ли вы трассировку SQL для документирования долго выполняющихся запросов и их исправления? Как вы пошли на добавление индексов?

Существует пакет OLAP с открытым исходным кодом - http://www.pentaho.com/index.php Но я не могу ручаться за его простоту использования или производительность.