Есть семовский куб, в который каждый день заносятся данные. Ночью куб в цепочке переключается в нетранзакционный и данные из него перекачиваются в другой (сводный) куб. В результате по каждому дню получаю запрос (виден в администрировании куба).
Внимание вопрос: Хорошо это или плохо? Как правильнее поступать в этом случае с запросами? Есть ли какие-нибудь камни, на которые можно нарваться?

1. А зачем перекачивать? хотя вопрос не в тему
2. много запросов = много разделов = фиговенько для производительности (rsrv ругается )
3. много данных в плановом кубе - снижение перфоманса при планировании
4. много несжатых данныз = снижение перформанса, так как в запросе будет писаться дельты - результаты изменений. соответтсвенно прежде чем вывести на экран сумму bw прошуршит по всему кубику и сложит превоначальную сумму + ВСЕ дельточки. потом чел изменит, bps посчитает дельточку от получившейся суммы и то что на экране и ее запишет в кубик...
5. партицирование ( физическое ) на несжатых данных не работает

В общем главные грабли - снижение проиводительности. Выходов много, один из которых - сжимать данные. И архивировать старые в другой куб и грохать архивные данные из планового - например выборочным удалением.

Реализация джойна кубов, (далее следует много нецензурных слов в сторону индусских программистов)

ok спасибо!

А сколько записей приемлемо в кубе планирования (без использования агрегатов)? Хотя бы порядок числа?

да фиг его знает... таких данных у сапа нет и у меня тоже )...
ну давайте порассуждаем вместе. Сап рекомендует держать не более 2 млн записей в кубе. Доступ к данным производится через функции rsdri_infoprov_read (ну или более низкоуровневых если быть точнее) в обоих случаях... ну отсюда можно сделать выводы... хотя все очень сильно зависит от задач , от архитектуры хранения информации, мощности измерений и от обшей производительности системы в целом... В каждом конкретном случае надо смотреть индивидуально.

2 млн записей это мало. Понятно что их в реальности гораздо больше. У нас по месяцу генерится около миллиона записей в некоторых SEM кубах. Пока не паримся. Особой разницы не заметно. Особенно на счетах.

Прошу прощения. А с чем связано такое ограничение? Как это объясняет SAP, и что об этом думают другие разработчики баз данных?

А фиг его знает, почему.. на курсе 360 по оптимизации так говорят тьютеры А вот лично мое мнение - фигня это. И на большем количестве все замечательно живет и шуршит .... Наверное это тот порог, после которого надо более пристальнее следить за запросами и перфомансом для запросов на данном кубе и быть готовым проанализировать статистику и начать строить наконец агрегаты )

А может (крамольная мысль) у SAP был проект, в котором при 2 000 001 записи по неизвестной причине случилось СТРАШНОЕ? Вот и рекомендуют теперь, от греха подальше.

кстати по поводу запросов в кубе и сжатия данных... есть нота 590370 которая говорит почему плохо иметь много запросов в кубе, к чему это приводит и что надо делать ... особенно порадовало вот это


Solution

Compress, compress, compress !

хм, согласен с тем, что сжатие запросов для семовских кубов очень даже актуально, но сжатие для "рабочих" кубов, данные в которые закачиваются ежедневно помоему можно опустить, вместо этого вполне можно настроить удаление существующих запросов с критерием "Идентичные или более объемные", хотя это наверное имеет смысл только когда нет агрегатов.

и еще, после сжатия-то удалить запросы уже нельзя, а это не есть гуд.

ну насчет удаления... вот представим себе, что в куб ежедневно грузятся данные и он существуют несколько лет... я думаю, что можно безболезненно сжать данные, оставив несжатыми последние полгода...