2 Kaniovski:

Необходимо иметь возможность строить кубы на основе разных реляционных БД (Oracle и MSSQL).

Microstrategy не умеет строить кубы, это ее самый существенный недостаток, со всеми вытекающими последствиями.

Так что если Вам реально надо строить кубы - выбирайте решение среди OLAP-продуктов (кроме MS AS это Cognos PowerPlay/Cognos 8 BI, Oracle Express/10G, Hyperion Essbase).

2 Гликоген:

C другой стороны, если нравится - можно брать, по заявкам они имеют все то же, что и Cognos/Hyperion/BO

Хорошее сравнение - ROLAP с ROLAP+MOLAP... Конечно если посмотреть что все эти системы - нероссийские, позволяют делать отчеты, выгружать данные в Excel, то можно сделать вывод, что они одинаковые. Но так тупо сейчас уже мало кто выбирает систему :)

Самое слабое место Microstrategy - это, как пишут в интернете, то что г-н Сакович уволился с должности менеджера по продажам компании S & T :)

2 MSTR_Fan:

P.S. Jurii, а Вы только на удобные вопросы отвечаете теперь? ;-)

Если Вы имеете в виду что я не ответил на интересные вопросы в дискуссии "OLAP на хранилищах от разных СУБД", то я обязательно отвечу в ближайшие дни. Вопрос там довольно серьезный требует точного ответа, а на это пока времени нет...
На этом форуме я пока не встречал неудобных вопросов ;)

2 MSTR_admin:

то что г-н Сакович уволился с должности менеджера по продажам компании S & T :)
:) г-н Сакович наверно упадет со стула, когда узнает, что был менеджером по продажам

Я это не с потолка взял :) В Яндексе легко найти ссылки, например вот эту:
http://www.it-vip.ru/Person.asp?ID=3401&Display=1&First_Letter=%D1

А чтобы г-ну Саковичу было не больно падать, прошу г-на Гликогена подстелить мягкий коврик для своего коллеги :)

Юра не надо путать свою профессию с профессией специалистов :)

Я по должности - руководитель проектов, не привык что-либо путать.

Microstrategy не умеет строить кубы, это ее самый существенный недостаток, со всеми вытекающими последствиями.
почитайте обзоры - MicroStrategy уже 2,5 года является HOLAP-системой, со всеми вытекающими (мало того, что куб можно построить - вы не ограничены размером куба и в любой момент можете провести анализ за его пределы, вплоть до транзакционной информации в хранилище)

Есть мнение, что Microstrategy - это все-таки прямые SQL-запросы к реляционным хранилищам данных, то есть это не OLAP-продукт. Вы с этим не согласны? Если не согласны, приведите аргументы. То что система относится к классу HOLAP, не говорит, что у нее есть OLAP-серверная функциональность (например BO умеет делать микрокубы, но это не OLAP, это разогретый кэш). Простой тест, позволяющий определить, является ли Microstrategy OLAP-сервером, это взять текстовый файл формата CSV размером 1 гигабайт, сделать из него куб в Microstrategy, и потом подкачать инкрементально в этот куб другой текстовый файл. И после этого отчеты поверх этого OLAP-куба (типа показать динамику продаж групп товаров по месяцам) должны выполняться быстро на обычном компьютере, за доли секунды, или максимум за секунды, но не за минуты. Справится ли с этим тестом Microstrategy, или "OLAP" там устроен по-другому?

2 Kaniovski:

Из официальных источников (с официального сайта) я вычитал что MicroStrategy может не только работать с огромными массивами реляционных данных, но и создавать собственные кубы.

С огромными массивами реляционных данных работает не MSTR, а движок реляционной СУБД (Oracle, Терадата), куда MSTR передает свои SQL-запросы. То что MSTR может создавать кубы - это вопрос, на который пока никто толком не пролил свет. Что это за кубы? Реляционный кэш, микрокубы, или действительно многомерная БД?

2 MSTR_Fan:

Специализация - качественные OLAP-решения на больших реляционных хранилищах данных, то есть если "сырых" данных меньше, скажем, 30 Гб, и не требуется сложный анализ на детальном уровне - MS AS или Cognos PP гораздо более оправданное решение

30 Гб - это странная оценка... Я считаю что ее надо как минимум на порядок поднять, до терабайта (так как терабайт - это не много для Cognos). То что выше терабайта - это отдельная тема. Там уже не на последнем месте крутизна сервера РСУБД. И я полагаю, что если у нас есть ХД в котором 100 терабайт данных, на его основе можно делать OLAP-кубы для разных групп пользователей, и пользователям это будет удобнее чем делать прямые запросы и ждать часами пока сгенерируются отчеты.

По этой причине MSTR очень силен в аналитике розничных продаж

А есть ли в России примеры успешных внедрений MSTR в крупной рознице, или это все только реклама?

Куб = многомерный кэш
Если будете утверждать, что Куб обязательно должен быть MDBMS - приведите источник из классиков, а не "квадраты Гартнера" :)

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

2 Виктор Сакович и Гликоген:

Долго озирался вокруг, но, поскольку господина Гликогена не увидел, со стула решил не падать
Ответственно заявляю, что с Саковичем никогда не работал! :)

А Ваши IP-адреса говорят о том, что вы работаете в одной и той же компании-партнере Cognos :) С IP-адресом не поспоришь...

2 MSTR_admin:

менеджер по продажам == консультант по продажам
горе тех.специалисту, попавшему в вашу команду :)

Бывают консультанты по внедрению, технические консультанты, но консультанты по продажам - это то же самое что и менеджеры по продажам.

Есть мнение, что Microstrategy - это все-таки прямые SQL-запросы к реляционным хранилищам данных, то есть это не OLAP-продукт.
Это ваше мнение? тогда опустим сий бесполезный спор

Это мнение коллективное, его в свое время насколько я помню высказывал Константин Лисянский.

способен ли современный протокол передачи данных отобразить детальную информацию по 1Gb данных за время <5 секунд?
или всё таки признаем, что сказки про 5 секунд - пыль в глаза

Я не говорю что надо за 5 секунд визуализировать весь гигабайт данных, я говорил про аналитический запрос - например вывести продажи групп товаров по месяцам. С Cognos PowerPlay архитектура понятна - все агрегаты там просчитаны заранее, и они визуализируются в пределах 5 секунд. А вот MSTR будет налету обрабатывать миллионы записей SQL-запросом...

2 MSTR_*:

Да уж, много вас под серыми никами развелось на форуме :) Интересно, делали ли вы хоть один серьезный проект на MSTR, или поскольку вы продавцы/маркетологи - вам такими мелочами заниматься не положено? :)

2 MSTR_Fan:

30 Гб - это странная оценка... Я считаю что ее надо как минимум на порядок поднять, до терабайта (так как терабайт - это не много для Cognos
Я написал эту оценку потому что хорошо представляю себе возможности этих технологий. Мы здесь говорим о серьезной аналитической системе, а в такой, будь это куб или таблицы в РХД, данные хранятся на транзакционном уровне, и MOLAP, с ростом объёмов, хорош только для менеджерских агрегированных отчетов, с этим даже никто не спорит. Неужели Вы считает, что кто-либо из читающих поверит в то что кому-то в здравом уме придет в голову мысль заливать целиком многомиллиардную таблицу с CDR или чеками?

Серьезная аналитическая система должна иметь единый семантический слой, который ссылается и на реляционные таблицы, и на OLAP-кубы. Записи CDR по закону надо хранить в определенном объеме определенное время, и если потребуется - по индексу для одного телефонного номера можно посмотреть все записи без использования OLAP. Но вот например проанализировать розничные продажи без OLAP-просто нереально. OLAP-сервер позволяет например создать формулу, которая учтет каждый чек, на основе формулы можно сделать интересный аналитический разрез, и при этом не обязательно закачивать все чеки в куб (хотя пожалуй если речь идет о чеках - их стоит держать в кубе по всем магазинам за всю историю, вот все CDR можно не закачивать).

Я вообще не в курсе, а Метро, Ашан, Мигрос, Оби - они разве уже свой бизнес в России свернули? Или их размер Вас не устраивает? :-)

Согласен, это серьезная розница. Но я сомневаюсь, что например в Ашане успешно внедрена MSTR. Недавно было объявлено что Ашан выбрал BO в качестве системы репортинга, и в этом пресс-релизе был намек на то, что анализ данных в Ашане делается с помощью MS AS...

2 just_me:

И MSTR и BO поддерживают агрегат таблицы.
При этом переводят обработку запроса пользователя (переписав запрос к другим таблицам), если запрашиваемые данные находятся вне агрегат таблиц (в Вашей терминологии кубов).

Таблицы с агрегатами и OLAP-кубы - это совершенно разные вещи. Таблицы надо проектировать, поддерживать, писать и переписывать процедуры их обновления... А кубы - это более высокий уровень, где оперируют бизнес-терминами пользователей. Один куб содержит столько агрегатов, сколько не поместится и в тысяче таблиц. Спроектировать и поддерживать OLAP-куб на порядки удобнее и эффективнее, чем таблицы с агрегатами. Да и с точки зрения компактность/производительность, OLAP-куб лучше, чем таблицы...

Кэширование в MSTR и локальные микрокубы - это уже другая тема.

То есть Вы подтверждаете, что OLAP-кубы в MSTR отсутствуют, и их заменяют таблицы с агрегатами, которые создает разработчик хранилища данных?

2 MSTR_admin:

p.s.: иногда лучше жевать ... чем заниматься рукофлудием, Юра

Ну вот, видимо случай у вас не самый клинический раз Вы это поняли. А то как-то странно читать нашу переписку - у меня за спиной реальные проекты, опыт, я высказываю свое мнение, а Вы - ничего конструктивного не говорите, не обогащаете форум. Так что с нетерпением жду когда качество Ваших постингов дойдет до нормального уровня.

2 MSTR_Fan:

Ясно что Вы и близко не видели серьезных розничных или телко моделей, таких как IBM RDW, Teradata RetailDecisions, Nokia NDW

Эти модели с научной точки зрения интересны, но на практике мало применимы. Даже те кто ездит на экскурсии за границу смотреть внедрения этих моделей, приезжает оттуда не в восторге...

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

Вы не читали этот пресс-релиз на сайте компании Терн?

Мне очень странно такое Ваше неприятие MSTR. Вас разве сильно обидели? Право слово, ну подвинули Вас в нескольких тендерах, ну разве это повод так врать в публичном месте?

Я не имею ничего против MSTR. Просто меня удивляет, что есть много фанатов MSTR, которые не рассказывают о реальных проектах, обходятся общими словами, засоряют форум... И в интернете про MSTR ничего кроме рекламы не увидишь - ни одного описанного проекта в России...

Кроме того, я уверен что все высказывавшиеся в этом топике люди работают в команиях, партнерах Вашего любимого вендора, а кое-кто даже внедрял его ;-)

А Вы интересно где работаете? :)

Советую завязывать с грязью в сторону MSTR и BO, а то окончательно прослывете клоуном, да и Cognos не лучшую репутацию сделаете.

Хороший аргумент в защиту MSTR и BO :)