Спасите-помогите? Ситуация такая: есть куб, анализирующий статистику использования инета. Там мера - трафик, измерения - пользователь, отдел, Дата, и УРЛ. И вот с ним-то, с последним, и вылезла сегодня проблема. А конкретно - именно сегодня количество members для этого измерения превысило 64000. Когда-то на olap.ru был похожий вопрос, но единственное, что там посоветовали - сделать группировку. В данном случае это вряд ли подойдет, по крайней мере, я с трудом представляю, как можно группировать кучу ссылок типа "http://195.54.209.148" и "http://www.yandex.ru/click/dtype=web/*http://www.vostok-lada.ru:82"

Итак, что было испробовано:
1) Разбивание на partitions по периодам.
2) Incremental process по периодам
3) Вынос этого измерения из куба в shared
4) Создание составного измерения Пользователь->Ссылка (прошло удачно), и на основе второго уровня - создание виртуального измерения (опять та же ошибка - превышение 64000). Просто оставить измерение Пользователь->Ссылка - не катит, т.к. нужна статистика отдельно по ссылкам.

Ну, как же это обойти? Можно, конечно, сделать подуровень типа "Первые 10 символов", и по ним группировать.... Но в скором времени один Яндекс надает 64000 членов, и что тогда?

В общем, какие идеи? Может, все-таки перестроить как-нибудь измерение?

И кстати, почему не прошел номер с разбиванием на partitions? Я так думала, что он будет их по частям процессить: за первые полгода, за вторые полгода. Но когда ошибку при процесс выдает, и я смотрю sql-запрос, там никаких условий не стоит, он целиком все измерение процессит....

Да, об этом и была речь. Да и брать первую часть - тот же яндекс - не совсем корректно. Интересно же, куда с этого яндекса пошли..
Дело в том, что измерение, собственно, было двухуровневое. Ссылка (обычно основной сайт, например, www.olap.ru, и детали - "/contacts/forum..." ну и т.п. При автоматическом групинге требуется, чтобы у всех нижних уровней соблюдалось свойство уникальности ключей. А это как раз нарушается в уровне деталей. Вынести в отдельное измерение - опять делать группировку на детали, т.к. их количество еще в 2-3 раза больше, чем количество ссылок. Не очень хорошее решение...
В общем, кому интересно, мы сделали так: решили статистику по ссылкам оставлять только за год, а за более ранние периоды - только статистику трафика по пользователям. В измерение Ссылка поставили условие: если дата меньше текущей-365 дней, ссылка = null. Все прошло хорошо, кубик процессится, но решение, сами понимаете - слишком конкретное. А если бы у нас было в 10 раз больше пользователей, и ссылки превышали 64000 за месяц? Или, скажем, куб по зарплате за несколько лет? Причем не с общей суммой зарплат по сотрудникам, а с разложением на пачки, виды расчетов?

В общем-то, большинство ссылок, на которые заходили раз-два - действительно не интересуют. Интересна статистика по самым посещаемым сайтам. Подскажите какую-нибудь возможность (может быть, не в кубе, а на уровне таблицы какие-то преобразования сначала сделать), чтобы брать, например, первые 25% ссылок по размеру трафика. А остальные ссылки - не учитывать, так же, например, считать их за null...

При процессе куба, на процессе этого дименшена....

На что сгенерить уникальные ключи? Я не очень поняла... На ссылки?



-------------
ICQ 47730054

Думаю над вариантом... В смысле соотношения затрат/результата... После праздников посмотрим. Кстати, всех с праздниками - Новым Годом и Рождеством! :-)


--------------
ICQ 47730054