2 dmitry_kz:

из всего вышесказанного я так понял, что у меня работать все будет очень плохо. У меня MSAS2K. Объемы примерно следующие:
Кол-во строк в одной самой большой таблице будет превышать 150 млн. записей. Стоит задача построения отчетов с использованием ОЛАПа.

Я бы сказал, что вопрос не в том, какая СУБД используется для создания хранилища данных, а какое OLAP-средство работает поверх хранилища... Я могу легко сделать ХД на основе MS Access или файлов DBF, закачать туда миллиард записей, и все будет работать с 5-секундным откликом на каждый запрос пользователя. Просто чтобы это достичь, я буду использовать OLAP-сервер, который преобразует реляционные данные в формат MOLAP-куба.
Так что 150 миллионов для MS SQL при правильном выборе OLAP-сервера - это небольшой объем.

2 dmitry_kz:

Ага, понял... Тогда если для такой ситуации выбирают MS AS2K, то это приемлимо?
Т.е. если схема такая:
OLTP (MS SQL 7.0/2K) -> Хранилище данных (MS SQL 2K) -> OLAP (MS AS2K)
то она вполне способна жить, и даже очень хорошо жить... :)

MS AS - это один из двух самых мощных в мире OLAP-серверов, поэтому Ваша схема приемлема. Есть конечно тонкости, которые могут всплыть, если Вы будете решать сложные аналитические задачи. Поэтому полезно заранее анализировать потребности пользователей, и только на основе этого выбирать OLAP-инструментарий.

2 MSTR_Fan:

Супер.
Запрос - distinct count по таблице детального уровня с группировкой по 3-4 полям. Без ограничений. (Смотрим активность торговых точек по времени суток за всю историю, в деньгах и штуках)
Размер таблицы - 1 млрд строк, для ровного счета :)
Решение в студию!

Если Вы представляете компанию S&T, которая недавно стала партнером Cognos, Вы должны знать, что такое Cognos PowerPlay. В MOLAP-куб PowerPlay можно закачать миллиард записей, и PowerPlay умеет считать Distinct Count и делать группировки. Задача по торговым точкам и часам суток - популярна и давно обкатана в PowerPlay.

2 MSTR_Fan:

Я не представляю здесь компанию S&T, хотя и хорошо к ней отношусь :)

То есть Вы не обижаетесь на S&T за то что она Вас предала и подружилась с Cognos? Если так - то Вы пока еще не фан МСТР :)

То есть Вы утверждаете что Cognos PowerPlay способен сделать full table scan таблицы любых размеров за 5 секунд, я правильно понял? И время закачивания мы считаем?

PowerPlay не делает full table scan, эта операция для MOLAP-куба не актуальна. Те данные, которых бывает много (записи CDR, строки чеков и т.п.), не корректируются задним числом, поэтому их можно подкачивать инкрементально, и за счет этого минимизируется время обновления MOLAP-куба. Обычно большие кубы обновляются по ночам, когда пользователи спят и никуда не торопятся, но можно их обновлять и по факту поступления свежих данных в ХД. В дневное время суток уже обеспечивается 5-секундный отклик, так как все показатели во всех разрезах заранее просчитаны.

2 MSTR_fan:

Очень интересно, а как происходит initial load?

Первоначальная загрузка данных в MOLAP-куб конечно же требуется, и может занимать значительное время (для сотен миллионов записей может занять несколько часов). Но как мы понимаем, если строить серьезное реляционное ХД, то там есть аналогичные этапы - и полная загрузка, и обновление, и поднятие базы из бэкапа. Для одной знакомой мне крупной розничной сети требовалось чуть ли не 2 недели, чтобы поднять из бэкапа большую реляционную БД Oracle...

Предположим пришло изменение задним числом.
И ещё такой момент: инкремент может приходить нецелостным - пришел факт, а в справочнике записи нет. Как с этим? Может PP обеспечить целостность или это возлагается на источник?

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

2 MSTR_fan:

Если предположить что для проведения инкрементальной подгрузки distinct count агрегата Cognos хранит все distinct значения отдельно, где-то в кубе, то как он определяет какие из distinct значений нужно корректировать?

Про технические тонкости хранения агрегатов в кубе сказать сложно - это ноу-хау Cognos. Для того чтобы управлять тем, какие мемберы считать в Distinct count, а какие нет, используется параметр Activity measure (если поставить ВЫРУЧКУ, посчитаются только те товары, которые хоть раз продавались за указанный период, если поставить ОСТАТКИ - посчитаются те которые были на складе). Если какие-то товары считать не хочется - надо с помощью сторнирования обнулить показатель, используемый как Activity measure.

И ещё вопрос: какой интерфейс дает Cognos для сторнирования? API?

Можно например держать в кубе данные из Oracle, и подкачать сторнирующие записи из файла Excel. Можно сделать это визуальными средствами, а можно и программным путем (например на VB).

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

Юрий, это для бедных. Есть задачи, которые не решаются средствами ОЛАП, а требуют реляционного хранилища. Вам это должно быть известно.

Я не призываю все хранилища делать на простых СУБД типа MS Access или dBase, но если у Вас миллиарды записей - почему бы не хранить их в формате DBF? Это экономично, не придется переплачивать за enterprise-версии СУБД :)

2 OldNov:

Главное - свое хранилище спроектируйте с умом, и тогда distinct count даст вам гарантированный ответ за те же 5 секунд. Просто придется потратить на железо на 2000$, а чуть поболее.

Боюсь что мощное железо не даст гарантии быстрого выполнения SQL-запросов, когда речь идет об аналитических запросах, под каждый запрос таблицу с агрегатами не спроектируешь... Без MOLAP трудно обойтись, либо нужно смириться с невысокой скоростью отклика, измеряемой минутами или часами.

А потом вам Юрий правильно сказал - купите хорошего клиента и радуйтесь удовольствиям жизни.

Все-таки я имел в виду не просто клиента, а MOLAP-сервер поверх ХД плюс OLAP-клиент для него.

2 backfire:

Я могу легко сделать ХД на основе MS Access или файлов DBF, закачать туда миллиард записей
Юра, Вы когда сказки рассказываете, то не забывайте сначала в шпаргалку по физическим ограничениям Access и DBF поглядеть...

Другими словами, Вы хотите сказать что я не смогу поместить 1 миллиард записей в ХД на основе MS Access или DBF? MS Access это мощное средство, аналог MS SQL сервер, его трогать не будем. Давайте на что-нибудь поспорим, что я без труда сделаю ХД на основе DBF-файлов, содержащее 1 миллиард записей, ОК? :)

2 backfire:

Юра у вас в школе что было по математике?

В первом классе я был круглым отличником :) Потом пятерки по математике сочетались с двойками за систематическое невыполнение домашнего задания, в итоге выходили четверки, но в университете с математикой у меня было все круто, даже открытие одно совершил (решил задачу, которую 100 лет назад решил Лобачевский, но другим, более легким способом :)

Пример из арифметики 2-го класса начальной школы.
максимальный размер базы в access 2 Gb, максимальный размер таблицы - не больше 2Gb, следовательно если вы запихнете в 1 (одну) таблицу 1 миллиард записей, то длинна записи должна быть не больше 2-х байт.

Это все конечно так, но кто сказал, что хранилище данных должно состоять из одной базы данных? Например, таблица фактов у меня будет содержать записи по 200 байт, всего записей в одной БД будет 7-8 миллионов, а баз данных у меня будет 140-150 штук. В OLAP-сервер я соответственно вставлю 140-150 одинаковых источников данных, и операция Union будет делаться на OLAP-сервере. В качестве железа при этом мне потребуется обычный однопроцессорный компьютер, какое-либо ультрамощное железо не требуется, так как не будет сложных SQL-запросов.

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

А у меня не получилось. После 5 млн. записей PowerPlay свалился.
Кстати пользуясь случаем хотел задать вопрос. Может ли PP взять данные например из SQL сервера? Если да, как это сделать?

Думаю проблема в том, что Вы не проходили официального обучения по PowerPlay и пользуетесь пиратской версией этого продукта. По информации полученной из корпорации Cognos, Ваша компания пока имеет право заниматься только продуктами Cognos Planning... :)
Если серьезно, то большие кубы в PowerPlay можно делать и без обучения, но только если не встретится сложных ситуаций, в которых нужно не допустить ошибок в проектировании куба.