Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Всем привет! Тема наверняка интересная для многих. Есть несколько СУБД (Oracle и MS SQL). Необходимо найти OLAP решение которое может бать основано на хранилищах или той или другой СУБД. Идеально чтобы поддерживались и другие известные СУБД, но это необязательно. Есть сторонние производители предоставляющие такие возможности. Они создают свой промежуточный уровень хранилища данных которое может заполнятся из разных СУБД. Ребята, кто в курсе, посоветуйте решения. Буду очень признателен! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 11:35 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Возможно есть решения на основе продукции компании Crystal? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 11:46 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
А в чем собственно проблема? У нас OLTP и DWH на Oracle, а MOLAP на MS AS 2005 - все работает без каких-либо проблем. В принципе никто не мешает использовать и такой вариант: OLTP - Oracle, DWH - MS SQL Server, OLAP - MS AS. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 11:50 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Вообщем так. Готовится ПО для нескольких компаний. Какой именно СУБД каждая из них будет пользоваться приблизительно ясно (Oracle и MSSQL). Разрабатывать параллельно OLAP решения и на то и на другое слишком замороченно. К тому же те кто работает на MSSQL не захотят ставить что-то из Oracle и наоборот. Хочется найти общее решение которое и будем дальше поддерживать. перекачивать хранилища из одной СУБД в другую проблем не составляет, а вот переделывать параллельно несколько разных кубов это уже расточительно. Вот я и ищу решение не основанное на конкретном СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 12:32 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Просто как вариант - СУБД - любая, хранилище и OLAP - MS. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 12:34 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
По поводу хранилища и самого OLPA на MS AS это вариант известный, но хотелось бы иметь в рассмотрении еще несколько вариантов. А что скажите по поводу Business Objects? Просто я никогда сам не видел этот продукт, но по описанию она может справиться с этой проблемой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 12:48 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Kaniovskiно по описанию она может справиться с этой проблемой. если читать описания продуктов, то все продукты все могут, да только реалии далеки от мануала. Если хотите объектива - ищете того, кто своим горбом сопровождал и не клюйте на сладкие речи сейлов / консалтеров - Геббельсу и отделу пропаганды ЦК до них далеко. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 12:56 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Это означает что Business Objects не способен создавать свое хранилище или подключаться к нужному и создавать свои кубы? Хотелось бы просто услышать описание от людей которые сталкивались с этой зверюгой лично ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 13:01 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
А почему интересует именно BO? Какие критерии выбора данного решения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 13:13 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Признаться честно я пока не выбрал BO а просто интересуюсь что он может. Пока мои знания ограничиваются MS AS. Но так как СУБД могут быть разные хочется универсального решения ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 13:46 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
у BO есть продукт Data Integrator - он этим и занимается (развертывание, развитие и поддержка хранилищ на всяких СУБД) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 13:50 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
BO сам по себе не имеет OLAP-продукта, микрокубы не в счет. Должен использоваться сторонний OLAP-сервер. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 13:52 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Так что, если я правильно понял, в BO нет своего хранилища? То есть он просто подцепляет и хранилище из внешнего СУБД и сами кубы от туда же?!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 13:57 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
KaniovskiНо так как СУБД могут быть разные хочется универсального решения А чем MS не универсальное решение? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 13:58 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
да меня устраивает MS AS всем, кроме некоторых моментов. У нее нет простого своего клиента. Никак не получается отфильтровать данные по исходной информации, то есть по инф. в самом хранилище. Нужно сделать возможность любой фильтрации (динамической) по исходным данным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 14:05 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
А чем Excel Вам не нравится. Нормальный клиент. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 14:13 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
KaniovskiТак что, если я правильно понял, в BO нет своего хранилища? То есть он просто подцепляет и хранилище из внешнего СУБД и сами кубы от туда же?!! В BusinessObjects XI есть OLAP Intelligence - универсальный клиент для OLAP-серверов. Я так понял, что это переделанный OLAP-клиент компании Crystal. Своего OLAP сервера нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 14:19 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
так вот в этом и беда, что своего OLAP сервера там нет. То есть получается что при любом раскладе BO будет работать значительно медленнее чем OLAP сервер. А вот еще вопросик - а какие-нибудь предварительные вычисления BO делает? ну типа как processing cube OLAP? Или BO всегда стучится в реляционное хранилище? Агрегаты он подсчитывает или нет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 14:43 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
2 Kaniovski: да меня устраивает MS AS всем, кроме некоторых моментов. У нее нет простого своего клиента. Никак не получается отфильтровать данные по исходной информации, то есть по инф. в самом хранилище. Нужно сделать возможность любой фильтрации (динамической) по исходным данным. Думаю что Вам стоит изучить возможности аналитической системы Cognos. У Cognos есть модуль класса Query & Reporting, который позволяет на основе семантического слоя метаданных делать сложные запросы к реляционным ХД, производить вычисления, и все это заливать в OLAP-куб. Соответственно, чтобы спроектировать сложный и содержательный OLAP-куб, не требуется как в MS AS писать вьюшки на SQL и вычисляемые объекты на MDX... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 20:03 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Kaniovskiтак вот в этом и беда, что своего OLAP сервера там нет. То есть получается что при любом раскладе BO будет работать значительно медленнее чем OLAP сервер. А вот еще вопросик - а какие-нибудь предварительные вычисления BO делает? ну типа как processing cube OLAP? Или BO всегда стучится в реляционное хранилище? Агрегаты он подсчитывает или нет? говоря "приземленно" - в ВО ты создаешь Юниверс - своего рода картинку всех связей БД (можешь использовать любой сервер БД и любую базу, хоть OLAP, хоть OLTP, лишь бы ты в ее структуре разбирался. Вопрос будет только в конечном быстродействии). В Юниверсе ты также создаешь набор полей, которые будут доступны пользователю в отчете. В результате пользователи видят только предназначенный для них набор полей, "бросают в отчет" нужные поля/условия/т.п. (но все эти поля и условия предварительно задаются тобой в Юниверсе). После этого пользователи запускают свой отчет. По набору выбранных пользователем полей и структуре составленного тобой Юниверса ВО генерирует SQL-запрос к БД, который и отрабатывает при запуске отчета. (Если в Юниверсе были агрегаты, то они конечно же подсчитываются и т.п....) Потом все данные запроса возвращаются в ВО и сохраняются там... Из запрошенных тобой полей в отчет ты можешь выводить только часть, при этом отработают всякие агрегатные функции, которые ты задал (т.е. группировка, суммирование, среднее и т.п.). На основе полученных данных можешь строить графики, сводные таблицы, "плоские" таблицы и т.п. Время, которое тратится - это время на отработку запроса к СУБД (тут уже твоя задача оптимизировать БД и Юниверс так, чтобы уменьшить это время), время на перекачку/сохранение запрошенных данных на клиенте, время на обработку данных на клиенте (это уже зависит от сложности отчета и объема "сырой" информации). Хотя можно все это сделать через браузер и web-доступ - тогда клиент будет почти отдыхать... В целом штука довольно удобная (в основном для пользователя), хотя за всякое удобство приходится платить (в основном админам). :) Будут еще вопросы - спрашивай. Если смогу, отвечу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 09:09 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Спасибо за ответ. Хотелось бы еще одну вещь уточнить - насколько решение на основе OLAP будет работать быстрее решения через BO если будут выводиться одинаковые данные? Время перестройки OLAP кубов в расчет брать не будем. Только прямые запросы к базам ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 12:38 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
2Kaniovski Ну опять же.... Если Вы используете BO OLAPi, то этот клиент направляет запросы непосредственно на сервер OLAP (например, MSAS 2000). И скорость работы в данном случае сравнима, например, с Excel. Ну... может и повыше. С другой стороны, Вы можете написать самостоятельно MDX запрос в BO OLAPi и его скорость может быть намного больше. Universe можно строить как поверх OLAP-сервера, так и поверх OLTP. Ну и скорости соотвествующие, соотвествующие способы оптимизации. Мы пробовали использовать в юниверсах MSAS 2000, к сожалению, BO кривовато поддерживает его, и далеко не вся функциональность reporting'a работает правильно (если работает вообще). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 12:59 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
KaniovskiСпасибо за ответ. Хотелось бы еще одну вещь уточнить - насколько решение на основе OLAP будет работать быстрее решения через BO если будут выводиться одинаковые данные? Время перестройки OLAP кубов в расчет брать не будем. Только прямые запросы к базам Могу только присоединиться к AAron-у. И повторить, что ВО - это по большому счету только СПОСОБ получения данных. Да - мощный, да - продвинутый, да - масштабируемый, "относительно красивый внешне" и т.п., но всего лишь СПОСОБ. Он генерирует SQL запрос и получает данные. А уже скорость работы запроса будет определяться СУГУБО скоростью работы СУБД/архитектурой Юниверса/мощностью сервера/пропускной способностью сети.... И еще у ВО есть одно достоинство - он "user-friendly". Т.е. конечный пользователь может ничего не знать ни о базе, ни о SQL-е... - и при этом иметь возможность получать нужные ему данные :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 13:13 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
...........И еще у ВО есть одно достоинство - он "user-friendly". Т.е. конечный пользователь может ничего не знать ни о базе, ни о SQL-е... - и при этом иметь возможность получать нужные ему данные :) А где скачать демо можно чтобы посмотреть на него? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 13:23 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Да, демку было бы очень неплохо заиметь. А еще лучше к ней вдобавок и какое-нибудь описание для первичного ознакомления ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 13:36 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
2 Kaniovski: насколько решение на основе OLAP будет работать быстрее решения через BO если будут выводиться одинаковые данные? Можно сказать, что среднее время генерации отчетов на основе OLAP - не более 5 секунд (если реально используется OLAP). А время генерации отчета на основе прямых запросов зависит от многих факторов - объемы данных, сложность запроса, индексированность БД и т.д. Если под каждый отчет BO делать таблицу с агрегатами - тогда скорость будет хорошая (тяжело правда под каждый отчет изменять структуру ХД). Если использовать MS AS - то тоже скорость хорошая, однако по мнению г-на AAron этот подход фактически нельзя использовать ( BO кривовато поддерживает его, и далеко не вся функциональность reporting'a работает правильно (если работает вообще). ) 2 ......... : Могу только присоединиться к AAron-у. И повторить, что ВО - это по большому счету только СПОСОБ получения данных. Да - мощный, да - продвинутый, да - масштабируемый, "относительно красивый внешне" и т.п., но всего лишь СПОСОБ. Он генерирует SQL запрос и получает данные. А уже скорость работы запроса будет определяться СУГУБО скоростью работы СУБД/архитектурой Юниверса/мощностью сервера/пропускной способностью сети.... И еще у ВО есть одно достоинство - он "user-friendly". Т.е. конечный пользователь может ничего не знать ни о базе, ни о SQL-е... - и при этом иметь возможность получать нужные ему данные :) Блин, сомнительно для меня что BO - user-friendly... Из реальных внедрений о которых мне известно - все отчеты на BO делают профессиональные ИТ-специалисты а пользователи запускают только стандартные отчеты. Сами посудите, у BO нет возможности вставлять в отчет строки, для этого надо делать юнион на уровне таблиц хранилища данных, непредсказуемо время отклика на запрос пользователя - если пользователь сделает сложный вычисляемый показатель, то результат будет не за 5 секунд, а неизвестно когда... А что касается стандартной отчетности, то в BO все более-менее OK, поэтому в мировых рейтингах он не так много проигрывает системе Cognos :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 14:27 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
ребята, а кто в курсе BO или Cognos способны выводить информацию из OLAP накладывая фильтрацию на первичные данные, то есть данные из самого хранилища? Например у меня есть желание получить отчет за год по месяцам за все продажи суммы каждой из которых находятся в нужном мне диапазоне. Эти диапазоны могут быть любыми для каждого отчета. И если такая возможность имеется, то насколько дольше он будет считаться? как вообще это будет происходить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 14:44 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Jurii А что касается стандартной отчетности, то в BO все более-менее OK, поэтому в мировых рейтингах он не так много проигрывает системе Cognos :) Ссылочку на независимый источник, если не трудно.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 14:47 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
JuriiБлин, сомнительно для меня что BO - user-friendly... Из реальных внедрений о которых мне известно - все отчеты на BO делают профессиональные ИТ-специалисты а пользователи запускают только стандартные отчеты. Сами посудите, у BO нет возможности вставлять в отчет строки, для этого надо делать юнион на уровне таблиц хранилища данных, непредсказуемо время отклика на запрос пользователя - если пользователь сделает сложный вычисляемый показатель, то результат будет не за 5 секунд, а неизвестно когда... А что касается стандартной отчетности, то в BO все более-менее OK, поэтому в мировых рейтингах он не так много проигрывает системе Cognos :) Если бы Вы только знали, насколько "профессиональные", насколько "ИТ" и насколько "специалисты" у нас эти отчеты ваяют!!!!! ;))))))))))))))) Иногда группа ученых обезьян умнее. Но самое удивительное, что даже несмотря на это нужные им данные они получают!!! Пусть иногда долго и временами криво, но получают. Профессиональные ИТ-специалисты должны разрабатывать базу, к которой БО обращается. И строить Юниверс в БО, через который это обращение идет. А сам продукт на уровне пользователя достаточно прост. Вставлять строку? не спорю.... вот только при обработке ста тысяч строк от одной "дополнительной" Вам толку скорее всего не будет... А вообще можете сохранить отчет в Excel - и уже форматировать там. Может, это не настолько удобно и "не красиво", но в конце концов работает... И ответа на сверсложное вычисление через 5 секунд и на терабайтной базе ждать глуповато, Вы не находите? ;) Если кому-то нужна ссылка и тестовая версия - поищите в Яндексе... ВО в России представляют несколько фирм (может, и на тестирование взять удастся), но не хочу давать их названий, дабы не засорять ветку постоянной рекламой (уж извините, но камень в огорот Когноса ;) ). Из описаний могу разве что своим мнением поделиться... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 15:04 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Поделитесь! Что именно в Cognos вас не устраивает? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 15:10 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
KaniovskiПоделитесь! Что именно в Cognos вас не устраивает? Вы уж извините, но про Когнос ВООБЩЕ сказать ничего не смогу - не работал с ним. (Конкретно на этом сайте меня слегка веселят постоянные попытки Когнос прорекламировать - хотя я и понимаю, что человек торгует продуктом, это его работа...) Могу поделиться только опытом работы с ВО. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 15:27 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Отлично!!! Поделитесь опятом работы с BO. Я еще не определился что лучше. Повторю свой вопрос... BO способны выводить информацию из OLAP накладывая фильтрацию на первичные данные, то есть данные из самого хранилища? Например у меня есть желание получить отчет за год по месяцам за все продажи суммы каждой из которых находятся в нужном мне диапазоне. Эти диапазоны могут быть любыми для каждого отчета. И если такая возможность имеется, то насколько дольше он будет считаться? как вообще это будет происходить? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 15:32 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
KaniovskiОтлично!!! Поделитесь опятом работы с BO. Я еще не определился что лучше. Повторю свой вопрос... BO способны выводить информацию из OLAP накладывая фильтрацию на первичные данные, то есть данные из самого хранилища? Например у меня есть желание получить отчет за год по месяцам за все продажи суммы каждой из которых находятся в нужном мне диапазоне. Эти диапазоны могут быть любыми для каждого отчета. И если такая возможность имеется, то насколько дольше он будет считаться? как вообще это будет происходить? В почте ответ поищите. Извините, но почту я просматриваю чаще, чем сайт - поэтому отвечу быстрее, если что.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 15:53 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
2 Kaniovski: ребята, а кто в курсе BO или Cognos способны выводить информацию из OLAP накладывая фильтрацию на первичные данные, то есть данные из самого хранилища? Например у меня есть желание получить отчет за год по месяцам за все продажи суммы каждой из которых находятся в нужном мне диапазоне. Эти диапазоны могут быть любыми для каждого отчета. И если такая возможность имеется, то насколько дольше он будет считаться? как вообще это будет происходить? Как я понимаю, на практике BO не выводит информацию из OLAP (если верить г-ну AAron). Что касается Cognos, то есть следующий подход: при проектировании OLAP-куба сделать вычисляемое измерение, элементы которого будут отображать Ваши диапазоны, причем надо сделать много маленьких диапазончиков (с шагом 1 доллар). Тогда в отчете Cognos Вы легко сможете отфильтровать данные по любому диапазону, сложив его из маленьких диапазончиков. Понятна ли идея? В этом подходе плюсом является то, что не пострадает производительность, так как фундаментом служит OLAP. 2 Bormoglot: А что касается стандартной отчетности, то в BO все более-менее OK, поэтому в мировых рейтингах он не так много проигрывает системе Cognos :) Ссылочку на независимый источник, если не трудно.... Вот например ссылка на отчет Gartner, где Cognos признан лучшей в мире аналитической платформой: http://mediaproducts.gartner.com/reprints/cognos/vol2/article2/article2.html 2 ......... : Если бы Вы только знали, насколько "профессиональные", насколько "ИТ" и насколько "специалисты" у нас эти отчеты ваяют!!!!! Можете ли привести название Вашей компании? Например если Вы из компании Терн и Ваши маркетологи анализируют Вашу клиентскую базу, то это не терабайтные, и даже не гигабайтные объемы данных... Вставлять строку? не спорю.... вот только при обработке ста тысяч строк от одной "дополнительной" Вам толку скорее всего не будет... При чем тут 100 тысяч строк? Обрабатывать можно хоть миллиард строк, но в отчете все зачастую помещается на 1 лист. Например, смотрим мы кто из крупных клиентов прошлого года стал хуже покупать в этом году. Увидели что кто-то стал покупать в 2 раза меньше, хотим эту строку раскрыть в товары и услуги, чтобы увидеть, что именно из ходовых товаров этого года этот клиент стал покупать меньше. Это типичный аналитический вопрос с двумя подзапросами, требующий гибкости от OLAP-клиента. В BO такие вещи сделать сложно, а фактически для пользователей - невозможно. А вообще можете сохранить отчет в Excel - и уже форматировать там. Может, это не настолько удобно и "не красиво", но в конце концов работает... Ну никто и не спорит, просто придется довольно много времени тратить на постоянные выгрузки в Excel и на переформатирования... И ответа на сверсложное вычисление через 5 секунд и на терабайтной базе ждать глуповато, Вы не находите? ;) Терабайтную базу можно залить в компактный OLAP-куб, и в среднем 5-секундный отклик там останется. дабы не засорять ветку постоянной рекламой (уж извините, но камень в огорот Когноса Интересно, какая связь между рекламой и Когносом? На этом сайте рекламируется Microsoft, это понятно, но рекламных предложений или рекламных банеров по Когносу - никогда не было. Поделитесь! Что именно в Cognos вас не устраивает? Вы уж извините, но про Когнос ВООБЩЕ сказать ничего не смогу - не работал с ним. Честный, хотя и немного уклончивый ответ... :) на этом сайте меня слегка веселят постоянные попытки Когнос прорекламировать Было бы интересно узнать где же на этом сайте такая реклама... :) А я вот в свою очередь понять не могу, почему еще кто-то интересуется и обсуждает BO, когда по стоимости он дороже чем Cognos, а по функциональности - проигрывает Когносу не имея OLAP (при этом репортинговая функциональность BO и Cognos примерно сопоставима)... Вот тех кто сравнивает MS SQL Server и Oracle понять можно - у каждой из этих СУБД есть свои плюсы и минусы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 16:54 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
согласен с Jurii по поводу того что на сайте действительно нет навязчивой рекламы Cognos. Вообще тема была открыта не для того чтобы прорекламировать то или иное решение, а для того чтобы разобраться в основах проблемы. Лично я получил много полезной информации по заданным вопросам. Всем отвечавшим большое спасибо! когда будут еще вопросы, буду задавать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 17:09 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Jurii2 ......... : Если бы Вы только знали, насколько "профессиональные", насколько "ИТ" и насколько "специалисты" у нас эти отчеты ваяют!!!!! Можете ли привести название Вашей компании? Например если Вы из компании Терн и Ваши маркетологи анализируют Вашу клиентскую базу, то это не терабайтные, и даже не гигабайтные объемы данных... Вставлять строку? не спорю.... вот только при обработке ста тысяч строк от одной "дополнительной" Вам толку скорее всего не будет... При чем тут 100 тысяч строк? Обрабатывать можно хоть миллиард строк, но в отчете все зачастую помещается на 1 лист. Например, смотрим мы кто из крупных клиентов прошлого года стал хуже покупать в этом году. Увидели что кто-то стал покупать в 2 раза меньше, хотим эту строку раскрыть в товары и услуги, чтобы увидеть, что именно из ходовых товаров этого года этот клиент стал покупать меньше. Это типичный аналитический вопрос с двумя подзапросами, требующий гибкости от OLAP-клиента. В BO такие вещи сделать сложно, а фактически для пользователей - невозможно. А вообще можете сохранить отчет в Excel - и уже форматировать там. Может, это не настолько удобно и "не красиво", но в конце концов работает... Ну никто и не спорит, просто придется довольно много времени тратить на постоянные выгрузки в Excel и на переформатирования... И ответа на сверсложное вычисление через 5 секунд и на терабайтной базе ждать глуповато, Вы не находите? ;) Терабайтную базу можно залить в компактный OLAP-куб, и в среднем 5-секундный отклик там останется. дабы не засорять ветку постоянной рекламой (уж извините, но камень в огорот Когноса Интересно, какая связь между рекламой и Когносом? На этом сайте рекламируется Microsoft, это понятно, но рекламных предложений или рекламных банеров по Когносу - никогда не было. Поделитесь! Что именно в Cognos вас не устраивает? Вы уж извините, но про Когнос ВООБЩЕ сказать ничего не смогу - не работал с ним. Честный, хотя и немного уклончивый ответ... :) 1. Я не думаю, что мне стоит тут приводить название своей компании. Но не Терн, честное слово. Смысл фразы про "непрофессионалов" был в том, что у нас ВО вполне нормально используют люди, зачастую просто фантастически далекие от каких-либо информационных технологий... 2. По добавлению строк - я только сказал, что это возможно, и привел способ. Не более того. 3. Ну если провести достаточно хорошую предварительную подготовку данных - то и 5 секунд будет много! Вопрос в том, до какой степени данные удастся в этот куб "ужать". Собственно, именно это и определит скорость работы. 4. Ну не будем спорить. Приношу свои извинения. Просто я несколько раз заглядывал в эту ветку - и почти всегда натыкался на то, что Вы сводите разговор к тому, какая хорошая система Когнос. Это Ваше право, повторюсь еще раз. Особенно если мнение искренне. Может, это я просто так неудачно попадал, что у меня неверное мнение сложилось. В общем еще раз скажу, что не хотел лично Вас обидеть. 5. Я правда никогда не работал с Когносом - потому и не стал отвечать. Хоть уклончиво это, хоть нет. Но еще более неправильно было бы давать какие-либо отклики о системе, которую "вживую" ни разу не пробовал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 18:13 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
......4. Ну не будем спорить. Приношу свои извинения. Просто я несколько раз заглядывал в эту ветку - и почти всегда натыкался на то, что Вы сводите разговор к тому, какая хорошая система Когнос. Это Ваше право, повторюсь еще раз. Особенно если мнение искренне. Может, это я просто так неудачно попадал, что у меня неверное мнение сложилось. В общем еще раз скажу, что не хотел лично Вас обидеть. Под "этой веткой" я подразумевал сам раздел сайта OLAP и DWH, а не данную тему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 18:15 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
авторКак я понимаю, на практике BO не выводит информацию из OLAP (если верить г-ну AAron). Возможно, я не удачно выразился. BO умеет работать с кубами MS AS2000. Для этого существует специальный инструмент. Называется BO OLAP intelligence. Там можно создавать отчеты, аналитик может крутить кубы, дриллить, создавать калькуляции, строить графики и т.п. OLAPi работает непосредственно с кубов в BO есть другие модули, например, Performance Manager, которые работают поверх универсов. И вот в этом случае - есть проблемы. В остальных - нет. Ладно, позже могу еще написать, сейчас времени нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 18:53 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Есть опыт работы с Jurii'ем и с Cognos'ом но нет опыта работы с BO :( система действительно позволяет делать достаточно многие вещи, единственный минус, что сейчас замечен - большие требования к ресурсам машины и не 5-секундная скорость формирования отчетов с серьезной детализацией и не определенной заранее в модели OLAP-куба иерархией. Правда скорее это статистические отчеты, для которых олап системы не предназначены, но у нас пока нет другого инструмента, говорят в Cognos 8 такой инструмент появился. P.S. почти все было сделано своими руками с минимальным привлечением консультантов и внедренцев, т.е. я имею ввиду, что если б внедрять еще прямыми ручками-вероятно было б совсем неплохо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 12:25 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
GuestzЕсть опыт работы с Jurii'ем и с Cognos'ом но нет опыта работы с BO :( система действительно позволяет делать достаточно многие вещи, единственный минус, что сейчас замечен - большие требования к ресурсам машины и не 5-секундная скорость формирования отчетов с серьезной детализацией и не определенной заранее в модели OLAP-куба иерархией. Правда скорее это статистические отчеты, для которых олап системы не предназначены, но у нас пока нет другого инструмента, говорят в Cognos 8 такой инструмент появился. P.S. почти все было сделано своими руками с минимальным привлечением консультантов и внедренцев, т.е. я имею ввиду, что если б внедрять еще прямыми ручками-вероятно было б совсем неплохо. Так как у меня наоброт - есть опыт с ВО, но не с Когносом, то можно вопрос? Если не секрет - НАСКОЛЬКО большие требования к ресурсам? И к ресурсам чего - сервера БД или клиентского места, где отчет выводится? Это на любом отчете, или только на сложных? Про "5 секунд" вообще говорить не стоит, думаю... Если у тебя ЗАРАНЕЕ и ЧЕТКО определен набор данных для отображения - тогда да, его можно поместить в компактный куб и т.п. (хотя в такой ситуации можно зачастую и excel-ем обойтись...). Но если у этого куба потенциально может быть измерений двести (например, продажи с немеряно подробным справочником товаров/клиентов/..., в котором куча полей), то тогда работа с ним в некоторых случаях просто отвратительна... P.S. К сожалению, далеко не факт, что "внешние" консультанты и внедренцы имели бы прямые ручки :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 12:58 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
2 Глеб: система действительно позволяет делать достаточно многие вещи, единственный минус, что сейчас замечен - большие требования к ресурсам машины и не 5-секундная скорость формирования отчетов с серьезной детализацией и не определенной заранее в модели OLAP-куба иерархией. Правда скорее это статистические отчеты, для которых олап системы не предназначены, но у нас пока нет другого инструмента, говорят в Cognos 8 такой инструмент появился. Если в боковик отчета вывести несколько заводов, под заводы - несколько тысяч клиентов, под клиентов подтащить несколько тысяч товаров, то получится наиинтереснейший аналитический отчет :) Только потребуется вагон бумаги чтобы его распечатать... Такие отчеты визуализируют миллиарды ячеек, это большая и неоправданная нагрузка на OLAP-сервер. Глеб, такие отчеты нужно делать не в Cognos PowerPlay/Analysis Studio, а в Cognos Query/Report Studio. Эти отчеты не аналитические, и хорошо строятся обычным SQL с использованием индексов. P.S. И не вводи народ в заблуждение :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 13:27 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
2 Юрий Guest_3212 Глеб: система действительно позволяет делать достаточно многие вещи, единственный минус, что сейчас замечен - большие требования к ресурсам машины и не 5-секундная скорость формирования отчетов с серьезной детализацией и не определенной заранее в модели OLAP-куба иерархией. Правда скорее это статистические отчеты, для которых олап системы не предназначены, но у нас пока нет другого инструмента, говорят в Cognos 8 такой инструмент появился. Если в боковик отчета вывести несколько заводов, под заводы - несколько тысяч клиентов, под клиентов подтащить несколько тысяч товаров, то получится наиинтереснейший аналитический отчет :) Только потребуется вагон бумаги чтобы его распечатать... Такие отчеты визуализируют миллиарды ячеек, это большая и неоправданная нагрузка на OLAP-сервер. Глеб, такие отчеты нужно делать не в Cognos PowerPlay/Analysis Studio, а в Cognos Query/Report Studio. Эти отчеты не аналитические, и хорошо строятся обычным SQL с использованием индексов. P.S. И не вводи народ в заблуждение :) прошу прощения но это не Глеб :) согласен что вероятно так оно и должно быть (о чем и был написан PS, мы этот инструмент использовать не научились по понятным причинам), к сожалению наши юзеры очень любят именно такие отчеты (правда покупателей и номенклатуры с фактически ненулевыми значениями там несколько меньше и саму номенклатуру мы используем в кубах не всегда-общая же база - да такого порядка). ввиду того что каждому юзеру, как правило требуется своя иерархия и группировки вложенностей в отчетах - OLAP более удобен для их формирования чем использование просто SQL (возможно Cognos Query/Report Studio облегчает эту задачу но..... см. выше)... 2 ......... имеются ввиду требования к ресурсам машины где крутится сам куб. у нас стоит P4-3Ггц, 2Гб оперативки - на нем OLAP сервер. В случае, если начинается массовое юзанье кубов система может отказаться формировать отчеты. здесь я рассматриваю конечно же формирование таких отчетов как говорит Guest_321 :) на меньших объемах система крутится достаточно шустро. Общее количество измерений порядка 30, показателей так же, количество значений измерений (позиций контрагентов или номенклатуры)-порядка несколька тысяч, когда мы их перемножаем между собой и еще с заводами и др признаками-получается действительно внушительная картина:) В принципе я согласен что нужно юзать и др. функционал, т.к. ОЛАП не совсем подходит для таких задач. если честно я слабо представляю себе ОЛАП куб с двумя сотнями измерений... зачем он такой нужен, под какие задачи, можно пример??? продажа это в простом случае 3 показателя: количество, цена, сумма. Клиент и номенклатура - это 2 измерения, а где 200?? по поводу внешних консультантов совершенно откровенно могу сказать что ручки у них прямее чем у нас, знаний и опыта тоже больше :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 14:12 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Guestzесли честно я слабо представляю себе ОЛАП куб с двумя сотнями измерений... зачем он такой нужен, под какие задачи, можно пример??? продажа это в простом случае 3 показателя: количество, цена, сумма. Клиент и номенклатура - это 2 измерения, а где 200?? а если у клиента есть еще десяток параметров, то Вы просто делаете связь куба (продаж, например) со справочником клиентов, а не добавляете эти параметры в куб? Ну даже при таком подходе могу добавить навскидку еще пару измерений: где продано, кто продал... Кстати, при таком подходе полученный "куб" будет очень мало отличаться просто от куска таблицы продаж за период (разве что только у вас клиенты ненормальные и закупаются в день по 10 раз, требуя в каждом счете одной строкой выбивать по одной единице товара - тогда продажи удастся "свернуть"). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 14:55 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
2 ......... нет, конечно же мы все измерения вытягиваем в куб но у клиентов у нас на текущий момент, к сожалению только один параметр - Группа, у номенклатуры больше, но основных в пределах 10 (производитель, несколько вариантов групп, модель, вид и др.), неосновные как правило мы закладываем в иерархии внутри, если они необходимы. так же у продаж есть доп параметры-каналы сбыта, склад, центр ответственности, менеджер и др. сейчас у нас по причине разнородности исходных данных нет ряда измерений, которые хотелось бы иметь, но даже если взять их всеравно мне трудно представить 200... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 15:10 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Guestz2 ......... нет, конечно же мы все измерения вытягиваем в куб но у клиентов у нас на текущий момент, к сожалению только один параметр - Группа, у номенклатуры больше, но основных в пределах 10 (производитель, несколько вариантов групп, модель, вид и др.), неосновные как правило мы закладываем в иерархии внутри, если они необходимы. так же у продаж есть доп параметры-каналы сбыта, склад, центр ответственности, менеджер и др. сейчас у нас по причине разнородности исходных данных нет ряда измерений, которые хотелось бы иметь, но даже если взять их всеравно мне трудно представить 200... "К сожалению"?! Да это к Вашему счастью!!!! )))) А теперь представьте, скажем, какую-либо торговую сеть. В которой клиенты формально прикреплены к одному региону, но могут закупаться в другом (а зарегистрированы, например, в третьем)... При этом клиент закреплен за каким-либо сотрудником (своего региона), но обслуживал его сделку другой сотрудник (другого региона). А если еще и менеджер проводит только предварительную подготовку, а непосредственно счет выписывает оператор, то это еще один параметр. Теперь по товарам... Пусть у Вас есть товар. У него наверняка есть товарная группа. Плюс еще какая-нибудь ассортиментная группа. Может, еще целевая аудитория. Плюс, возможно, товар составной (ну предположим, та же шоколадка может попадать и в категорию "белый шоколад", и в категорию "темный шоколад", если она "полосатая"... А если она "полосатая", да еще и с орехами?! А если и с фундуком, и с арахисом?! ;) Кстати - это просто был "отвлеченный пример" - не надо придираться, ок?). И прочая фигня. Итого получаем, что анализировать продажи газа - это одно, но анализировать продажи какой-либо "мелочевки" - совсем другое... В общем, итого может набежать как раз измерений под пару сотен. И прикол в том, что реально в 90% отчетов из них используется наверное половина, но остальные 10% МОГУТ потребовать и остальные параметры. Вот и получается, что куб придется строить полный. А если еще и неизвестно заранее, по какому периоду будут построены те же отчеты... Итого получим, что "якобы свернутый" куб будет мало отличаться от исходной таблицы, только полей там будет до .... Кстати, удобство ВО в том, что он вытянет не все 200 измерений, а только те, которые выбраны в отчете :) Вот из-за такой фигни лично у меня и сделано так, что ВО обращается не к кубам, а непосредственно к базе... Был бы очень рад, если бы мне удалось это дело сворачивать в кубы, но, видно, пока не судьба... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 15:36 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
2 ............ Да... я понял Вас :-) полагаю в таком случае это действительно возможно... а наше счастье может быть и счастье но до поры до времени, т.к. периодически со стороны пользователей появляются заявления о малом количестве измерений, спасают же нас от этого наши доблестные коллеги которые вот уже как год "не могут" дать нам данные с той аналитикой которая необходима - в учетных системах есть и менеджеры и операторы и пункт назначения и многое остальное, просто к нам они не попадают - и вскоре боюсь это может стать "к сожалению".... а что касается 90% отчетов использующих 50% параметров могу предложить сделать второй куб и третий и 4-й если нужно... у нас их порядка 6-7: 2 полных с различной степенью детализации, а остальные рассчитаны на определенные специализированные отчеты - так мы распределяем нагрузку и ускоряем формирование ряда специализированных отчетов, т.к. часто определенная группа юзеров пользуется лишь 2-3 отчетами ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 17:57 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Guestz2 ............ Да... я понял Вас :-) полагаю в таком случае это действительно возможно... а наше счастье может быть и счастье но до поры до времени, т.к. периодически со стороны пользователей появляются заявления о малом количестве измерений, спасают же нас от этого наши доблестные коллеги которые вот уже как год "не могут" дать нам данные с той аналитикой которая необходима - в учетных системах есть и менеджеры и операторы и пункт назначения и многое остальное, просто к нам они не попадают - и вскоре боюсь это может стать "к сожалению".... а что касается 90% отчетов использующих 50% параметров могу предложить сделать второй куб и третий и 4-й если нужно... у нас их порядка 6-7: 2 полных с различной степенью детализации, а остальные рассчитаны на определенные специализированные отчеты - так мы распределяем нагрузку и ускоряем формирование ряда специализированных отчетов, т.к. часто определенная группа юзеров пользуется лишь 2-3 отчетами Ну, глядишь, когда Ваши коллеги "смогут" дать Вам данные, уже или Вас там не будет, или пользователям это не понадобится (как в сказке о Ходже Насреддине: "За 10 лет уж или ишак, или султан, или я точно сдохнем...") ;) Иметь 10 кубов - это хорошо, конечно... Но сложности начнутся, если пользователи вдруг построят отчет в одном кубе, а потом захотят его "расширить", добавив туда же поле, но из другого куба. :) Особенно если им это поле будет то нужно, то не нужно... К тому же при таком подходе от пользователей придется требовать "степень интеллекта выше среднего", то есть как минимум понимание того, что есть кубы, какие там данные, что мы за рамки кубов в отчете вышли, т.е. надо куб сменить и т.п.... Да и место на диске все-таки кубы требуют - боюсь, при десяти кубах лично нам придется диски как минимум удваивать :)) Поэтому пока что ВО и устраивает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 19:29 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
прошу прошения тороплюсь-поэтому кратко: у нас объем среднего куба 200-250Мб - не так и много (все конечно от кол-ва измерений зависит:) и вероятно при 200-это будет совсем другой вариант Cognos кстати позволяет частично решить вопрос методом дрилл-дауна из одного куба в другой (этой технологией правда мы тоже не пользовались, а уже наверное пора кстати - хорошо - вспомнил о том что такое есть! а по поводу интеллекта-это да... временами такая проблема возникает) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 19:48 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
2 Guestz: 2 Юрий прошу прощения но это не Глеб :) Вот как... Не узнал, богатым будете :) У меня есть предположения, но не хотелось бы гадать. Если хотите чтобы эффективность использования Cognos у вас повысилась - предлагаю пообщаться вне форума, обсудить ваши задачи. у нас стоит P4-3Ггц, 2Гб оперативки - на нем OLAP сервер. В случае, если начинается массовое юзанье кубов система может отказаться формировать отчеты. Если OLAP-куб сделать из файла Excel, в котором 100 строк и 10 колонок, то при желании можно убить и 32-процессорный сервер с 64 гигабайтами оперативной памяти (если сделать сто миллиардов строчек и скрыть нулевые строки)... Чтобы такого не происходило - нужно вести соответствующую работу с пользователями, повышать их квалификацию. сейчас у нас по причине разнородности исходных данных нет ряда измерений, которые хотелось бы иметь, но даже если взять их всеравно мне трудно представить 200... 200 измерений в кубе можно представить легко. Например проводите Вы анкетирование Ваших клиентов - каждый вопрос в анкете - это отдельное измерение, эти измерения позволят проводить очень интересные аналитические исследования, сегментацию. Кроме этого по-хорошему надо делать вычисляемые измерения (лояльный клиент или нет, долго он существует или новый клиент, покупает ли он дешевые товары или дорогие, и т.д.) - эти измерения опять таки ценны для выявления скрытых тенденций и зависимостей... Cognos позволяет делать вычисляемые измерения без необходимости программирования на SQL. 2 ............ : Кстати, удобство ВО в том, что он вытянет не все 200 измерений, а только те, которые выбраны в отчете :) У Cognos вообще то есть тоже самое, на основе такого же семантического слоя метаданных. Вот из-за такой фигни лично у меня и сделано так, что ВО обращается не к кубам, а непосредственно к базе... Был бы очень рад, если бы мне удалось это дело сворачивать в кубы, но, видно, пока не судьба... Я думаю это и есть главная слабая сторона BO. По-хорошему, нужно чтобы семантический слой частично состоял из обращения к кубам, а частично - из обращения к реляционным таблицам. Пользователи могут не задумываться над архитектурой решения, когда они будут делать отчеты по анализу продаж - будут задействоваться кубы, когда будут делать многостраничные отчеты - будет несильно нагружаться реляционный сервер. Но можно и все закачивать в кубы. Куб с 200 измерений - это вполне реально. Да и место на диске все-таки кубы требуют - боюсь, при десяти кубах лично нам придется диски как минимум удваивать :)) Поэтому пока что ВО и устраивает. Кубы занимают места на диске всяко меньше, чем распухающее реляционное хранилище данных, в котором под BO надо делать много таблиц с агрегатами. А уж про размер бэкапов и про скорость поднятия их в случае выхода из строя основного сервера я не говорю - мои знакомые из розничной сети как-то поднимали реляционное ХД 2 недели... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 21:41 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Jurii У Cognos вообще то есть тоже самое, на основе такого же семантического слоя метаданных. Я думаю это и есть главная слабая сторона BO. По-хорошему, нужно чтобы семантический слой частично состоял из обращения к кубам, а частично - из обращения к реляционным таблицам. Пользователи могут не задумываться над архитектурой решения, когда они будут делать отчеты по анализу продаж - будут задействоваться кубы, когда будут делать многостраничные отчеты - будет несильно нагружаться реляционный сервер. Но можно и все закачивать в кубы. Куб с 200 измерений - это вполне реально. Как называется программный продукт у Cognos все это реализующий, и где можно достать демо-версию продукта? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2006, 08:54 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
2 Bormoglot: Как называется программный продукт у Cognos все это реализующий, и где можно достать демо-версию продукта? Программный продукт называется Cognos 8 BI. По вопросу получения демо-версии пишите запрос на адрес cognos@narod.ru или ymariinskyi@microtest.ru . P.S. Если говорить о том, что все данные закачиваются в один OLAP-куб с большим количеством аналитических разрезов и показателей, то это можно делать не только в Cognos 8 BI, но и с помощью OLAP-сервера Cognos PowerPlay версии 7.х или 6.x. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2006, 10:51 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
JuriiКубы занимают места на диске всяко меньше, чем распухающее реляционное хранилище данных интересно, а где кубы хранятся? вероятно, в своей СУБД, на сервере? JuriiА уж про размер бэкапов и про скорость поднятия их в случае выхода из строя основного сервера я не говорю почему Вы думаете, что надежность сервера Cognos выше чем, Oracle например? Jurii- мои знакомые из розничной сети как-то поднимали реляционное ХД 2 недели... у меня знакомый неделю пытался Когнос установить, а у него не получилось, вот такой вот "плохой" когнос... а может знакомый криворукий... ЗЫ Когнос, близко не видел, просто интересно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2006, 20:12 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
2 серый ник....: Если не секрет, Вас зовут СЕРгей или НИКита? :) Кубы занимают места на диске всяко меньше, чем распухающее реляционное хранилище данных интересно, а где кубы хранятся? вероятно, в своей СУБД, на сервере? Каждый куб - это отдельный файл (в формате многомерной базы данных Cognos), обычно размер этих файлов, когда в них храниятся данные за всю историю по всем товарам и клиентам, не превышает 1 гигабайта. Это усредненная оценка, бывают кубы и побольше, и поменьше, но в целом кубы обычно на 1-2 порядка меньше чем реляционные источники данных. А уж про размер бэкапов и про скорость поднятия их в случае выхода из строя основного сервера я не говорю почему Вы думаете, что надежность сервера Cognos выше чем, Oracle например? Пусть надежность будет одинаковой. Просто если Оракл - надежен, это не значит что железо, на котором он живет - не может сломаться. Соответственно делают бэкапы. При размере ХД в 50-140 гигабайт, общий размер кубов составляет в пределах пары гигабайт (эти параметры взяты из двух торгово-производственных компаний, где используется Cognos, продукция этих компаний продается практически в каждом магазине России). - мои знакомые из розничной сети как-то поднимали реляционное ХД 2 недели... у меня знакомый неделю пытался Когнос установить, а у него не получилось, вот такой вот "плохой" когнос... а может знакомый криворукий... Я имею в виду крупную московскую розничную сеть, у которой в хранилище Оракл хранятся все строки чеков за всю историю, а в железо еще не вложены миллионы долларов, чтобы терабайтный объем данных быстро поднимался из бэкапа. И думаю что руки у их специалистов не кривые, раз держат у себя такие хранилища... ЗЫ Когнос, близко не видел, просто интересно Не быть знакомым с Когнос - это в наши дни не модно :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2006, 20:31 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
серый ник.... интересно, а где кубы хранятся? вероятно, в своей СУБД, на сервере? В файлах. Готовые. Время получения данных = время их чтения. Ничего лишнего. Кукуете на загрузке в куб , закон сохранения энергии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2006, 01:24 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
JuriiКаждый куб - это отдельный файл (в формате многомерной базы данных Cognos), обычно размер этих файлов, когда в них храниятся данные за всю историю по всем товарам и клиентам, не превышает 1 гигабайта. Это усредненная оценка, бывают кубы и побольше, и поменьше, но в целом кубы обычно на 1-2 порядка меньше чем реляционные источники данных. Не быть знакомым с Когнос - это в наши дни не модно :) 1. Поясни, пожалуйста... Предположим, у нас есть описанная мной ранее ситуация - куча клиентов, они закупаются один раз в день, в счетах строки с одним товаром не дублируются и т.п. И таблица продаж (реляционная, т.е. просто со ссылками на товары, клиентов и т.п.) занимает.... ну пусть гигабайт 5-10. И "свернуть" эту таблицу в куб тогда почти невозможно (если оставлять детализацию по дням-товарам-клиентам). А мы еще и добавляем в кубе расшифровку наименований/групп/признаков товаров, клиентов и т.п. Я затрудняюсь понять, как при этом размер куба может быть меньше размера исходной таблицы на 1-2 порядка... Ну пусть в исходной таблице FillFactor стоял 80%, а в кубе его нет - сожмется тогда пусть на 20%... но откуда получается 1-2 порядка?! 2. Рекламы Когноса в Ваших постах не встречается ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2006, 10:58 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
спасибо за ответы, еще вопрос, в ВО есть ETL средство, Data Integrator, а что есть подобное у Cognos и насколько оно сопоставимо? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2006, 12:41 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
.............. Я затрудняюсь понять, как при этом размер куба может быть меньше размера исходной таблицы на 1-2 порядка... Ну пусть в исходной таблице FillFactor стоял 80%, а в кубе его нет - сожмется тогда пусть на 20%... но откуда получается 1-2 порядка?! Файлики действительно получаются очень маленькими. Как это достигается - трудно понять. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2006, 10:29 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Виктор Сакович .............. Я затрудняюсь понять, как при этом размер куба может быть меньше размера исходной таблицы на 1-2 порядка... Ну пусть в исходной таблице FillFactor стоял 80%, а в кубе его нет - сожмется тогда пусть на 20%... но откуда получается 1-2 порядка?! Файлики действительно получаются очень маленькими. Как это достигается - трудно понять. Ну так может, у Вас просто в настройках куба стоит, что надо хранить только 5-10% от всех данных, а остальное выбирать on-line в случае обращения?! Вот он маленький и получается. Но выигрыш по скорости это дает только в случае, когда Вы обращаетесь только к последним данным, т.е. именно к тем 10%, что были уже выбраны... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2006, 11:05 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
2 iscrafm: Кукуете на загрузке в куб , закон сохранения энергии. Кубы обычно перестраиваются и/или обновляются по ночам, когда пользователи Cognos отдыхают :) Ночное время не так ценно для принятия эффективных управленческих решений, как рабочее дневное время. 2 ............. & Виктор Сакович : Поясни, пожалуйста... Предположим, у нас есть описанная мной ранее ситуация - куча клиентов, они закупаются один раз в день, в счетах строки с одним товаром не дублируются и т.п. И таблица продаж (реляционная, т.е. просто со ссылками на товары, клиентов и т.п.) занимает.... ну пусть гигабайт 5-10. И "свернуть" эту таблицу в куб тогда почти невозможно (если оставлять детализацию по дням-товарам-клиентам). А мы еще и добавляем в кубе расшифровку наименований/групп/признаков товаров, клиентов и т.п. Я затрудняюсь понять, как при этом размер куба может быть меньше размера исходной таблицы на 1-2 порядка... Ну пусть в исходной таблице FillFactor стоял 80%, а в кубе его нет - сожмется тогда пусть на 20%... но откуда получается 1-2 порядка?! Конечно, я не знаю всех алгоритмов, которые используют программисты Cognos, но могу предположить, что сжатие на 1-2 порядка происходит по следующим основным причинам: 1) В OLAP-кубы Cognos не закачиваются лишние для анализа и отчетности поля (служебные поля, ID-шники и т.п.), не закачиваются индексы. 2) В OLAP-кубе, коду или названию клиента, или дате документа, присваивается короткий указатель, чем меньше количество мемберов в кубе - тем меньше места занимают указатели. А вот как короткие указатели ссылаются на числа в многомерной БД Cognos, чтобы отчеты в среднем строились не более чем за 5 секунд - это ноу-хау компании Cognos... Я как-то рассказывал об эксперименте, когда текстовый файл содержащий 7 миллионов детальных записей размером 600-700 мегабайт по 700 тысячам юридических лиц умещался в OLAP-куб размером 50 мегабайт, а при архивации размер куба сокращался до 1.3 мегабайт. И при этом не было какого-либо предагрегирования, из куба можно было получить любую из 10 записей по любой из 700 тысяч организаций. Также хочу отметить, что OLAP-кубы Cognos шустро крутятся на 486 компьютерах с процессором 80 мегагерц с оперативной памятью 16-24 мегабайта, под Windows-95. Все это говорит о том, что за 15 лет совершенствования OLAP-движка Cognos его алгоритмы идеально вылизаны и доведены до совершенства. Ну так может, у Вас просто в настройках куба стоит, что надо хранить только 5-10% от всех данных, а остальное выбирать on-line в случае обращения?! Вот он маленький и получается. Но выигрыш по скорости это дает только в случае, когда Вы обращаетесь только к последним данным, т.е. именно к тем 10%, что были уже выбраны... Нет, таких настроек нет. Все детальные данные лежат в кубе (например для каждого часа суток/дня-товара-дисконтной карты/клиента). еще вопрос, в ВО есть ETL средство, Data Integrator, а что есть подобное у Cognos и насколько оно сопоставимо? У Cognos есть промышленное ETL-средство Data Manager (Decision Stream). Я не думаю что оно может уступать по функциональности продукту Data Integrator. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2006, 13:22 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
JuriiКонечно, я не знаю всех алгоритмов, которые используют программисты Cognos, но могу предположить, что сжатие на 1-2 порядка происходит по следующим основным причинам: 1) В OLAP-кубы Cognos не закачиваются лишние для анализа и отчетности поля (служебные поля, ID-шники и т.п.), не закачиваются индексы. 2) В OLAP-кубе, коду или названию клиента, или дате документа, присваивается короткий указатель, чем меньше количество мемберов в кубе - тем меньше места занимают указатели. А вот как короткие указатели ссылаются на числа в многомерной БД Cognos, чтобы отчеты в среднем строились не более чем за 5 секунд - это ноу-хау компании Cognos... Я как-то рассказывал об эксперименте, когда текстовый файл содержащий 7 миллионов детальных записей размером 600-700 мегабайт по 700 тысячам юридических лиц умещался в OLAP-куб размером 50 мегабайт, а при архивации размер куба сокращался до 1.3 мегабайт. И при этом не было какого-либо предагрегирования, из куба можно было получить любую из 10 записей по любой из 700 тысяч организаций. Также хочу отметить, что OLAP-кубы Cognos шустро крутятся на 486 компьютерах с процессором 80 мегагерц с оперативной памятью 16-24 мегабайта, под Windows-95. Все это говорит о том, что за 15 лет совершенствования OLAP-движка Cognos его алгоритмы идеально вылизаны и доведены до совершенства. Нет, таких настроек нет. Все детальные данные лежат в кубе (например для каждого часа суток/дня-товара-дисконтной карты/клиента). Ну тогда можете считать меня "не самым умным своим собеседником", но я Вам не верю. Может, я слишком хорошо усвоил сказку про "бесплатный сыр".... Но 700Мб текста безо всякого сжатия засунуть в 50Мб пространства... не понимаю. И то, что Вы описываете - это не OLAP-куб, а структура реляционной СУБД, пусть "снаружи" это и вроде как и не видно. А если база реляционная - то у нее и скорость соответствующая... Пусть все сказанное IMHO, но Вы меня напугали ;) Кстати, раз уж все алгоритмы Когноса УЖЕ совершенны, то там подразделение разработчиков уже закрылось, я так думаю. Или это снова всего лишь "отсутствие рекламы"? ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2006, 13:45 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
To COGNOS.NAROD.RU У Cognos есть промышленное ETL-средство Data Manager (Decision Stream). Я не думаю что оно может уступать по функциональности продукту Data Integrator. Юра а Вы хоть раз задумайтесь. Нет в России Decision Stream - и никто не пытается продвигать ! ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2006, 14:16 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
2 ............. : Ну тогда можете считать меня "не самым умным своим собеседником", но я Вам не верю Если Вы не верите и уверены в своей правоте - не хотите ли заключить пари? Гарантированно получите приз :) Может, я слишком хорошо усвоил сказку про "бесплатный сыр".... Но 700Мб текста безо всякого сжатия засунуть в 50Мб пространства... не понимаю. Думаю что секрет в коротких указателях Cognos. Кстати, раз уж все алгоритмы Когноса УЖЕ совершенны, то там подразделение разработчиков уже закрылось, я так думаю. Подразделение разработчиков теперь мало занимается OLAP-движком (раз уж он и в 7, и в 8 версии один и тот же). Основные силы и ресурсы разработки сейчас направлены на развитие Cognos 8, чтобы преумножить функциональность Cognos, доступ к которой предоставляется через Web-портал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2006, 18:15 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
2 amex: Нет в России Decision Stream - и никто не пытается продвигать ! ;) Ну как же нет, если есть. Практически все партнеры Cognos в России и СНГ продвигают это ETL-средство. Г-н Гликоген насколько я помню от него просто в восторге... С чем я согласен, так это с тем, что пользователи Cognos в основном тратят свои ИТ-бюджеты на модули OLAP-анализа, визуализации, ГИС, репортинга, а ETL - это не такая уж нужная для Cognos функциональность. У Cognos очень хорошо реализован виртуальный ETL - с использованием связки Impromptu/Framework Manager + PowerPlay, который является хорошим заменителем реального ETL. Кроме этого есть ETL-решения от партнеров Cognos, интегрированные с аналитическими модулями Cognos. А вот те системы, которые работают без OLAP (MSTR, BO и т.п.), не могут работать без хорошо спроектированного хранилища данных, и им ETL нужен обязательно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2006, 18:32 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Jurii2 ............. : Ну тогда можете считать меня "не самым умным своим собеседником", но я Вам не верю Если Вы не верите и уверены в своей правоте - не хотите ли заключить пари? Гарантированно получите приз :) Может, я слишком хорошо усвоил сказку про "бесплатный сыр".... Но 700Мб текста безо всякого сжатия засунуть в 50Мб пространства... не понимаю. Думаю что секрет в коротких указателях Cognos. Если уж приз я получу ГАРАНТИРОВАННО, то зачем пари? ;) Может, мне Вам просто адрес сказать для высылки приза? ;) А в чем суть пари? Можно узнать условия? Может, мне и будет интересно убедиться в собственной неправоте... А заодно узнать, как реально можно сжимать информацию в разы без ущерба качеству доступа к ней (и даже с выигрышем). Если только это не слишком уж "ноу-хау" компании Когнос ;). "Короткий" указатель - это сколько?! один бит? два? ;) или все-таки минимум байт? а сколько вариантов Вы байтом адресовать сможете? Вроде бы 2^8=256. И вы хотите сказать тогда, что в 700Мб текста максимум 256 вариантов значений для каждого каждого поля? Это крутая база... Или Когнос научился оперировать милли-, микро-, нано- и пикобайтами? ;) И опять-таки, снова повторю: если мы используем какие-либо "указатели" - то это уже не куб, а обычная реляционная БД. Со всеми своими плюсами и минусами.... Заранее спасибо за ответ :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2006, 19:22 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
2 ............. : Если уж приз я получу ГАРАНТИРОВАННО, то зачем пари? ;) Может, мне Вам просто адрес сказать для высылки приза? ;) Ну пари это так, формальность. Я не ставлю под сомнение Вашу правоту. Но для порядка надо проверить, вдруг все таки я действительно в кубе Cognos без потери детализации данных ужал текстовый файл с 600-700 до 50 мегабайт, а потом методом архивирования - с 50 до 1.3 мегабайт... Тогда Вы пари проиграете :) А в чем суть пари? Можно узнать условия? Обычно пари - это когда спорят на деньги или что-то в этом роде :) а сколько вариантов Вы байтом адресовать сможете? Вроде бы 2^8=256 Правильно копаете. А двумя байтами сколько вариантов можно адресовать? И опять-таки, снова повторю: если мы используем какие-либо "указатели" - то это уже не куб, а обычная реляционная БД. Со всеми своими плюсами и минусами.... Термин указатель может использоваться по отношению не только к реляционной БД, но и к многомерной. Но дело не в теории - главное что в той БД про которую я говорю, в отличие от реляционной, гарантируется что среднее время генерации любого отчета - не более 5 секунд. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2006, 20:20 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Jurii... гарантируется что среднее время генерации любого отчета - не более 5 секунд. Jurii, вот за что мы Вас ценим, так это за глубоко научный, можно сказать фундаментальный, подход к оценке производительности BI систем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2006, 20:42 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
2 MSTR_Fan: ... гарантируется что среднее время генерации любого отчета - не более 5 секунд. Jurii, вот за что мы Вас ценим, так это за глубоко научный, можно сказать фундаментальный, подход к оценке производительности BI систем. А как Вы гогадались что этот подход научный? Неужели узнали что Cognos имеет функциональность OLAP и соответствует стандарту FASMI ( http://www.olapreport.com/fasmi.htm )? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2006, 21:02 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Jurii2 MSTR_Fan: ... гарантируется что среднее время генерации любого отчета - не более 5 секунд. Jurii, вот за что мы Вас ценим, так это за глубоко научный, можно сказать фундаментальный, подход к оценке производительности BI систем. А как Вы гогадались что этот подход научный? Неужели узнали что Cognos имеет функциональность OLAP и соответствует стандарту FASMI ( http://www.olapreport.com/fasmi.htm )? а где там про 5 секунд? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2006, 22:35 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
zmike а где там про 5 секунд? а, нашел... это видимо еще где-то есть стандарт, что цифры до 10 надо писать словами ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2006, 22:38 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
JuriiНеужели узнали что Cognos имеет функциональность OLAP и соответствует стандарту FASMI ( http://www.olapreport.com/fasmi.htm )? "SHARED means that the system implements all the security requirements for confidentiality (possibly down to cell level) and, if multiple write access is needed, concurrent update locking at an appropriate level." Интересно, а как в PowerPlay реализуются блокировки при модификации отдельных элементов куба? Или PP не в полной мере удовлетворяет требованиям FASMI? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2006, 22:51 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
2 Андрей Прохоров: and, if multiple write access is needed, concurrent update locking at an appropriate level." Интересно, а как в PowerPlay реализуются блокировки при модификации отдельных элементов куба? Или PP не в полной мере удовлетворяет требованиям FASMI? Я считаю что в PowerPlay multiple write access is NOT needed. Закачка данных в OLAP-куб (в те или иные ячейки куба) не производится несколькими процессами одновременно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.04.2006, 23:06 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Jurii2 amex: Нет в России Decision Stream - и никто не пытается продвигать ! ;) Ну как же нет, если есть. Практически все партнеры Cognos в России и СНГ продвигают это ETL-средство. Г-н Гликоген насколько я помню от него просто в восторге... С чем я согласен, так это с тем, что пользователи Cognos в основном тратят свои ИТ-бюджеты на модули OLAP-анализа, визуализации, ГИС, репортинга, а ETL - это не такая уж нужная для Cognos функциональность. У Cognos очень хорошо реализован виртуальный ETL - с использованием связки Impromptu/Framework Manager + PowerPlay, который является хорошим заменителем реального ETL. Кроме этого есть ETL-решения от партнеров Cognos, интегрированные с аналитическими модулями Cognos. А вот те системы, которые работают без OLAP (MSTR, BO и т.п.), не могут работать без хорошо спроектированного хранилища данных, и им ETL нужен обязательно. Если Cognos не имеет особого отношения к хранилищу данных, то тогда что Вы делаете в этом топике? Прочтите внимательнее название топика. Завели бы отдельный топик, и впаривали бы там свой любимый Cognos. Не обязательно же до шизы доходить в любви к этой замечательной компании. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2006, 10:22 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Виктор Сакович Если Cognos не имеет особого отношения к хранилищу данных, то тогда что Вы делаете в этом топике? Прочтите внимательнее название топика. Завели бы отдельный топик, и впаривали бы там свой любимый Cognos. Не обязательно же до шизы доходить в любви к этой замечательной компании. Cognos - это BI продукт, поэтому говорить, что он не имеет отношение к хранилищам данных, просто глупо. Меня в данный момент интересует следующее: если Cognos такой супер продукт и Jurii его на просторах нашей Родины толкнул уже не одному десятку компаний и пользователи Cognos растут как грибы и тогда почему .... расхваливает Cognos один только Jurii? Пусть выскажутся реальные пользователи Cognos, те, кому внедрили данный продукт, а не только внедренцы и продажники... Подтвердите нам, действительно ли любой запрос к любым кубам Cognos возвращает результат в среднем за пять секунд, а сами кубы занимают на порядок меньше чем реляционные таблицы. Ну и вообще, ваше личное отношение к функциональности продукта тоже приветствуется...... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2006, 10:53 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Bormoglot Виктор Сакович Если Cognos не имеет особого отношения к хранилищу данных, то тогда что Вы делаете в этом топике? Прочтите внимательнее название топика. Завели бы отдельный топик, и впаривали бы там свой любимый Cognos. Не обязательно же до шизы доходить в любви к этой замечательной компании. Cognos - это BI продукт, поэтому говорить, что он не имеет отношение к хранилищам данных, просто глупо. Меня в данный момент интересует следующее: если Cognos такой супер продукт и Jurii его на просторах нашей Родины толкнул уже не одному десятку компаний и пользователи Cognos растут как грибы и тогда почему .... расхваливает Cognos один только Jurii? Пусть выскажутся реальные пользователи Cognos, те, кому внедрили данный продукт, а не только внедренцы и продажники... Подтвердите нам, действительно ли любой запрос к любым кубам Cognos возвращает результат в среднем за пять секунд, а сами кубы занимают на порядок меньше чем реляционные таблицы. Ну и вообще, ваше личное отношение к функциональности продукта тоже приветствуется...... Господа, являясь пользователем и внедренцем Cognos на своем предприятии уже 1,5 года могу Всех ответсвенно заверить что продукты от Jrii действительно работаю. Суть проблемы в том, что надо использовать их исключительно по назначению. И если вы хотите сделать что то серьёзное то вам понадобяться еще и грамотные постановщики способные правильно расставить акценты на укрупненном уровне (бытует ложное мнение что это может каждый). На нашем примере могу любого интересующегося заверить продукт достойный внимания и работает нормально. конечно есть вопросы и непонятки, но в целом этот продукт достоин Внимания, единственный конкурент у него это комплексное решение от компании Oracle. но создать решение на когносе или на оракле не одно и тоже, для маленьких компаний когнос, для больших оракл. если требуется только BI то подойдет и когнос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2006, 11:19 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
JuriiЯ считаю что в PowerPlay multiple write access is NOT needed. Закачка данных в OLAP-куб (в те или иные ячейки куба) не производится несколькими процессами одновременно. Тогда какой смысл ссылаться на стандарт, которому Вы не считаете нужным следовать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2006, 11:36 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
KaniovskiВообщем так. Готовится ПО для нескольких компаний. Какой именно СУБД каждая из них будет пользоваться приблизительно ясно (Oracle и MSSQL). Разрабатывать параллельно OLAP решения и на то и на другое слишком замороченно. К тому же те кто работает на MSSQL не захотят ставить что-то из Oracle и наоборот. Хочется найти общее решение которое и будем дальше поддерживать. перекачивать хранилища из одной СУБД в другую проблем не составляет, а вот переделывать параллельно несколько разных кубов это уже расточительно. Вот я и ищу решение не основанное на конкретном СУБД. Уважаемый, попробуйте рассмтотреть вопрос в долгосрочной перспективе на два года, возможно у вас появятся некоторые ожидания определяющие направления работ. Буквально недавно, после 1,5 лет решения аналогичной задачи, пришел к однозначному выводу что надо брать все решение от одного поставщика, выбрал Оракл (особенно учитывая новые версии продуктов Оракл выходящих в 2007г.). Цена сопровождения и развития конечного комплекса в составе BI, CPM и Portal будет на порядок меньше. Возврастает оперативность обработки и модификации комплекса, сужаются профили специалистов (очень сильно повышает качество проекта). Остается решить один вопрос - бюджет проекта и его рамки. Вывод подскажет простой экономический расчет на два года в перед. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2006, 11:36 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Gleb P создать решение на когносе или на оракле не одно и тоже, для маленьких компаний когнос, для больших оракл. очень интересная формулировка :) к сожалению, никогда не сталкивался с оракл решением по BI... боюсь, что не могу отнести нашу компанию к маленькой и Cognos у нас действительно РАБОТАЕТ, его юзают люди и они довольны :) вопрос в том что Вы желаете от системы получить - реляционную таблицу через интерфейс Cognos или аналитический OLAP отчет??? в среднем(!!) скорость формирования отчетов действительно может составить несколько секунд, кубы действительно небольших объемов, по поводу сжатия с 700Мб до 50 ничего сказать не могу (не тестировали) но самый объемный куб у нас в компании занимает около 500Мб. при этом я не хочу сказать что я защищаю Cognos, что система идеальна и у нас нет проблем, НО господа - покажите мне идеальную систему?? 2 Bormoglot кстати, прошу прощения, но форум называется OLAP и DWH. я что-либо путаю или Cognos и OLAP это вещи не совместимые???? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2006, 11:55 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Cognos user Gleb P создать решение на когносе или на оракле не одно и тоже, для маленьких компаний когнос, для больших оракл. очень интересная формулировка :) к сожалению, никогда не сталкивался с оракл решением по BI... боюсь, что не могу отнести нашу компанию к маленькой и Cognos у нас действительно РАБОТАЕТ, его юзают люди и они довольны :) вопрос в том что Вы желаете от системы получить - реляционную таблицу через интерфейс Cognos или аналитический OLAP отчет??? в среднем(!!) скорость формирования отчетов действительно может составить несколько секунд, кубы действительно небольших объемов, по поводу сжатия с 700Мб до 50 ничего сказать не могу (не тестировали) но самый объемный куб у нас в компании занимает около 500Мб. при этом я не хочу сказать что я защищаю Cognos, что система идеальна и у нас нет проблем, НО господа - покажите мне идеальную систему?? 2 Bormoglot кстати, прошу прощения, но форум называется OLAP и DWH. я что-либо путаю или Cognos и OLAP это вещи не совместимые???? Уважаемы Вы наверно не полностью читали исходное сообщение, а выхватывать куски из текста не есть правильно. Читайте внимательно " .... Если Вам нужен только BI Вам подойдет и Cognos. ..." ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2006, 13:31 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Cognos user 2 Bormoglot кстати, прошу прощения, но форум называется OLAP и DWH. я что-либо путаю или Cognos и OLAP это вещи не совместимые???? Прощаю, но что вас не устраивает, не понял?))))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2006, 14:11 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
.............сможете? Вроде бы 2^8=256. И вы хотите сказать тогда, что в 700Мб текста максимум 256 вариантов значений для каждого каждого поля? Это крутая база... Или Когнос научился оперировать милли-, микро-, нано- и пикобайтами? ;) И опять-таки, снова повторю: если мы используем какие-либо "указатели" - то это уже не куб, а обычная реляционная БД. Со всеми своими плюсами и минусами.... Заранее спасибо за ответ :) Не знаю как там и что делает Когнос, но исходные данные, характерные для таких задач, можно пожать раз в 10 (а то и больше) даже в "исходном" реляционном виде. Причём вместе с индексами. В экспериментах на реальных хранилищах (реляционных) мы получали 16-ти кратное сжатие. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2006, 16:24 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Bormoglot Cognos user 2 Bormoglot кстати, прошу прощения, но форум называется OLAP и DWH. я что-либо путаю или Cognos и OLAP это вещи не совместимые???? Прощаю, но что вас не устраивает, не понял?))))) ) ) еще раз прошу прощения это относилось к Виктор Сакович Если Cognos не имеет особого отношения к хранилищу данных, то тогда что Вы делаете в этом топике? Прочтите внимательнее название топика. Завели бы отдельный топик, и впаривали бы там свой любимый Cognos. Не обязательно же до шизы доходить в любви к этой замечательной компании. что касается сжатия в 10-16 раз ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2006, 16:48 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
pavelvp .............сможете? Вроде бы 2^8=256. И вы хотите сказать тогда, что в 700Мб текста максимум 256 вариантов значений для каждого каждого поля? Это крутая база... Или Когнос научился оперировать милли-, микро-, нано- и пикобайтами? ;) И опять-таки, снова повторю: если мы используем какие-либо "указатели" - то это уже не куб, а обычная реляционная БД. Со всеми своими плюсами и минусами.... Заранее спасибо за ответ :) Не знаю как там и что делает Когнос, но исходные данные, характерные для таких задач, можно пожать раз в 10 (а то и больше) даже в "исходном" реляционном виде. Причём вместе с индексами. В экспериментах на реальных хранилищах (реляционных) мы получали 16-ти кратное сжатие. я полагаю Вы имеете ввиду архивацию?? поправьте плз если ошибаюсь если так, то здесь речь несколько не об этом мне кажется ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2006, 16:50 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Cognos user pavelvp Не знаю как там и что делает Когнос, но исходные данные, характерные для таких задач, можно пожать раз в 10 (а то и больше) даже в "исходном" реляционном виде. Причём вместе с индексами. В экспериментах на реальных хранилищах (реляционных) мы получали 16-ти кратное сжатие. я полагаю Вы имеете ввиду архивацию?? поправьте плз если ошибаюсь если так, то здесь речь несколько не об этом мне кажется я бы даже сказал, что СОВСЕМ не об этом... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2006, 17:15 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Cognos userя полагаю Вы имеете ввиду архивацию?? поправьте плз если ошибаюсь если так, то здесь речь несколько не об этом мне кажется Нет, не архивацию. Речь о сжатии данных внутри хранилища средствами специализированной СУБД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2006, 17:30 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
pavelvp Cognos userя полагаю Вы имеете ввиду архивацию?? поправьте плз если ошибаюсь если так, то здесь речь несколько не об этом мне кажется Нет, не архивацию. Речь о сжатии данных внутри хранилища средствами специализированной СУБД. тогда прошу прощения, с такими средствами я к сожалению не знаком, не подскажете ради интереса где можно почитать? каковы алгоритмы сжатия? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2006, 17:56 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Cognos userтогда прошу прощения, с такими средствами я к сожалению не знаком Так их фактически и нет... пока. не подскажете ради интереса где можно почитать? каковы алгоритмы сжатия? Пока нигде :-) Можно будет ознакомиться на сайте сitforum. После 11-12 апреля, когда пройдёт конференция "Корпоративные базы данных", будут опубликованы выступления. Методы сжатия применяются разнообразные: словарное, дифференциальное, экономное кодирование и т.п., могут комбинироваться. В зависимости от статистики по исходным данным. Меня сейчас в рекламе обвинят :-) Просто хотел сказать, что запихнуть 700М в 50М вполне реально при некоторых условиях... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2006, 18:47 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
pavelvp Cognos userтогда прошу прощения, с такими средствами я к сожалению не знаком Так их фактически и нет... пока. не подскажете ради интереса где можно почитать? каковы алгоритмы сжатия? Пока нигде :-) Можно будет ознакомиться на сайте сitforum. После 11-12 апреля, когда пройдёт конференция "Корпоративные базы данных", будут опубликованы выступления. Методы сжатия применяются разнообразные: словарное, дифференциальное, экономное кодирование и т.п., могут комбинироваться. В зависимости от статистики по исходным данным. Меня сейчас в рекламе обвинят :-) Просто хотел сказать, что запихнуть 700М в 50М вполне реально при некоторых условиях... Скорее Вас обвинят сейчас или в сокрытии информации, или вообще в балабольстве :) Вас по-русски нормально попросили указать конкретную существующую СУБД, которая позволяет НАСТОЛЬКО сжимать данные. Причем без ущерба быстродействию, желательно... (Ибо никто не хочет очередного "неожиданного" применения "rar"-а для онлайн архивирования, а потом разархивирования файла БД :) ) Жаль, что ответа мы не получили. Уж извините, но фразу о "пока секретной и пока несуществующей разработке, которая перевернет ваши представления о мире" я бы не стал воспринимать как конкретный ответ. (Ни в чем Вас не обвиняю. Если пока что информация закрытая - значит, пока закрытая.) Но за ссылку спасибо - обязательно постараюсь заглянуть на сitforum после 12-го. Кстати, Вы бы тоже могли разместить тут ссылку на описанные материалы - думаю, что это многим будет очень интересно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2006, 19:14 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Да почему перевернёт. Вон Sybase IQ есть. Тож неплохая штука. ........... Причем без ущерба быстродействию, желательно... Прототип есть. Работающий и реально существующий. Никакого ущерба быстродействию, а наоборот его увеличение. Целью исследований было не достижение максимального сжатия как такового, а увеличение при этом и скорости выполнения аналитических запросов (например ROLLUP, CUBE, GROUPING SET), вычисления агрегатов и др. Мы об этом частично рассказывали в прошлом году на той же конференции. Но за ссылку спасибо - обязательно постараюсь заглянуть на сitforum после 12-го. Кстати, Вы бы тоже могли разместить тут ссылку на описанные материалы - думаю, что это многим будет очень интересно. Хорошо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2006, 19:38 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
2 Виктор Сакович: Если Cognos не имеет особого отношения к хранилищу данных, то тогда что Вы делаете в этом топике? Я не говорю что Cognos нужно внедрять не делая при этом реляционного хранилища. Реляционное хранилище просто не является обязательным условием для успешного внедрения Cognos. И не стоит забывать, что OLAP-клиент работает поверх многомерной СУБД формата Cognos. 2 Глеб: единственный конкурент у него это комплексное решение от компании Oracle. Оригинальная оценка :) Представляю себе новый магический квадрант Gartner, в котором представлены только Cognos и Oracle... если требуется только BI то подойдет и когнос. Примечание редактора: Глеб имеет в виду, что если требуется еще и хранилище данных, то нужно использовать реляционную БД Oracle, что вполне логично. пришел к однозначному выводу что надо брать все решение от одного поставщика, выбрал Оракл (особенно учитывая новые версии продуктов Оракл выходящих в 2007г.). В рейтингах аналитическая функциональность Oracle не занимает высоких мест... Новые версии 2007 года ты уже видел, или только читал рекламу? Ну ладно, пока это все слова, вот когда сделаешь прототип аналитической системы на Oracle BI - тогда посмотрим, стоящая это вещь или нет. Цена сопровождения и развития конечного комплекса в составе BI, CPM и Portal будет на порядок меньше. Возврастает оперативность обработки и модификации комплекса, сужаются профили специалистов Типа наймете студента-ораклиста, который за 300 долларов в месяц будет все поддерживать, и еще переведет вашу систему 1С на платформу Oracle :) На мой взгляд, РСУБД Oracle и Oracle BI - это разные технологии, задачи у них слишком разные, требуют даже разного уровня образования и опыта, и вряд ли хороший специалист по РСУБД будет одновременно хорошим специалистом по BI/CPM. 2 Андрей Прохоров: Я считаю что в PowerPlay multiple write access is NOT needed. Закачка данных в OLAP-куб (в те или иные ячейки куба) не производится несколькими процессами одновременно. Тогда какой смысл ссылаться на стандарт, которому Вы не считаете нужным следовать? Стандарт FASMI не требует от OLAP-системы многопользовательского ввода данных в ячейки куба. Похоже Вы просто спутали термин OLAP с термином OLTP (в OLTP-системе действительно нужно поддерживать многопользовательский ввод данных). 2 pavelvp: Не знаю как там и что делает Когнос, но исходные данные, характерные для таких задач, можно пожать раз в 10 (а то и больше) даже в "исходном" реляционном виде. Причём вместе с индексами. В экспериментах на реальных хранилищах (реляционных) мы получали 16-ти кратное сжатие. У Cognos нет цели делать сжатие данных. Самое главное - гибкость и интерактивность при работе с отчетами, и высокая скорость отклика. При этом кубы получаются компактными, и это приятно. Просто хотел сказать, что запихнуть 700М в 50М вполне реально при некоторых условиях... А может ли Ваша СУБД помочь тем, у кого компьютер без CD ROM? То есть ужать 700 мегабайт в 1.3 мегабайт? (я имею в виду что размер 50 мегабайт - это не архивирование данных, а рабочее состояние с 5-секундным откликом на запрос, а 1.3 мегабайта - это архивированное состояние, из которого надо будет данные развернуть в рабочие 50 мегабайт). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2006, 20:26 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
JuriiСтандарт FASMI не требует от OLAP-системы многопользовательского ввода данных в ячейки куба. Похоже Вы просто спутали термин OLAP с термином OLTP (в OLTP-системе действительно нужно поддерживать многопользовательский ввод данных). Не я привел ссылку на этот "стандарт", так что если кто-то чего-то не понимает так это явно Вы. "SHARED means that the system implements all the security requirements for confidentiality (possibly down to cell level ) and, if multiple write access is needed, concurrent update locking at an appropriate level." После утверждения, что: JuriiCognos имеет функциональность OLAP и соответствует стандарту FASMI Попытки аппелирования к тому, что авторы "стандарта" чего-то не понимают выглядят просто жалко. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2006, 21:57 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
"когда я вижу как они мажут туда майонез, я готов убить" (с) Джимми Тюльпан, 9 ярдов В смысле прошу прощения за офф-топ. JuriiНеужели узнали что Cognos имеет функциональность OLAP и соответствует стандарту FASMI ( http://www.olapreport.com/fasmi.htm )? Серьезно? И как давно имеет и соответствует? Кстати, за какие заслуги OLAP Report были причислена к лику.. то есть к стандартизующим организациям? По теме: Jurii, какое Вы решение предлагаете по вопросу в топике? Про OLAP я кажется понял, как строить хранилище? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.04.2006, 22:23 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
MSTR_FanПо теме: Jurii, какое Вы решение предлагаете по вопросу в топике? Про OLAP я кажется понял, как строить хранилище? Простите, что влажу в вопрос не ко мне лично... Не знаю, согласится ли со мной Юрий, но мое мнение - Хранилище надо строить ИНДИВИДУАЛЬНО и за отдельные деньги. :) Тут уже специалиста нанимать надо, а не на форуме совета спрашивать :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2006, 11:42 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
мнение MSTR_FanПо теме: Jurii, какое Вы решение предлагаете по вопросу в топике? Про OLAP я кажется понял, как строить хранилище? Простите, что влажу в вопрос не ко мне лично... Не знаю, согласится ли со мной Юрий, но мое мнение - Хранилище надо строить ИНДИВИДУАЛЬНО и за отдельные деньги. :) Тут уже специалиста нанимать надо, а не на форуме совета спрашивать :) Вы действительно не в тот вопрос залезли. Читать ветку надо сначала....... :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2006, 12:07 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
JuriiТо есть ужать 700 мегабайт в 1.3 мегабайт? (я имею в виду что размер 50 мегабайт - это не архивирование данных, а рабочее состояние с 5-секундным откликом на запрос, а 1.3 мегабайта - это архивированное состояние, из которого надо будет данные развернуть в рабочие 50 мегабайт). Честно говоря, не совсем понял вопроса... Но пожать данные без потерь в 500 раз, в общем случае ИМХО невозможно :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2006, 12:31 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
2 Андрей Прохоров: "SHARED means that the system implements all the security requirements for confidentiality (possibly down to cell level) and, if multiple write access is needed, concurrent update locking at an appropriate level." После утверждения, что: Cognos имеет функциональность OLAP и соответствует стандарту FASMI Попытки аппелирования к тому, что авторы "стандарта" чего-то не понимают выглядят просто жалко. Спасибо за цитату стандарта FASMI. Я не говорил, что авторы этого стандарта что-то не понимают, я говорил что Вы не понимаете разницу между OLAP и OLTP. Cognos позволяет настраивать права доступа к ячейкам OLAP-куба (cell level). Далее в стандарте говорится, что "если требуется multiple write access и т.д.", но мы ведь понимаем что в OLAP/BI не требуется "multiple write access". В случае если бы авторы стандарта хотели обязать настоящие OLAP-сервера поддерживать "multiple write access", они бы написали, что "multiple write access is required". 2 MSTR_Fan: Неужели узнали что Cognos имеет функциональность OLAP и соответствует стандарту FASMI ( http://www.olapreport.com/fasmi.htm )? Серьезно? И как давно имеет и соответствует? Кстати, за какие заслуги OLAP Report были причислена к лику.. то есть к стандартизующим организациям? Cognos соответствует стандарту FASMI как минимум с 1999 года, когда я впервые с ним познакомился... А что касается авторитета OLAPReport - если Вы их не уважаете - это Ваше право, но почему то их недешевые отчеты покупают... По теме: Jurii, какое Вы решение предлагаете по вопросу в топике? Про OLAP я кажется понял, как строить хранилище? Автор дискуссии говорил, что ему "Необходимо найти OLAP решение которое может бать основано на хранилищах или той или другой СУБД". На этот вопрос топика, по выбору OLAP-решения, я предлагаю посмотреть в сторону Cognos. А на Ваш вопрос по поводу того, как строить хранилище, могу сказать, что на это влияет выбор BI-инструментария. Если инструментарий является OLAP-продуктом, то за прототип хранилища можно взять хоть базу данных 1С, если не является - то надо строить хранилище по схеме звезда. 2 pavelvp: Честно говоря, не совсем понял вопроса... Но пожать данные без потерь в 500 раз, в общем случае ИМХО невозможно :-) Возможно что в общем случае - невозможно, но вот в частных случаях, как показывает практика, это вполне реально... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2006, 20:41 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
JuriiВозможно что в общем случае - невозможно, но вот в частных случаях, как показывает практика, это вполне реально... У меня есть серьёзные сомнения насчёт "без потерь". Из этих 1.3М можно восстановить в полном объёме исходные 700? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2006, 20:57 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
2 pavelvp: У меня есть серьёзные сомнения насчёт "без потерь". Из этих 1.3М можно восстановить в полном объёме исходные 700? Да, можно. Реально в моем примере это были 7 миллионов записей по 700 тысячам юр. лиц, и в архивном файле размером 1.3M помещался куб размером 50M, в котором без потери детализации хранились все 7 миллионов записей (700M). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2006, 21:05 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
JuriiСпасибо за цитату стандарта FASMI. Я не говорил, что авторы этого стандарта что-то не понимают, я говорил что Вы не понимаете разницу между OLAP и OLTP. Cognos позволяет настраивать права доступа к ячейкам OLAP-куба (cell level). Далее в стандарте говорится, что "если требуется multiple write access и т.д.", но мы ведь понимаем что в OLAP/BI не требуется "multiple write access". В случае если бы авторы стандарта хотели обязать настоящие OLAP-сервера поддерживать "multiple write access", они бы написали, что "multiple write access is required". Чем дальше, тем смешнее. Во всем "стандарте" утверждения "is our key requirement" и "system must provide" относятся только к поддержке иерархий. В результате фривольной трактовки Вы свели "стандарт" к туманному требованию поддержки многмерного взгляда на данные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2006, 21:49 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
JuriiCognos позволяет настраивать права доступа к ячейкам OLAP-куба (cell level). Далее в стандарте говорится, что "если требуется multiple write access и т.д.", но мы ведь понимаем что в OLAP/BI не требуется "multiple write access". В случае если бы авторы стандарта хотели обязать настоящие OLAP-сервера поддерживать "multiple write access", они бы написали, что "multiple write access is required". По моему скромному мнению, в описании ТЕСТА FASMI под частью SHARED имеется ввиде не "если Jurii считает нужным", а "если такая необходимость диктуется условиями проекта". Проектов где требуется такая модель доступа масса - посмотрите хотя бы на методологию Active Data Warehouse от Teradata - создание хранилища, пополняемого near real-time одновременно из множества источников данных и используемого для выполнения большого (соизмеримого с числом транзакций в оперативной системе) количества сложных тактических запросов. Как в таком случае использовать Cognos? Jurii, Вы сами себе противоречите - выдвигаете такие высокие требования к системе (а ТЕСТ FASMI - это высокие требования IMHO) и предлагаете для этого самый кондовый MOLAP. Даже сам Cognos отвечая новым потребностям делает ставку на ROLAP решение - пора бы и Вам квалификацию повысить. К слову, o FASMI: уважаемый, СТАНДАРТ - это официальный регламентирующий документ или определение, утвержденное государственной или международной стандартизующей организацией. Стандарты выпускают ANSI, ISO, IEEE и другие, но никак не OLAP Report, OLAP Survey, Gartner и прочие. Если бы разделение стандарт/частное мнение базировалось на авторитете - сложно представить в каком мире мы бы с Вами жили. JuriiЕсли инструментарий является OLAP-продуктом, то за прототип хранилища можно взять хоть базу данных 1С, если не является - то надо строить хранилище по схеме звезда. То есть, если я Вас правильно понял, вся поддержка историчности возлагается на OLAP средство, в Вашем случае - Cognos PP? Расскажите пожалуйста, какие средства борьбы с SCD там есть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.04.2006, 21:52 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Jurii Если инструментарий является OLAP-продуктом, то за прототип хранилища можно взять хоть базу данных 1С, если не является - то надо строить хранилище по схеме звезда. Ну это Вы просто на основы DWH замахнулись, если для Вас база 1С - это прототип хранилища. Может быть, Вы всё-таки классиков почитаете, Инмона, Кимбалла, вместо того, чтобы веселить народ на форуме своей невежественностью. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.04.2006, 09:56 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Ребята, хочу снова подключиться к дискуссии. Я ознакомился с Cognos несколько дней назад, спасибо Юрию. Могу некоторые мысли озвучить. После беседы с Юрием его специалистами я сдел таблицу возможностей этой системы и сравниваю с другими имеющимися. Цель моя сводится к поиску ПО которое может базироваться на хранилищах разных производителей (MS SQL и Oracle). Как мне сообщил Юрий, у Cognos есть проблемы с подключением к OLAP Oracle, а к OLAP MS доступ имеется только к версии 2000. Что не понравилось (самое критичное что нашел) - показать детализацию получаемых агрегатных значений Cognos не умеет. Поясняю - есть срез в котором показывается число продаж за искомый период, оно например равняется 50. Так вот из чего складывается это число Cognos рассказать не может! Для этого нужно создавать специальные отчеты, а про динамический Drillthrough речи не идет. Это очень не удобно! В остальном мне система понравилась. Всякая фильтрация, экспорт получаемых данных в другие форматы мне понравилась. Удобно что Cognos создает на основе внешних хранилищ свои кубы, производительность их я пока не пробовал. Еще порадовала наличие руссифицированного интерфейса (для конечных пользователей очень удобно). Вообщем если есть средства, то в принципе посмотреть в сторону Cognos стоит. Но ведь невсегда есть необходимость иметь всю функциональность которую предоставляет эта система. Есть множество примеров когда от такого рода системы требуется быть только клиентом к уже существующему OLAP серверу. Так что нужно десять раз подумать... И еще одно, про объемы создаваемых Cognos кубов... У вас что, мало места на винтах? Какая разница будет куб занимать 700Мб или 400Мб, сейчас могу поспорить что люди которые покупают такие решения не стеснены объемами жестких дисков на серверах. К чему такие подробности на сколько сжимается информация? Просто нужно провести эксперимент - построить куб Cognos, сделать его перестройку? а потом отключить хранилище. Если все будет работать и правильно работать, то Юрий был прав, иначе нет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.04.2006, 17:32 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Kaniovski И еще одно, про объемы создаваемых Cognos кубов... У вас что, мало места на винтах? Какая разница будет куб занимать 700Мб или 400Мб, сейчас могу поспорить что люди которые покупают такие решения не стеснены объемами жестких дисков на серверах. К чему такие подробности на сколько сжимается информация? Просто нужно провести эксперимент - построить куб Cognos, сделать его перестройку? а потом отключить хранилище. Если все будет работать и правильно работать, то Юрий был прав, иначе нет А если речь не о мегабайтах, а о сотнях гигабайт реаляционного ХД, тогда Юрина программка просто находка: любой отчет на любом объеме за пять секунд Лучше, как независимый эксперт, протестируйте, объем кубов по сравнению с исходными данными, время выполнения запросов и результаты в форум. Будем благодарны. Хотя Юра потом все-равно скажет вам: JuriiЧто же Вы хотите - Вы не прошли даже одночасового тренинга по Cognos PowerPlay, не видели ни одной квалифицированной демонстрации возможностей PowerPlay. Поэтому и гибкости Вы там не обнаружили... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.04.2006, 18:11 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
2 Kaniovski: Я ознакомился с Cognos несколько дней назад, спасибо Юрию После беседы с Юрием его специалистами Интересно, с каким же Юрием Вы общались? :) Тут какое-то недоразумение, я с Вами не общался... Я лишь получил от Вас письмо на адрес cognos@narod.ru , ответил, но ответа от Вас не получал... Так что видимо Юриев, которые занимаются Когносом, в России несколько... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.04.2006, 18:26 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Jurii Интересно, с каким же Юрием Вы общались? :) Тут какое-то недоразумение, я с Вами не общался... Я лишь получил от Вас письмо на адрес cognos@narod.ru , ответил, но ответа от Вас не получал... Так что видимо Юриев, которые занимаются Когносом, в России несколько... Блин, прямо детектив какой-то. Агата Кристи отдыхает........ Или может, таким образом Jurii заранее отвергает плачевные для его системы и авторитета результаты тестирования Kaniovski??? Тогда мы еще с большим нетерпением ждем результатов тестов Kaniovski.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.04.2006, 18:44 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
2 Андрей Прохоров: Чем дальше, тем смешнее. Во всем "стандарте" утверждения "is our key requirement" и "system must provide" относятся только к поддержке иерархий. В результате фривольной трактовки Вы свели "стандарт" к туманному требованию поддержки многмерного взгляда на данные. Не хочется продолжать пустой флейм. Думаю никто не станет спорить, что есть важные критерии (типа среднего отклика не более 5 секунд), а есть экзотика, которой в природе не бывает (типа многопоточного пополнения OLAp-куба свежими данными). 2 MSTR_Fan: методологию Active Data Warehouse от Teradata - создание хранилища, пополняемого near real-time одновременно из множества источников данных и используемого для выполнения большого (соизмеримого с числом транзакций в оперативной системе) количества сложных тактических запросов. Как в таком случае использовать Cognos? А вот в этом нет ничего сложного, у меня в практике были подобные проекты. Cognos позволяет иметь для одного OLAP-куба множество источников данных (таблиц фактов/измерений), обновление (в частности - инкрементальное обновление) куба можно запускать очень часто либо по триггеру СУБД, и при этом можно обеспечить, чтобы куб во время обновления был доступен 24 часа в сутки, 7 дней в неделю. Но все это я не называю многопоточным пополнением куба, есть только один процесс (который можно распараллелить по процессорам), обрабатывающий множество источников данных. Jurii, Вы сами себе противоречите - выдвигаете такие высокие требования к системе (а ТЕСТ FASMI - это высокие требования IMHO) и предлагаете для этого самый кондовый MOLAP Вы не знакомы с функциональностью Cognos. Когда познакомитесь, поймете, что в моих словах нет противоречия и требованиям FASMI Cognos соответствует. Даже сам Cognos отвечая новым потребностям делает ставку на ROLAP решение - пора бы и Вам квалификацию повысить Вы немного путаете Cognos 8 и ROLAP... В Cognos 8 используется универсальный семантический слой метаданных, который позволяет пользователям работать как в режиме ROLAP, так и в режиме MOLAP, и дает в частности возможность делать сложнейшее форматирование у отчетов, которые созданы на основе MOLAP (это то чего не хватает всем известным OLAP-клиентам). То есть, если я Вас правильно понял, вся поддержка историчности возлагается на OLAP средство, в Вашем случае - Cognos PP? Расскажите пожалуйста, какие средства борьбы с SCD там есть? В свое время на форуме была дискуссия на тему поддержки SCD в Cognos. Не хочется повторяться. Пример со структурой 1С может не самый удачный если есть задача поддержки SCD, хотя 1С 8 вроде как приблизилась к этому, там есть элементы темпоральности (как в ERP-системах). Еще раз повторюсь, что я сам руковожу проектами по созданию ХД с поддержкой SCD, поверх которых ставлю Cognos, но хранилища не всегда нужны... 2 Виктор Сакович: Ну это Вы просто на основы DWH замахнулись, если для Вас база 1С - это прототип хранилища. Может быть, Вы всё-таки классиков почитаете, Инмона, Кимбалла Когда-то не было MOLAP, и все обходились простыми реляционными запросами, создавались хранилища. Но когда появился MOLAP (который можно назвать многомерным хранилищем данных), понятия о необходимости ХД изменились... Постарайтесь расширить свой кругозор, не замыкайтесь на MSTR, которая без оптимизированного ХД не умеет работать. Есть еще и другие системы, тот же Cognos. 2 Kaniovski: показать детализацию получаемых агрегатных значений Cognos не умеет. Поясняю - есть срез в котором показывается число продаж за искомый период, оно например равняется 50. Так вот из чего складывается это число Cognos рассказать не может! Это неправда, Вас злостно обманули. Cognos автоматом делает DrillThrough через тот запрос, который соответствует таблице фактов. Вообщем если есть средства, то в принципе посмотреть в сторону Cognos стоит Примечание: автор имеет в виду, что если есть лишняя пара тысяч долларов, уже можно внедрить аналитическую систему Cognos на основе лицензионного ПО (а если средств больше - тем круче получится система, тем больше можно подключить к ней пользователей). Но ведь невсегда есть необходимость иметь всю функциональность которую предоставляет эта система. Есть множество примеров когда от такого рода системы требуется быть только клиентом к уже существующему OLAP серверу. Так что нужно десять раз подумать... Не понял вопроса... Многие компании имеют свои OLAP-сервера (Microsoft AS, Oracle Express, Hyperion Essbase, SAP BW) и используют ограниченную функциональность Cognos (функциональность OLAP-клиента). Какая разница будет куб занимать 700Мб или 400Мб, сейчас могу поспорить что люди которые покупают такие решения не стеснены объемами жестких дисков на серверах Ну как сказать... Если взять малый бизнес, или некоторые бедные гос. структуры, у которых денег совсем мало, то они 1-2 тыс. долларов на Cognos наскребут, а железо новое закупать не захотят. 2 Bormoglot: А если речь не о мегабайтах, а о сотнях гигабайт реаляционного ХД, тогда Юрина программка просто находка: любой отчет на любом объеме за пять секунд Да, Вы правы, хотя те у кого хранилища размером сотни гигабайт это поняли давно и давно используют Cognos для получения среднего отклика не более 5 секунд. Или может, таким образом Jurii заранее отвергает плачевные для его системы и авторитета результаты тестирования Kaniovski??? Тогда мы еще с большим нетерпением ждем результатов тестов Kaniovski.... Было бы что отвергать Видно же что г-н Kaniovski введен в заблуждение каким-то новичком, который незаконно использует мое имя :) Ну ладно, это излечимо, я в меру своих сил помогу г-ну Kaniovski докопаться до истины. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.04.2006, 20:02 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
JuriiCognos позволяет иметь для одного OLAP-куба множество источников данных (таблиц фактов/измерений), обновление (в частности - инкрементальное обновление) куба можно запускать очень часто либо по триггеру СУБД, и при этом можно обеспечить, чтобы куб во время обновления был доступен 24 часа в сутки, 7 дней в неделю А вот это очень интересно, а можно о механике процесса подробнее? Как обеспечивается одновременное чтение-запись? Блокировки, версионнность, что-то ещё? JuriiВы немного путаете Cognos 8 и ROLAP... В Cognos 8 используется универсальный семантический слой метаданных, который позволяет пользователям работать как в режиме ROLAP, так и в режиме MOLAP... Боже упаси, я о Cognos 8 вообще ни словом... :-) Но раз Вы сказали, будем считать что в Cognos 8 - это не ROLAP. JuriiЕще раз повторюсь, что я сам руковожу проектами по созданию ХД с поддержкой SCD, поверх которых ставлю Cognos, но хранилища не всегда нужны... Jurii Если инструментарий является OLAP-продуктом, то за прототип хранилища можно взять хоть базу данных 1С, если не является - то надо строить хранилище по схеме звезда. Я запутался. Скажите, если я пользуюсь OLAP продуктом, нужно ли мне строить хранилище? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.04.2006, 21:55 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Kaniovski Что не понравилось (самое критичное что нашел) - показать детализацию получаемых агрегатных значений Cognos не умеет. Поясняю - есть срез в котором показывается число продаж за искомый период, оно например равняется 50. Так вот из чего складывается это число Cognos рассказать не может! Простите, если я Вас правильно понял, то в России есть не только несколько Юриев, продвигающих Когнос но и несколько Когносов, продвигаемых Юриями на мой взгляд, то, что Вы упомянули, как раз в системе присутствует и является одним из ее достоинств, или я что-то не правильно понимаю?:) мне кажется Вам необходимо еще раз пообщаться с Юрием.. Kaniovski Какая разница будет куб занимать 700Мб или 400Мб, сейчас могу поспорить что люди которые покупают такие решения не стеснены объемами жестких дисков на серверах. Если не ошибаюсь от объема куба зависит объем занимаемой при работе с ним оперативной памяти-а это уже может быть критично... Если ошибаюсь, прошу Юрия меня поправить... Kaniovski Но ведь невсегда есть необходимость иметь всю функциональность которую предоставляет эта система. Есть множество примеров когда от такого рода системы требуется быть только клиентом к уже существующему OLAP серверу. Так что нужно десять раз подумать... .....а можно взять Excel... и прекрасно в нем считать - у нас в компании был целый отдел, который этим занимался теперь там 3 человека: руководитель, заместитель и исполнитель Bormoglot протестируйте, объем кубов по сравнению с исходными данными, время выполнения запросов и результаты в форум. Будем благодарны. Как Вы предложите оценить объем исходных данных в Oracle'овом WH?? 1. объем экспортированной таблицы/представления источника данных? 2. объемы всех исходных таблиц (вкл. справочные) 3. какую предложите создать иерархию измерений в кубе??? объем куба от этого зависит.... Jurii Вообщем если есть средства, то в принципе посмотреть в сторону Cognos стоит Примечание: автор имеет в виду, что если есть лишняя пара тысяч долларов, уже можно внедрить аналитическую систему Cognos на основе лицензионного ПО (а если средств больше - тем круче получится система, тем больше можно подключить к ней пользователей). ??? MSTR_Fan Я запутался. Скажите, если я пользуюсь OLAP продуктом, нужно ли мне строить хранилище? мне кажется все зависит от Ваших задач, количества источников данных и др. входящих условий проекта... сложно ответить на вопрос-"нужно ли мне хранилище данных?" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.04.2006, 09:06 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
KaniovskiРебята, хочу снова подключиться к дискуссии. Я ознакомился с Cognos несколько дней назад, спасибо Юрию. Могу некоторые мысли озвучить. После беседы с Юрием его специалистами я сдел таблицу возможностей этой системы и сравниваю с другими имеющимися. Цель моя сводится к поиску ПО которое может базироваться на хранилищах разных производителей (MS SQL и Oracle). Как мне сообщил Юрий, у Cognos есть проблемы с подключением к OLAP Oracle, а к OLAP MS доступ имеется только к версии 2000. Что не понравилось (самое критичное что нашел) - показать детализацию получаемых агрегатных значений Cognos не умеет. Поясняю - есть срез в котором показывается число продаж за искомый период, оно например равняется 50. Так вот из чего складывается это число Cognos рассказать не может! Для этого нужно создавать специальные отчеты, а про динамический Drillthrough речи не идет. Это очень не удобно!Ну вот и правда всплыла ... 90% слов сейла - пыль в глаза. В реальности все совершенно иначе. Cognos - это куча продуктов, некоторые из которых стоят 2000$ - при этом уступают в функциональности текстовому редактору ;) Если же вам нужно использовать несколько источников и динамический DrillThrough - ищите настоящий продукт с поддержкой ROLAP и MOLAP. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2006, 12:37 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Guestz KaniovskiРебята, хочу снова подключиться к дискуссии. Я ознакомился с Cognos несколько дней назад, спасибо Юрию. Могу некоторые мысли озвучить. После беседы с Юрием его специалистами я сдел таблицу возможностей этой системы и сравниваю с другими имеющимися. Цель моя сводится к поиску ПО которое может базироваться на хранилищах разных производителей (MS SQL и Oracle). Как мне сообщил Юрий, у Cognos есть проблемы с подключением к OLAP Oracle, а к OLAP MS доступ имеется только к версии 2000. Что не понравилось (самое критичное что нашел) - показать детализацию получаемых агрегатных значений Cognos не умеет. Поясняю - есть срез в котором показывается число продаж за искомый период, оно например равняется 50. Так вот из чего складывается это число Cognos рассказать не может! Для этого нужно создавать специальные отчеты, а про динамический Drillthrough речи не идет. Это очень не удобно!Ну вот и правда всплыла ... 90% слов сейла - пыль в глаза. В реальности все совершенно иначе. Cognos - это куча продуктов, некоторые из которых стоят 2000$ - при этом уступают в функциональности текстовому редактору ;) Если же вам нужно использовать несколько источников и динамический DrillThrough - ищите настоящий продукт с поддержкой ROLAP и MOLAP. красиво красиво учитывая что я не зарегистрированный пользователь такую ситуацию можно было предположить, но надеялся что до такого мы не дойдем... Господа-ЭТО НЕ МОЕ сообщение!!! и если с "Cognos - это куча продуктов, некоторые из которых стоят 2000$" я согласен, то про текстовый редактор мой "тезка" на мой взгляд погорячился :) в этой ветке уже идет не обсуждение реального вопроса а мутновато-грязный маркетинг... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2006, 13:07 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Guestzи если с "Cognos - это куча продуктов, некоторые из которых стоят 2000$" я согласен, то про текстовый редактор мой "тезка" на мой взгляд погорячился :)гипербола знаете ли :) Guestzв этой ветке уже идет не обсуждение реального вопроса а мутновато-грязный маркетинг...представьте, что я один из ботов Jurii'я, но не расхваливаю когнос ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2006, 13:52 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
2 MSTR_Fan: Cognos позволяет иметь для одного OLAP-куба множество источников данных (таблиц фактов/измерений), обновление (в частности - инкрементальное обновление) куба можно запускать очень часто либо по триггеру СУБД, и при этом можно обеспечить, чтобы куб во время обновления был доступен 24 часа в сутки, 7 дней в неделю А вот это очень интересно, а можно о механике процесса подробнее? Как обеспечивается одновременное чтение-запись? Блокировки, версионнность, что-то ещё? Идея состоит в том, что пользователи работают с кубом, в это время копия куба обновляется инкрементально (например из множества источников), когда обновление завершено, программным путем доступ к кубу перекрывается (например когда сервер обработал последний текущий запрос к кубу), куб физически удаляется, а обновленная копия кладется на место где лежит куб, и доступ опять открывается. Поскольку кубы у Cognos хранятся как файлы, удаление и перемещение файла - это операции, которые производятся мгновенно, практически независимо от размера куба. При этом у Cognos есть функциональность, которая в случае отсутствия доступа к серверу, перенаправляет запросы на параллельный сервер. Таким образом, в простом случае можно на пару-тройку секунд прекращать доступ к обновившемуся кубу, а в более продвинутой архитектуре не прекращать доступа ни на секунду. Я запутался. Скажите, если я пользуюсь OLAP продуктом, нужно ли мне строить хранилище? Практика показывает, что иногда в проекте надо решать проблему SCD, а иногда такой проблемы нет. В первом случае, если учетная система не поддерживает темпоральность, строить хранилище полезно. Во втором случае можно обойтись и бех хранилища. 2 настоящий Guestz: Если не ошибаюсь от объема куба зависит объем занимаемой при работе с ним оперативной памяти-а это уже может быть критично... Если ошибаюсь, прошу Юрия меня поправить... Поправляю. Объем (размер) куба не связан с размером оперативной памяти. Например если куб имеет размер 1 гигабайт, с ним легко можно работать на компьютере с оперативкой 256 мегабайт. А если использовать технологию тонкого клиента, то можно вообще не задумываться над вопросом оперативной памяти. если есть лишняя пара тысяч долларов, уже можно внедрить аналитическую систему Cognos на основе лицензионного ПО (а если средств больше - тем круче получится система, тем больше можно подключить к ней пользователей). ??? Если у предприятия есть пара тысяч долларов, то этого бюджета хватит чтобы купить лицензионное ПО Cognos - OLAP-сервер PowerPlay User (на это нужно меньше чем 2000$), и полезно к этому докупить средство класса Query & Reporting/ROLAP - Impromptu Administrator (PPU + IA стоят подороже чем 2000$, но не на много). Это ПО позволит создавать OLAP-кубы и аналитические отчеты на основе больших объемов данных (десятки-сотни миллионов записей), иметь при этом в среднем 5-секундный отклик в стиле OLAP (по стандарту FASMI), и кроме всего этого делать по расписанию всю стандартную корпоративную отчетность с высоким уровнем форматирования отчетов (с точностью до миллиметра). Вряд ли можно купить что-либо другое от другого производителя, даже за миллион долларов, что по функциональности было бы сильнее чем связка этих базовых модулей Cognos... Хочу отметить, что я не призываю кого-либо это покупать, просто рассказываю о лицензионной политике Cognos. PPU и IA - это модули, которые например не предоставляют ИНТЕРАКТИВНОГО доступа через Web-браузер к своим аналитическим моделям и отчетам. Поэтому зачастую проект начинается с PPU + IA, а потом докупается Web-компонента на столько то рабочих мест, для визуализации того что было сделано с помощью PPU + IA на корпоративном Web-портале. красиво красиво учитывая что я не зарегистрированный пользователь такую ситуацию можно было предположить, но надеялся что до такого мы не дойдем... Господа-ЭТО НЕ МОЕ сообщение!!! Чтобы таких казусов не возникало, надо регистрироваться. Но думаю что модераторы форума быстро вычислят злоумышленника, прикрывшегося Вашим именем. А его шутка про сравнение PPU + IA с текстовым редактором выдает его не слишком высокий уровень в области OLAP/BI. Не завидую его клиентам... 2 Ненастоящий Guestz: Если же вам нужно использовать несколько источников и динамический DrillThrough - ищите настоящий продукт с поддержкой ROLAP и MOLAP. Вышеупомянутые PPU + IA за примерно 2k$ позволяют делать DrillThrough из куба в любые реляционные источники (например пользователь стоя в кубе по продажам на ячейке может выбрать, либо сделать DrillThrough в ту базу, на основе которой был сделан этот куб, либо сделать DrillThrough в другую БД). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2006, 14:06 |
|
||
|
OLAP на хранилищах от разных СУБД
|
|||
|---|---|---|---|
|
#18+
Юрий зарапортовался даже по ценам. У Cognos нельзя строить кубы меньше чем за десятку килогрин. PPU - голый клиент. Transformer, который кубы строит - стОит от 7К. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2006, 14:44 |
|
||
|
|

start [/forum/topic.php?all=1&fid=49&tid=1870303]: |
0ms |
get settings: |
5ms |
get forum list: |
9ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
44ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
74ms |
get tp. blocked users: |
1ms |
| others: | 202ms |
| total: | 351ms |

| 0 / 0 |
