Спасите-помогите? Ситуация такая: есть куб, анализирующий статистику использования инета. Там мера - трафик, измерения - пользователь, отдел, Дата, и УРЛ. И вот с ним-то, с последним, и вылезла сегодня проблема. А конкретно - именно сегодня количество 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-запрос, там никаких условий не стоит, он целиком все измерение процессит....