Добрый день,

Есть вопрос по поводу производительности отчетов: какой из способов разделения кубов - логическое (на основе мультикуба) или физическое (на уровне СУБД) обеспечивает большую производительность выполнения отчетов?
Кто - нибудь сталкивался с подобной ситуацией?

Мое мнение используя мультипровайдер однозначно теряешь в производительности, используй куб с агрегатами, отчеты построенные на инфосете будут работать еще медленнее, если используется БД ORACLE - это только плюс, в ней происходит партишионирование на уровне БД

Ждите BW 7.2 - там можно делать физическое партицирование по любым признакам, а не только временным. Будет т.н. Semantic Partitioned Object (SPO)

Спасибо большое. В теории разделение на уровне СУБД должно быть производительней. Я согласен. Но практически никто не проверял это? Насколько быстрее?

А какое из способов используется чаще на практике? В связи с чем?

На практике используются мультикубы. Суть такая - параллельный доступ нескольких процессов сервера приложений к одной базе данных. Но тут тоже есть ограничение... эвристически больше 10-12 кубов лучше не соединять. Насколько быстрее никто точно не скажет, потому что тут от структуры отчета (запроса) зависит многое и от ограничений на признаках, а также от настроек системы и железа. Данный способ проще, чем физическое партицирование (нет необходимости знать ничего о количестве дисков, их ресурсах, не надо разбираться в способах партицирования). При большом количестве пользователей, работающих одновременно, разница в производительности не велика (слишком много ресурсов потребляется, даже вероятна потеря производительности), при малом количестве пользователей можно выиграть от 10 до 50% в среднем (колдовство админов). Физическое партицирование работает хорошо только тогда, когда изначально планируется железо под определенный софт, написанный специально для этой самой архитектуры железа.

Вопрос на самом деле комплексный и однозначного ответа здесь нет. Все зависит от условий проекта.
DW здесь необходимо учитывать не только уровень DB, но и уровень OLAP, Frontend. То есть какая у вас модель данных, как определены запросы, как часто они запускаются, используете ли вы агрегаты или нет, компрессию и индексы, статистика БД и ее параметры, виртуальные признаки и показатели, скорость соединения, и т.д. Еще ведь нужно все это добро сопровождать, архивировать! Следить за тем, чтобы все это добро работало. ОТчеты были, точные, релевантные и адекватные и точно вовремя. ETL это вообще целая история. В общем два подхода существуют вместе.