Вопрос к специалистам по созданию/поддержке больших OLAP кубов - есть куб в котором 25 измерений и 6 мер, размер таблицы фактов - 500,000,000 строк. Глубина иерархий разная - от 1 до 4 уровней. Aggregations wizard после 3 часов работы выдал улучшение в 3%. Вопросы, собственно, в следующем:
1. какого рода hardware необходимо для поддержания такого куба и обеспечения приемлемого response time.
2. как увеличить эффективность Aggregation wizarda(очевидное решение это user-based optimization, но к сожалению много запросов просто не возвращаются поэтому приходится убивать MSAS и ProClarity).

Сейчас у нас вариант только один - вместо одного куба с 25 измерениями создать 4-5 с различными наборами этих измерении, но это может оказаться неприемлемым для пользователей, а они, как известно, всегда правы.

Заранее спасибо.

Пытались! :-) У нас 3 временных измерения на самом деле. Когда мы делаем партиции по месяцам то все равно Agregation Wizard больше 4% оптимизации не выдаёт. А данных нас на 15 лет назад...

Документик очень полезный, да вот только у них там всего 3 измерения было(соответственно все агрегаты влёт построились), а у нас 25! В общем, думаю, придется просто разбивать куб на кубы с меньшим количеством измерений.

На данный момент да, да и с выходом MS AS 2005 это становится всё более вероятным. Но в реальности мы готовы рассмотреть другие интересные варианты.

Я согласен, что это вариант, но что делать, если пользователь захочет выбрать members из измерения, которое не участвовало в аггрегациях? Как долго MSAS будет ответ считать?
Поэтому я и пытаюсь убедить пользоваталей дать мне пару-тройку наборов измерений(по 8-10 в каждом) вдоль которых и будет проводиться анализ. На етих наборах я и построю кубы.

To Jurii:

У нас проблема всё-таки не с количеством фактов, а с количеством измерений и с их глубиной. У MSAS тоже нету проблемы закачать и пол-миллиарда фактов на десктоп-компьютере.

Jurii2 kornal:

У нас проблема всё-таки не с количеством фактов, а с количеством измерений и с их глубиной. У MSAS тоже нету проблемы закачать и пол-миллиарда фактов на десктоп-компьютере.

Я делал кубики в PowerPlay с 50 измерениями, в каждом из которых было по 5 уровней иерархии, но при этом я не пробовал закачивать сотни миллионов записей... :)

Надо будет потестировать PowerPlay на примере, аналогичном Вашему. Сколько кстати у Вас мемберов (листьев) на нижних уровнях иерархии измерений? Есть ли измерения, содержащие сотни тысяч/миллионы мемберов?

Нет, таких больших измерений нет - максимальное количество это 4500 мемберов в одном из измерений, остальние измеряются парой сотен.

backfire kornal
есть куб в котором 25 измерений и 6 мер, размер таблицы фактов - 500,000,000 строк. Глубина иерархий разная - от 1 до 4 уровней. Aggregations wizard после 3 часов работы выдал улучшение в 3%.


kornal
Нет, таких больших измерений нет - максимальное количество это 4500 мемберов в одном из измерений, остальние измеряются парой сотен.

Уважаемый Корнал, исходя из моего опыта (куб с количествоим измерений до 40 и мер до 60 факт правда), я бы на вашем месте начал бы с того, что повыключал бы аггрегации на кроме листовых уровней и All.

Позвольте узнать, на каком железе эти 3% получили? Какое количество аггрегаций при этом было рассчитаны? А сколько длится процессинг куба. Иногда рассчет аггрегаций длится сутки, а процессинг куба несколько минут. Проблема в том, что рассчет аггрегаций идет в одном thread, что утилизирует максимум 1 процессор, а процессинг куба идет на всех.

Кстати вы партиции делаете? что является slicer? Сколько фактов льете в один раздел?


Спасибо, backfire, попробуем повыключать аггрегации на всех, кроме листовых уровней и All.
отвечаю на вопросы:
1. Железо: Dual Xeon 3.2Ghz, 1Gb RAM
2. количество аггрегаций: 2104 считал около 4 часов
3. Процессинг длился 3 суток т.к. данные закачиваются из Sybase IQ и партиция была одна. (собираемся кстати bcp out всё из IQ в MS SQL для скорости)
4. партиции делали на месяц(slicer), для эксперимента - количество месяцев у нас 156 количество фактов в разделе - не помню :).
5. Критерий - время отклика - когда MSAS начинал "тормозить"(т.е. сразу не возвращался с ответом) дождаться ответа уже не удавалось.
А для пользователей что является критерием? Время отклика?

backfire kornalотвечаю на вопросы:
1. Железо: Dual Xeon 3.2Ghz, 1Gb RAM
2. количество аггрегаций: 2104 считал около 4 часов
3. Процессинг длился 3 суток т.к. данные закачиваются из Sybase IQ и партиция была одна. (собираемся кстати bcp out всё из IQ в MS SQL для скорости)
4. партиции делали на месяц(slicer), для эксперимента - количество месяцев у нас 156 количество фактов в разделе - не помню :).
5. Критерий - время отклика - когда MSAS начинал "тормозить"(т.е. сразу не возвращался с ответом) дождаться ответа уже не удавалось.
А для пользователей что является критерием? Время отклика?

1. Такое количесво памяти при таких объемах данных просто издевательсво над AS. Поставьте 4 и смею предположить что время процессинга снизмися более чем на порядок.

3. Данные тянутся напрямую из Sybase или есть хранилище на MSSQL на той же машине?
4. Я бы делал партиции по году.
5. Каким клиентом смотрите? Какие типичные запросы, на которых тормозит?
1. Про память и диск - не сыпте соль на раны - казалось-бы, работаем в солидной компании, однако выбить 200Гб диска и 4Гб памяти стоит уже почти неделю времени и кучи e-mails!!!
3. Данные тянутся напрямую из Sybase через OLEDB for ODBC
4. партиции по году - чтобы увеличить кол-во фактов в партиции?
5. Смотрим ProClarity 6.1, запросы пока самые простые(1 юзверь всего) - показать меру по месяцам(Leaf мемберы) и какому-нибудь другому измерению, когда дело доходит до выбора Leaf Members на втором измерении - все умирает включая ProClarity и MS AS, который живой на самом деле, но сервер на котором он крутится становится жутко медленным(non-resposive). Загрузка проца - 5% память на уровне 400Мб, но вот только огромное количество I/O Reads.

QuarkВсе же 1Гб - маловато.
Какие у Вас параметры в Server Properties по памяти.
Что за железо в качестве физ. диска?
Рекомендации из рассылки МССКЛ пробовали?
Параметры - Min Allocated Memory-312Mb, Conservation threshold - 712Mb, Read-ahead buffer - 40Mb, Process buffer - 320Mb
Железо - в пред. посте, диск - 40Гб UltraSATA(не кидайте камни - обьяснение тоже в пред. посте)
Рекомендации - сейчас вот это будем смотреть:
www.microsoft.com/technet/prodtechnol/sql/2000/maintain/ansvcspg.mspx

backfire
У меня только временное измерение с жесткой иерархией, все осталтные плоские с N-количеством виртуальных измерений, построенных на них.
Это поэтoму у Вас "количествоим измерений до 40"? :-)

backfire партиции по году - чтобы увеличить кол-во фактов в партиции?

чтобы получить аггрегаты на уровне года.

Загрузка проца - 5% память на уровне 400Мб, но вот только огромное количество I/O Reads.

AS понимая, что памяти мало, не кеширует данные, а постоянно их читает. Остутствие нормальной дисковой подсистемы (RAID-10 на SCSI c приличным собственным кэшем, так под 128 Мб) только усугубляет нехватку памяти. Процессор оказывается просто невостребованным.

Даже RAID-0 на нескольких SATA дисках будет для вам неплохим подспорьем, но для AS прежде всего нужна RAM.
Спасибо - сейчас опять будем долбить чтобы дали hardware...

backfire kornal backfire партиции по году - чтобы увеличить кол-во фактов в партиции?

чтобы получить аггрегаты на уровне года.

Загрузка проца - 5% память на уровне 400Мб, но вот только огромное количество I/O Reads.

AS понимая, что памяти мало, не кеширует данные, а постоянно их читает. Остутствие нормальной дисковой подсистемы (RAID-10 на SCSI c приличным собственным кэшем, так под 128 Мб) только усугубляет нехватку памяти. Процессор оказывается просто невостребованным.

Даже RAID-0 на нескольких SATA дисках будет для вам неплохим подспорьем, но для AS прежде всего нужна RAM.
Спасибо - сейчас опять будем долбить чтобы дали hardware...

Корнал, если вы действительно из NewYork, то купить 4 GB RAM вы можете на ваше дневное жалование и даже на парочку SATA хардов останется и на пиво. А начальство, после достижения результата в AS, жестоко поставьте (раком)перед фактом успеха.
Последнее сделал бы с удовольствием, но вот только сервера наши стоят в North Carolina data center а мы прозябаем в New Yorkе :)

backfire kornal
Последнее сделал бы с удовольствием, но вот только сервера наши стоят в North Carolina data center а мы прозябаем в New Yorkе :)

Никогда бы не подумал, что сервер, имеющий на борту 1 Gb мозгов и жалкий 40 гиговый SATA, достоин установки в Data Center. Максимум тянет на наспех полусобраный PC под столом у админа. Что же за "мудрец" анализировал требования к железе и конфигурировал заказ на него? Сечас нормальный WorkStation DataBase озабоченного профи помощнее будет
Надо еще спасибо сказать, что отдельную машину дали!!! А то могли бы и на своих десктопах всё крутить!!! Вот бьёмся сейчас за железо нормальное. Проблема еще в том, что "мудрецы" хотят магии от OLAP думая, что всё и на таком железе будет летать.

backfire seroffСтоль безумная ситуация с hardware в нашей организации (а мы с kornal работаем в одной организации) является результатом того, что она представляет собой слияние нескольких организаций, причём это произошло в очень короткое время. Отсюда - полный бардак. А если к этому добавить то, что в любой большой организации уровень эффективноски напоминает социалистическое государство, то никакого удивления сия обстоятельства вызывать не должны.

Прошу прощения за оффтоп,
но социалистичность государства тут не при чем, неуж то ваш большеяблоковский горисполком, куда вы, 100 пудов, имели повод не раз обращаться, по эффективности далеко ушел от совка?

А по поводу бардака, то не так давно я вырыл на одном из gov сайтов полную статистику о том в какую контору, на какую доджность и на какие бабки за последние 5 лет был выдан зеленый билет или Х1Б. Не думаю, что это было задумано как открытая для всех желающих статистика.
Про горисполком не скажу, но как только дело касается бюрократии то не важно, совок это или финансовая организация здесь - результат один - всё тянется вечно и каждый раз приходится доказывать, что ты не осёл. Я думаю иногда количество бюрократии переходит в качество - бардак . Sorry, я думаю этот offtop уже выходит за рамки этого форума, поэтому предлагаю на sql.ru организовать новый форум по обсуждению таких вопросов!!