День добрый, коллеги!
Знает ли кто случайно о том, как BW использует Oracle - используется OLAPовский движок Оракла или нет (ROLAP или MOLAP)?

не используется.

так, я и думал, спасибо

там свой OLAP - движок на ABAP написанный...

значит тормозявее заметно (думается коэфициент - между двойкой и десяткой)

не скажи...

организация данных ( схема БД + индексы + агрегаты ) + оптимизация разборщика запроса под эту схему + паралелльность выполнения запросов + базовый фукнционал на СИ ( ядро ) дает очень неплохой результат...

могу поспорить, что связка oracle olap + business objects даст примерно тот же эффект, что и BW + Bex . Тут уже узким местом будет фронтэнд + сетка.

Ответ принят!
Я буду в это верить!

Я сравнивал MS OLAP с BW, так BW намного тормознение. Правда всего пара кубов было. Надеюсь, что с увеличением объёма BW своё отыграет.

ms olap с кубами типа MOLAP однозначно быстрее "чисто" bw. bw пользetn ROLAP - т.е. реляционную БД. MOLAP оптимизирован для многомерных запросов и построения агрегатов. Хотя, помнится, в BW в связке с ms analyzes services можно использовать MOLAP...

Интересно, кто-нибудь пробовал?

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

При попытке сравнить сразу же упираемся в железо. BW однозначно тяжелее чем ms - следовательно треболвательнее к железу. и как сравнивать то? на одном дохлом компе запускаем и то и то? ну получим результат...

А как посмотрит ms molap на терабайтные базы и тысячи реальных пользователей? Ведь не секрет, что ms просто обламается на больших объемах и нагрузке быстрее, чем oracle ... И как тут сравнивать?

В общем я бы не стал столь категорично утвреждать, так как классы приложений не равные. Это то же что и сравнивать нашу машину и иномарку ( не джип) - наша по [censored] проедет и не поперхнется, а иномарка застрянет... но это же не значит, что иномарка хуже...

Надо рассматривать все в комплексе. не только скорострельность СУБД но и сетку, фронтэнд. А вот тут очень сложно провести адекватные сравнения.

Я не защищаю архитектуру BW, я против категоричных сентенций типа бога нет - а кто это может доказать...

В догонку. А не могу бы уважаемый AnS1 привести ссылку хотя бы на один формальный тест для BW и для ms molap ? например для tpc-d ? Просто если есть такая информация , то грех ею не поделиться с общественностью...

Хе хе.
Надо поискать в инете для MS OLAP документы типа саповских "SAP BW Multi-Terabyte Evaluation & Feasibility Test" и сравнить

Только вот кажется мне, что MS OLAP и Multi-Terabyte - вещи несовместные

Смех и слезы
Есть подобный документ для MS?
The 5 Terabyte Showcase - Scalability with SAP BW

есть такой сайт www.tpc.org
( http://www.tpc.org/tpch/results/tpch_perf_results.asp )
и там проводятся стандартные тесты проивзодительности OLAP для СУБД. и прошу обратит внимаени на категорию 10,000 GB Results... дык там кроме oracle и ibm db2 вообще никого нет
доминанта ms sql видна до 100 GB Results ( с 6 по 10 место)
после 300 GB Results скатилось до 8 а после 3,000 GB Results его вообще в 10 - ке нет ни на каком оборудовании...

а вот если почитать про 5 - терабайтный тест для BW то становиться страшно от того, на каких мощностях эта сволочь способна пахать... и как пахать.. по данным WINTER CORPORATION которая собственно проводило один из таких тестов " The database occupied a total 5.5 terabytes of storage, which included 1.1 terabytes of detail data, 0.2 terabytes in aggregates, and 0.6 terabytes as Oracle indexes. "

Софт - SAP Business Information Warehouse version 3.0B, Solaris 2.9, Oracle 9i version 9.2.0, and Veritas Volume Manager 3.2

про тест загрузки - пропущу скажу что грузилось 580 million records

про результаты

Simulate a multi-user query workload by running many reports simultaneously. There were 15 different sales reports that were run continuously in a loop using random attributes for report filtering. To simulate multiple users, there were several instances of the loop running in parallel.

что означает it was determined that 20,000 users would generate 158,991 navigation steps in one hour, running simple database requests. The goal of the workload simulation was to meet or exceed the number of navigation steps calculated for the 20,000 users.


и вот какие результаты

- Simulation Test #1 356,000 navigation steps
Average Response Time:
2.5 seconds (aggregates)

Simulation Test #2 208,000 navigation steps
Average Response Time:
5 seconds (aggregates)
335 seconds (cubes)

Про серваки и т.д. можно почитать самим...

упс.. пропустил про собственно тесты

Test #1. In the first simulation test, 660 parallel connections processed 5 loops each of all 15 sales reports for a total of 49,500 reports. The queries were tuned to access aggregate views generated from the InfoCubes. Each aggregate ranged in size from 12 to 200,000 rows and the total amount of aggregate data accessed was 7GB. None of the reports ran against detailed data.
Test #2. In the second simulation, 550 connections were established. Of these, 540 processed reports that accessed aggregate views, as in the previous run. In the remaining 10 connections, one of the fifteen reports was modified to obtain results by accessing detailed data stored in an InfoCube.

The 540 connections unchanged from the prior simulation each processed 5 loops of 15 reports. The remaining 10 connections ran 2 loops per connection. This provided a total of 40,800 reports, of which 20 reports accessed detailed InfoCube data. A single InfoCube contained approximately 145 million rows of data.