assmskВсем привет. Имеется куб ~ на 100 млн записей + 1млн в неделю. Порядка 150 измерений. Все бы ничего кроме 1 метрики которая является уникальной для каждой строки, те если в фактовой таблице 100 млн записей, то для данного измерения будет 100 млн уникальных значений атрибута. Из за этого измерения куб процессится люто долго, так как его раз в неделю нужно полностью перепроцессшивать потому что в нем нет константных измерений и все может поменяться. Что можно сделать в такой ситуации чтобы ускорить процессинг куба?


Делайте партиции. Правильно, с проставленными slice. Это ускорит процессинг, ускорит в первуцю очередь ПОЛНЫЙ процессинг

У меня 3 лярда процессилось на 3-4 часа при 40 измерений.

Igor.KoДелайте партиции. Правильно, с проставленными slice. Это ускорит процессинг, ускорит в первуцю очередь ПОЛНЫЙ процессинг

У меня 3 лярда процессилось на 3-4 часа при 40 измерений.

Какие партиции Вы советуете делать на измерениях?[/quot]

Никакие -- партиции делаются на группах мер.

На измерениях можно сделать бакеты (BUCKETS), но подойдет ли это вам.

Alex_496Разобраться со структурой измерений. Уверен, можно сократить количество измерений, объединив несколько существующих в одно. В измерениях чем больше атрибутов распределено по натуральным иерархиям (особенно с высоким коэффициентом подчиненности), тем лучше. Но это предъявляет требование к качеству данных: элементы должны иметь одного родителя.

Если остается действительно большое измерение, например, Клиенты (половина страны), то тем более создавать иерархии и точечно DrillDown при обязательно выставленном фильтре по другому атрибуту.

Хотя и понимаю, пользователям хочется и удобно спускаться на детальный уровень и получать широкие таблицы. Но тут разъяснять - зачем возводить в куб данные, чтобы тусоваться на детальном уровне.

Я все же придерживаюсь мнения, что надо начать с партиционирования групп мер. Если партиция принимает более 15 млн строк (а группа мер это как минимум 1 партиция), то это сильно замедлит процессинг.