2 Владимир Иванов

Мне наверное повезло. я работал с несколькими телекомовскими компаниями и везде было по-честному. Хранилище было на Oracle и данные оттуда читали запросами все кому не лень. (Собственно это и было обычно предпосылкой создания OLAP системы - разгрузить хранилище)
Distinct Count делали. Тогда еще 2 миллионов абонентов не было, но и техника была послабее. не то что сейчас. Довольно шустро работало, со своими правда особенностями. :)

2 Владимир Иванов
Дык и было внедрение MOLAP (Express) для разгрузки хранилища.

А насчет того что MV не помогают, в Oracle 10g есть теперь интересная фича. Я тут ее упомянул чуть выше. Называется QUERY EQUIVALENCE. Это расширение Query Rewrite.

QR работает как? Мы создаем сколько-то MV на наши таблицы. Можно создать на одну таблицу несколько MV с разной степенью детализации. И когда пишем select к исходным таблицам, оптимизатор SQL может решить что данные лучше взять не из таблиц исходных, а из одного или нескольких MV. Запрос автоматом переписывается. То есть участие программиста тут не требуется.

QE - это более хитрая штука. DBA может прописать, что существует MOLAP куб, который содержит данные такие же, как и дает запрос по некоторым реляционным таблицам. И вот в момент селекта по реляционным таблицам оптимизатор может переписать запрос так, что обращение произойдет к MOLAP кубу, а не к таблице. Естественно MOLAP часто отрабатывает запрос гораздо быстрее, чем group by.

Надо экпериментировать, я много раз видел как таблицы с десятком миллионов записей при помощи набора MV очень шустро опрашиваются. Это вопрос настройки. Так что не стоит списывать ROLAP со счетов.

2 Владимир Иванов

Судя по тому, что вы пишите видно, что MV в Oracle как серьезно отставали от IV в MS SQL так и отстают.
Судя по тому, что вы пишите, я плохо объяснил идею.

Я имел удовольствие разворачивать Discoverer с использованием оптимизации под MV. Проблем хватило, в том числе обновление MV по расписанию, в MS SQL обновление IV всегда real-time.
В Discoverer обновление materialized views (MV) по расписанию - это дефолтный вариант, который меньше всего грузит сервер, особеннно в случае большой транзакционной загрузки. К тому же, обычно подразумевается что хранилища обновляются по расписанию.
Но и в Discoverer в частности и в MV вообще существуют разные режимы обновления и работы. Можно сделать чтобы MV обновлялось в real-time, можно по времени, можно по команде. Использоваться они могут тоже в нескольких режимах. Например, оптимизатор может брать данные из MV только если они соответствуют тому, что в таблице. Или может брать данные всегда. Это в том случае, когда несколько новых записей в таблице не сказываются на трендах.
Что будет делать IV если у нас нагрузка 1000 транзакций в минуту? будет пытаться обновлять IV 1000 раз в минуту? Тогда понятно почему на 10 миллионах записей все это уходит в даун. А если бы можно было сделать отложенное обновление IV - это резко бы разгрузило систему.

Оптимайзер MS SQL без всяких действий со стороны админа цепляет подходящий IV, если он может помочь в расчетах и цепляет весьма разумно (см. Query Plan). Я этот прием даже иногда использую в Real-time OLAP и ROLAP отказываясь от кривоватых автоматических IV и создавая свои руками. Оптимайзер их подбирает сам.
Ну так и в случае MV оптимизатор без всяких действий админа цепляет нужный MV (или несколько).
Насчет весьма разумного оптимизатора - не знаю как в MS, но если поищите в форуме Oracle по ключевым словам "CBO" или "оптимизатор" найдете, что в сложных случаях оптимизаторы могут ошибаться. И админы с этим пытаются бороться. Думаю что в MS тоже самое, просто вы не сталкивались с такими сложными случами.

А QE вообще-то не производит вид божественного откровения. Поскольку MV и IV все такие же плоские как таблицы при многомерных запросах по многим мемберам они быстро выпадают из актуальности и эффект от них нивелируется.
Вот тут видимо вы и не поняли идею Query Equivalence (QE).
Может ли оптимизатор в MS при например
select shop,sum(amount) from sales group by shop
автоматом переписать этот запрос в MDX и отправить его в MS AS?
Думаю не может. А вот QE именно это и делает.
Мы пишем селект к реляционным таблицам, а оптимизатор решает взять ли данные из таблицы, из MV или переписать его и отправить в многомерную базу, где не может быть ситуации когда при многомерных запросах по многим мемберам они быстро выпадают из актуальности и эффект от них нивелируется . Так как обращение идет к самому что ни на есть многомерному OLAP.
В этом подходе уже не ясно где кончается ROLAP (да и начинается ли?) и где он переходит в MOLAP. HOLAPом это тоже назвать сложно.

А Real-time OLAP действительно ли он кому то нужен? Или это просто погоня за идеальной системой?

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

P.S. Обратите внимание, что в Юконе будет большое количество расширений реляционной части для хранилищ данных, в том числе партиционные таблицы.
В Oracle партиционированные талицы уже давно существуют, что так же помогает не умирать системе на 15 миллионах записях.
Кстати не дадите линку какую нибудь summary по новым фичам Юкона для хранилищ?

Кстати еще одной фишкой в 10g является возможность взять данные из таблице не те, которые лежат сейчас там, а те, которые в ней были на момент времени в прошлом. То есть можно сравнивать что изменилось за определенное время.

2 Владимир Иванов

1) На MS SQL нет проблем сделать отложенное обновление IV. Просто сделайте их поверх DWH, а не таблиц OLTP. При создании DWH они обновяться как MV.
А если DWH нет, если работаем над OLTP таблицами? Тогда MV можно обновлять по расписанию. Почему вы говорите, что это неудобно? В чем неудобство?

Оптимайзеру MS SQL можно при манипулировании IV помочь хинтами, однако на практике OLAPов это редкость. Довольно прозрачно как надо цеплять IV.
В простых запросах конечно, а если например запрос объединяет 20 таблиц, которые при этом не лежат в звезде? Тогда оптимизатор может ошибаться.

MDX и QE сравнивать некорректно. Для работы MDX под MOLAP обычно не нужно обращаться ни куда SQL-запросами. MDX запросы в MOLAP всегда быстрее в 2-3-7 раз аналогичных SQL-запросов.
Похоже опять вы меня не поняли. Есть реляционный сервер. Есть многомерный.
Мы делаем селект к реляционному серверу - запрос отрабатывается. Можем сделать MDX запрос к многомерному серверу - запрос отрабатывается гораздо быстрее. Но что нельзя сделать, так это то, чтобы когда писался селект к реляционной базе - оптимизатор знал что послав вместо реляционки MDX запрос к многомерной он получит ответ гораздо быстрее. Именно это делает QE. Пользователь не знает что его реляционный запрос перенаправлен на многомерный сервер - он просто получает ответ гораздо быстрее.
Может вы просто не знаете, что в Oracle OLAP тоже есть свой язык многомерных запросов - OLAP DML? Вот QE как раз переписывает SQL в DML когда это удобно. В чем некорректность сравнения?
Давайте не будем про неумерающий Oracle на 15 млн. фактов? Ok?
Давайте. Если бы я не работал с хранилищем в котором было 200 миллионов фактов и не делал бы по этому хранилищу запросы с объединением 20 таблиц то я бы с вами может и согласился. При этом сервак работал медленно, да, этот запрос мог отрабатываться десятки минут, но сервер не умирал.
Причем там не было ни партишинига ни MV.
Ну и давайте вспомним пример, что я раньше приводил о 32 терабайтном хранилище в France Telecom. Хотите сказать, что у них там нет табличек на 20 миллионов записей?

Аналог партишининга через UNION ALL это как раз то что и применялось до изобретения партишининга. Партиции и сейчас представляют собой отдельные таблицы, просто теперь оптимизатор знает в какой таблице что лежит.
А что это за тест TPC где MS делает Oracle- специально заглянул туда - вроде Oracle делает MS с большим отрывом. Или я что то неуглядел?

2 Владимир Иванов
Это не религия, это что-то другое. :) Вот уж не думал что придется доказывать вам, что 20 миллионов записей - обычный объем.

Я поищу в понедельник на работе пример запроса, если найду - пришлю. Нет там никакого преувеличения, так как нет и звезды, зато есть несколько outer join-ов. Хранилище представляло собой копию OLTP базы на определенный момент времени. Так что звезды там не были предусмотрены. Select count (*) по таблице фактов проходил за 40 минут :)
Насчет того, что Discoverer умирает с 20 миллионами записей - нужно смотреть конкретный пример. Можно наверное придумать как и на 1 миллионе убить, при желании. :)

Вот вы говорите 20 миллионов ситуация нетипичная. Странно. Вы же работаете с розницой. Там 20 миллионов фактов должны встречаться сплошь и рядом. Да и в первом посте этого топика спрашивали о том как работать с 200-300 миллионами записей...
Посудите сами, что такое 20 миллионов записей? Возьмем какого-нибудь среднего регионального сотового оператора с объемом абонентской базы 100 тысяч человек. Он вам миллион записей нагенерит дня за 3 максимум. Если держать в хранилище звонки за полгода - год, то будет 50-100 миллионов записей. А если взять крупных операторов, то 10 миллионов записей у них падает в базу за день. Думаю московсоке метро вбивает в базу 10 миллионов записей о проходах через турникеты в день, а то и больше. Различные типы партишининга позволяют держать и работать с огромными объемами. Я проверю в понедельник, по-моему у меня на компьютере даже есть одна тестовая базулька на 12 миллионов записей.
Другой пример. Я его как то уже приводил - мне нужно было загрузить и проанализировать большой справочник номенклатуры, около 40 миллионов наименований. Загрузил его в MS SQL, потом построил кубик с Distinct Count мерами в MS AS. И все это тоже на обычной персоналке с гигом памяти. Никаких тормозов ни при SQL запросах, ни при запросах к MS AS. Заметьте не Oracle даже :)
Я спорю не о технологии даже, а о том что в наше время 20 миллионов записей это совершенно обычная вещь. Если бы лучшие серверы умирали на таких объемах как бы мы вообще жили?
К слову в тестах tpc-с число, насколько я помню, показывает количество транзакций отработанных в секнуду. Вот на текущий момент Oracle лидирует с числом 1,184,893. В секунду. За сколько набьется 20 миллионов? За 17 секунд.

Теперь по кластерам. Я не особый специалист в них. Попытался найти, что такое федеративный кластер - яндекс выдал мне две ссылки - одну на старый Микрософтовский прессрелиз, а вторую на ваш сайт :) Как это в оригинале называется? Я так понял, это когда персоналки объединяются вместе, база делится по их дискам, а результаты запроса собираютя по кусочку со всех?
И как это работает? Какая технология?
Не уверен, что у Oracle есть технология именно такая. Да и зачем плодить кучу персоналок, когда можно взять большой дисковый массив? И каким нибудь хэш партишинингом раскидать по этому массиву огромное количество записей с огромной же скоростью...
Подождем Юкона, что делать :) Теперь-то MS SQL можно пускать на супердомах. Красота :)

2 Владимир Иванов
Это не религия, это что-то другое. :) Вот уж не думал что придется доказывать вам, что 20 миллионов записей - обычный объем.

Я поищу в понедельник на работе пример запроса, если найду - пришлю. Нет там никакого преувеличения, так как нет и звезды, зато есть несколько outer join-ов. Хранилище представляло собой копию OLTP базы на определенный момент времени. Так что звезды там не были предусмотрены. Select count (*) по таблице фактов проходил за 40 минут :)
Насчет того, что Discoverer умирает с 20 миллионами записей - нужно смотреть конкретный пример. Можно наверное придумать как и на 1 миллионе убить, при желании. :)

Вот вы говорите 20 миллионов ситуация нетипичная. Странно. Вы же работаете с розницой. Там 20 миллионов фактов должны встречаться сплошь и рядом. Да и в первом посте этого топика спрашивали о том как работать с 200-300 миллионами записей...
Посудите сами, что такое 20 миллионов записей? Возьмем какого-нибудь среднего регионального сотового оператора с объемом абонентской базы 100 тысяч человек. Он вам миллион записей нагенерит дня за 3 максимум. Если держать в хранилище звонки за полгода - год, то будет 50-100 миллионов записей. А если взять крупных операторов, то 10 миллионов записей у них падает в базу за день. Думаю московсоке метро вбивает в базу 10 миллионов записей о проходах через турникеты в день, а то и больше. Различные типы партишининга позволяют держать и работать с огромными объемами. Я проверю в понедельник, по-моему у меня на компьютере даже есть одна тестовая базулька на 12 миллионов записей.
Другой пример. Я его как то уже приводил - мне нужно было загрузить и проанализировать большой справочник номенклатуры, около 40 миллионов наименований. Загрузил его в MS SQL, потом построил кубик с Distinct Count мерами в MS AS. И все это тоже на обычной персоналке с гигом памяти. Никаких тормозов ни при SQL запросах, ни при запросах к MS AS. Заметьте не Oracle даже :)
Я спорю не о технологии даже, а о том что в наше время 20 миллионов записей это совершенно обычная вещь. Если бы лучшие серверы умирали на таких объемах как бы мы вообще жили?
К слову в тестах tpc-с число, насколько я помню, показывает количество транзакций отработанных в секнуду. Вот на текущий момент Oracle лидирует с числом 1,184,893. В секунду. За сколько набьется 20 миллионов? За 17 секунд.

Теперь по кластерам. Я не особый специалист в них. Попытался найти, что такое федеративный кластер - яндекс выдал мне две ссылки - одну на старый Микрософтовский прессрелиз, а вторую на ваш сайт :) Как это в оригинале называется? Я так понял, это когда персоналки объединяются вместе, база делится по их дискам, а результаты запроса собираютя по кусочку со всех?
И как это работает? Какая технология?
Не уверен, что у Oracle есть технология именно такая. Да и зачем плодить кучу персоналок, когда можно взять большой дисковый массив? И каким нибудь хэш партишинингом раскидать по этому массиву огромное количество записей с огромной же скоростью...
Подождем Юкона, что делать :) Теперь-то MS SQL можно пускать на супердомах. Красота :)

Поправка. TPC считает число транзакций в минуту, а не в секунду.
Ну в общем, это мало что меняет. 20 миллионов за 17 секунд или за 17 минут, в данном случае не важно :)

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

Oracle хралище данных может быть только на одном сервере в кластере
Это не совсем так. У Oracle кластер - это несколько серверов с единым дисковым массивом. Сказать на каком из узлов находится хранилище нельзя, да и не имеет смысла. В этой архитектуре в случае сбоя одного из узлов, нагрузка перераспределится на оставшиеся, все данные будут по-прежнему доступны.
А вообще по Oracle кластерам у нас на форуме есть как минимум один специалист - DimaR, может он что-то добавит.

Пойду пить пиво :)

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

Про DB2, так же как и про Teradata не говорят, потому что, видимо, нет тут специалистов по этим СУБД.