Нужно подобрать OLAP-средство, которое могло бы за приемлемое время (не более десятка секунд) работать с кубом: 30 измерений, 250 000 записей в табл фактов. Иерархия желательна. Динамическая работа - обязательна!Ктонить может подсказать продукт?

За десять секунд хотите сгенерировать куб, или чтобы каждый отчет на основе куба генерировался за 10 секунд?

Вращать куб и открывать новые измерения.

Что Вы имеете в виду под динамической работой - чтобы данные в кубе хранились как ROLAP и отчеты создавались на основе SQL-запросов, а не на основе многомерных запросов?

Я "скрываю" произвольное к-во членов произвольных измерений. Чтобы это не тормозило...

To Jurii:

А сколько записей было в табл фактов? Сколько занимала первоначальная подготовка данных? На каком сервере все крутилось?
Просто Вы, как я заметил, являетесь специалистом по Cognos ( ;-) ), а я пока разберусь...

2 Jurii

Подготовка данных - это формирование определенного OLAP-куба на основе таблицы фактов, а не их "набивка". И вопрос для меня, таким образом, остается открытым...

2 Константин Лисянский:

Спасибо за ссылку. Что касается конкретики по данной задаче, то см ниже...

2 GoodLeo:

Здесь каждый будет "рекламировать" то с чем работал.
Пусть рекламируют, я этого и добиваюсь. А по результатам рекламы я уже сам постараюсь провести сравнение :) Вот, например, Jurii прорекламировал, что системе Cognos совершенно безразлично к-во записей в таблице фактов: что 1000, что 250000. Я, конечно, понимаю, что речь идет не о сотнях миллионов записей, но все же как, вы верно заметили, чудес не бывает :)

И действительно зачем 30 (!!!!) измерений???
Нужно :) Если бы мне нужно было не 30 измерений, а, скажем, 5, я бы здесь вопрос не задавал бы, а использовал, на таких-то объемах, любой, который подошел бы мне по прочим критериям (включая цену).

И важно выбирать не только сервер но и ещё клиент.
Согласен, но это уже тема другого вопроса :)

Вопрос на самом деле стоит-то так: существует ли OLAP-сервер, который бы умел создавать любой OLAP-разрез "на лету"? Я не могу работать с заранее просчитанными данными, потому что это бессмысленно: кустомеры будут "дриллить" измерения и вращать куб, и мне неизвестно, как именно, так как основная задача:
1 - выявить взаимосвязь измерений (поэтому их так много - задача на стыке медицины и социологии, обрабатывать надо результаты тестов)
2 - выделить наиболее важные влияющие факторы, ответственные за взаимосвязь определенных групп измерений.

2 GoodLeo & Jurii:

Хотя те, кто считает свои OLAP-продукты недостаточно сильными для решения этой задачи - просто не будут о них упоминать.

2 Jurii:

Да, конечно. Именно сужения списка продуктов для сравнения я и добиваюсь.

Я думаю для 250000 записей при 30 измерениях это будет несколько минут - но это нужно проверить экспериментально.

Ок, спасибо, проверим :) Для меня сейчас важно, минуты или месяца ;-)

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

Ну это вряд-ли :) Хотя бы линейный рост "тормозов" должен наблюдаться... Кстати, подскажите пропорционально чему замедляется работа при увеличении количества измерений: логарифмически, линейно, в квадрате или экспоненциально? разумеется, я не прошу точных формул :)

Обработка 250000 записей - это не чудо, а вполне реальная задача
Да, конечно. Чудо - это одинаковое время обработки 1000 записей и 250000. Как, впрочем, и Ваше предыдущее высказывание относительно прибавления полутора десятка измерений ;-)

2 GoodLeo:

Измерений можно делать и 30 и 100, но тогда они должны быть "ровными", что бы это реально работало.

Поясните, plz. Что это за термин "ровные"?

To Jurii:

Есть некоторое фиксированные время на "разгон" в процессе генерации куба?
Чем в это время Cognos занимается? Считает аггрерации, обрабатывает элементы измерений или еще чего-то? И что это вообще за время, как его оценить?
Спасибо за развернутый ответ про измерения. Размер куба примерно 10E+50.

To GoodLeo (да и вообще всем):

MS AS "по умному" рассчитывает агрегации.
Поясните, если есть возможность... Последовательно, от меньшего уровня аггрегирования к большему, или в произвольный момент считает произвольный аггрегат, без обязательного наличия аггрегатов более низкого уровня? На этот вопрос, по-моему, может дать ответ не теория, а только чистая практика :)

To Константин Лисянский:

Кубы были довольно небольшими (150 МБайт)
Имеется в виду размер базы, на основании которой рассчитывается куб, или размер куба с просчитанными аггрегатами?

Одноуровневые иерархии ответов с очень небольшим количеством листовых элементов. Это и на Excel можно анализировать.
На Excel нельзя. Не передергивайте :)

To Jurii снова:

А как, вообще, Cognos переваривает обратную моей ситуацию: сотни миллионов записей в табл фактов и относительно небольшой (5-7 измерений) куб?

То Birkhoff:

А почему кстати вам не подходит ROLAP решение типа Business Objects или Oracle Discoverer?

Может, и подходит, я же не знаю :) У Вас былда практика использования этих продуктов для решения задач, похожих на мою (см. мои сообщения выше)?

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

To Jurii:

Правильно ли я понимаю, что это означает, что например в 20 измерениях у Вас по 100 элементов, а еще в 10 измерениях - по 10 элементов? (100^20*10^10 = 10^50)
Примерно так, только разброс несколько больше...

Закачиваются данные порциями по 5-6 миллионов записей - каждая порция - по 25 минут. Размер куба со всеми агрегатами - около гигабайта.
А время аггрегирования какое? Или аггрегирование было учтено в "25 минут"?