2 alpamis:

В сети прочитал про Hyperion Essbase, очень понравился, правда не знаю подойдет ли она (цена/качество)

Hyperion Essbase не заточен на поддержку большого объема детальных данных. Например, мои знакомые в одной из крупнейших в мире розничных сетей используют Hyperion Essbase, и закачивают в него только агрегированные данные - порядка 90 тысяч записей в месяц (а на закачку уходит целых 3 часа), в то время как мало-мальски серьезная розничная сеть генерирует на 2-3 порядка больше детальных данных.

Думаю Вам надо выбирать между MS Analysis Services и Cognos PowerPlay. Это самые высокопроизводительные из известных OLAP-серверов. Также надо подумать над интерфейсом OLAP-клиента - очевидно что для Вашей задачи он должен уметь предоставлять удаленный доступ.

2 Сергей & alpamis:

Не забудем здесь еще SAS (работает на любых платформах) и Teradata. Которые легко побьют по производительности и функциональности MS AS.

По функциональности - возможно, но насчет производительности - сомневаюсь. У Вас есть примеры крутых тестов по производительности, где SAS или Teradata себя хорошо показали? Например, Teradata сильна как реляционная СУБД, но гарантировать средний отклик 5 секунд (в стиле MOLAP)на аналитический запрос она не может.

И еще совет. При выборе той или иной OLAP системы старайтесть не делать скоропалительных решений основываясь на красивых буклетах.

Ну это понятно. Как говорил г-н Иванов (и я полностью с ним согласен), полезно делать "пилоты" - выработать тестовое задание и реализовать его при помощи опытных специалистов с помощью разных OLAP-продуктов.
Лично я могу помочь с предоставлением демо-версии Cognos PowerPlay и с настройкой тестового примера на этом OLAP-сервере. Если интересно - пишите мне по почте на cognos@narod.ru

2 Андрей Прохоров:

У Вас есть собственный опыт работы с Teradata?
Или это результат "крутого" анализа чужих слов?

Своими руками я Терадату не тестировал. Но я из разных источников (в том числе от главного на нашем форуме эксперта по Терадате Константина Лисянского) получал информацию, что средний отклик на аналитический запрос в СУБД Терадата при серьезных объемах данных измеряется минутами, а не секундами. Масштабирование там производится хорошо, но все равно от SQL-запросов никуда не уйти, функциональности MOLAP там нет.

2 alpamis:

На AS-ку окончательно остановились, так как есть и другие задачи, которых хотим под ДБ2.
Анализаторы будут сидеть только в центральном офисе

Делал я в свое время проект для одной из гос. структур, которая собирает данные от нескольких сот тысяч юридических лиц, хранит эти данные в центральном офисе в СУБД DB2, и аналитики находятся только в центральном офисе.
Если у Вас задача сбора данных из магазинов в центральное реляционное хранилище данных уже решена или будет решаться Вашими техническими специалистами - то останется только прикрутить OLAP-сервер и настроить для него OLAP-клиента. Таким образом, минимальная стоимость решения Вашей задачи может составить трехзначную сумму в долларах (то есть XXX $, ранее на форуме обсуждались цены на OLAP-сервера и OLAP-клиенты) .

2 Сергей:

Здается мне что это фармацевтическая компания. В четверке сильнейших - Шрея, Сиа, Инвакорп, Протек.

Возможно, если это аптеки - то аптек бывает много.
Но возможно это торговая сеть торгующая продуктами питания (типа Пятерочки). Многие крупные сети супермаркетов планируют рано или поздно иметь несколько сотен супермаркетов.

Если так, прямой путь в SAS. Все фарм. компании США работают на SAS-е н.р на вскидку - Пфайзер.

Как-то мне попадалась статистика, что типа 7 крупнейших банков в мире используют Microstrategy, и при этом 9 крупнейших банков в мире используют Cognos :) То же самое можно сказать и о Pfizer:
http://www.cognos.com/company/success/pfizer.html

Вообще-то мы не в США, а в России, и в России многие известные мне фарм-дистрибьюторы из первой двадцатки используют MS AS, но есть тенденция мигрирования с MS AS на Cognos...

2 alpamis:

предполагаемые объемы данных довольно большие (может быть даже несколько десятков миллионов записей в год)

Ну значит Вы - не Пятерочка :)
Несколько десятков миллионов записей в год - это небольшой объем данных для MOLAP-сервера.

2 Виктор Сакович:

Несколько десятков миллионов записей в год - это небольшой объем данных для MOLAP-сервера.
Это довольно большой объём для MOLAP сервера

Думаю что для каждого MOLAP-сервера нужно делать отдельные выводы. Практика показывает, что для MS AS и Cognos PowerPlay это объем небольшой, для Hyperion Essbase - очень большой.

Время загрузки данных может оказаться неподъёмным.

Там где имеются большие объемы данных (например чеки в рознице), эти данные не правятся задним числом, и использование инкрементального обновления кубов позволяет подкачивать миллионы свежих записей за минуты. А если взять документы по закупкам в той же рознице, то эти документы правятся задним числом, но записей по ним на порядки меньше, чем строк чеков, и полный перепроцессинг куба занимает те же самые минуты.

Но вообще Ваша задачка больше для ROLAP. Там и времена загрузки поменьше

Зато время генерации отчетов не укладывается в среднем в 5 секунд :) На мой взгляд, важнее высокая скорость отклика на запросы пользователей, это экономит их время и позволяет оперативнее принимать управленческие решения, проводить более глубокий анализ данных. Время же загрузки не так критично, поскольку обычно загрузка производится ночью, когда пользователи спят.

и кубы - виртуальные, пресловутого молаповского врыва данных нет.

Взрыв данных не характерен для Cognos и малохарактерен для MS AS. А то что у ROLAP кубы виртуальные - это реально проблема, так как в них не просчитаны агрегаты, обеспечивающие высокую скорость отклика, и виртуальные кубы нельзя обновить инкрементально.

А вообще совет - пригласите соскателей и предложите сделать самый простой отчёт на реальных объёмах данных. Всё сразу и поймёте.

Вот это мысль здравая, я полностью с ней согласен.

2 Андрей Прохоров:

Сам я сено не косил, но советы давать могу ...

А зачем мне косить сено, если за меня его покосил Костя Лисянский? :)

2 Константин:

Уважаемый Юрий, попрошу без фамильярностей.
Если хотите, чтобы Ваши посты были удалены из этого топика, я Вам могу это устроить.

Согласен, некоторые посты стоит удалить из топика, начиная с провокационного поста про сено Андрея Прохорова :) Воспользуйтесь редакторским опытом г-на backfire.

2 Виктор Сакович:

Не знаю, не знаю. Один Ваш клиент в рознице никак с этими проблемами справиться не может и Вы помочь ему так и не смогли.

Если Вы про розничную сеть, расположенную в Санкт-Петербурге, то у нее есть определенная специфика. Там не использовался на 100% проектный подход, по причине конфиденциальности их данных солидная часть задач была возложена на их программиста, который также загружен текущими делами. И этот программист настоял на собственной методологии оптимизации аналитических моделей, которая приводит к необходимости отказаться от инкрементального обновления. Но рано или поздно мы совместными усилиями перейдем на правильную методологию :)
Тем не менее, невзирая на методологии, у них сохраняется средний отклик на аналитический запрос в пределах 5 секунд, и каких-либо реальных альтернатив OLAP-серверу Cognos PowerPlay они не видели.

2 Виктор Сакович:

Я всё-таки не очень понимаю отличия между Cognos и, скажем, Hyperion. Если есть какие-то материалы, это объясняющие, можете их бросить на мыло?

Я поищу, где то у меня были материалы по поводу крутизны MS Analysis Services по сравнению с Hyperion Essbase (подчеркиваю, именно Essbase а не Planning). А как говорится в математике, если M > H и при этом C > M, то C > H :)

2 Виктор Сакович:

Не понял. Что, Business Objects уже не считается OLAP средством?

Знатоки OLAP сходятся во мнении, что BO - это не OLAP (у него нет функциональности OLAP-сервера), а средство класса Query & Reporting.