Интересная тенденция. Сразу целый ряд наших клиентов преодолели рубеж в 35-40 миллионов фактов в MS AS. Речь идет скорее о средних компаниях (1000-2000 человек персонала), в нефтянке и энергетике уже нормально иметь матричное хранилище на 2,5 млрд. элементов.
Ни каких проблем с производительностью не было отмечено, точнее там где мы выполняли работы.
Еще целый ряд корп. внедрений MS AS проявился в виду того, что разработчики обратились к нам из-за того, что MS AS фактически ушел в "даун" от объемов свыше 30 млн. фактов. Не помогали даже серверные системы стоимостью $20000-$50000 на RAID10. Особенно это касается тех, кто применял маркетинговые исследования на MS AS, т.е. плотно использовал distinct count. Эта мера предагрегируется в MS AS, но требует тонкого тюнинга сервера.
Выполнение нами тюнинга приводило к росту производительности примерно такого плана:
время отклика на построение OLAP-отчета в MS Excel XP с 180 секунд до 2 секунд, т.е. ускорение почти в 100 раз.
время процессирования OLAP-кубов (30-40 млн. фактов) с 50 часов до 4х часов (без использования инкрементального DWH) и до 5 минут с использованием инкременталки, т.е. ускорение более чем в 100 раз.

Вывод: железо не спасает, нужен хороший тюнинг.

Рост объемов данных в обсуждаемых компания происходит нелинейно и напоминает скорее степенную функцию. Очевидно что уже в ближайшие 1-2 года MS AS будет там оперировать с 100-150 млн. фактов.

Вывод: Очень важно выполнить оптимизации до того как данные окончательно обвалят систему. К сожалению радикальное ускорение производительности часто приходится делать путем переделки структур кубов и хранилищ. Лучше раньше, чем позже.

Беру смелость предсказать, что ожидаемое повсеместное внедрение матричных методов калькуляции производственных себестоимостей и других структур Доходов/Расходов приведет к взрывообразному увеличению хранилищ данных. Матричный метод очень хорош и удобен для экономистов, но фактически приводит к структурам, размер которых КВАДРАТИЧНО зависит от числа транзакций между ЭО-ЭЗ.
Современные OLAP-сервера и даже их следующее поколение не в состоянии оперировать с матричными хранилищами в 2-5 млрд. элементов (учтем что там еще нужно делать расчеты и не просто крутить обороты). Посему очень важно иметь для оперирования таким DWH специальный матричный модуль предназначенный для оперирования сверхбольшими матрицами, в том числе с поддержкой их компрессии. В OLAP-сервер должны уходить только Data Mart из такого хранилища.

Вывод: надо быть готовым в ближайшие 1-2 года оперировать в MS AS с матричными хранилищами в несколько миллиардов элементов.

Как делается тюнинг MS AS написано в MSDN, точнее там даны основы, советую всем прочитать, повторятся нет смыла. Microsoft сравнительно недавно обновил базу знаний.
Вообще говоря, специалистам из Microsoft стоит принести свои извинения за невнятную позицию относительно темы distinct count. Почти год Micrsoft не мог даже внятно ответить на вопрос "агрегаты distinct count настоящие или виртуальные?".
Этот вопрос мы с Юрой обсуждали на OLAP.ru и насколько я помню, г-н Мамаев приводил высказывание центрального эксперта по OLAP в Microsoft Russia г-на Шулейнина, который на выступлении среди разработчиков утверждал, что агрегация distict count виртуальная. Сам я там не был, так что цитирую со слов "свидетелей".
Теперь правда открывалась. MS AS единственный OLAP-сервер в мире умеющий делать настоящие агрегаты distinct count, но эта агрегация стала работоспособной только после SP и требуется настоящее шаманство для оптимизации решений на distinct count.
Частичное руководство "шамана по distinct count" вышло в MSDN.

2Юра. Ты в принципе примерял клиента Cognos к MS AS именно к нашему матричному решению для Лукойла. И ты смотришь в точку.
Если ты заметил, когда я говорю о матричных DWH, я говорю о элементах, а не о фактах. Матрица это не таблица, поэтому более правильно говорить об элементах. Только после трансляции матрицы в различные таблицы получаются обычные факты. Поскольку трансляция делается всегда частичная в определенном разрезе, то фактов уже выходит не так много (десятки миллионов). Но сама матрица даже для небольшого центра в нефтянке не менее 200 млн. элементов (15 тыс. закрываемых ЭО-ЭЗ).

PS. К слову интересно сколько сейчас фактов в российских OLAP-базах от Oracle, Cognos и Microstrategy и Hyperion?

Коллеги, мои искрение извинения но за недостатком времени я не смогу все помочь. Поэтому отвечаю выборочно и с задержками.
Поскольку нет желания вписывать в форум целый учебный курс по MS AS, могу предложить сделать мастер-класс и пригласить туда желающих.
Кому нужно, пишите на Ivanov-soft@inbox.ru, стоимость будет на уровне компенсации аренды класса – наверное $200.
Насчет матричных вычислений в экономике это не совсем тема форума, т.к. OLAP это только компонент таких решений. Скорее всего будет в ближайшее время специализированный семинар, там и обсудим.

Да, ребята. Еще раз мои извинения тем кого я случайно задел, обидел или спровоцировал на неадакватную реакцию.
Потенциальным клиентам я готов продемонстрировать решения по калькуляциям масштаба всего производственного комплекса Лукойл-Коми или Лукойл-Пермь, а также отзывы клиентов по 100 кратному повышению производительности в том числе с визитом на место.
Но все это не касается потенциальных конкурентов. Им еще раз мои извинения и мой отказ как либо аргументировать мою позицию. Мотивация сторон делает спор бессмысленным.
"На слабо", ценные знания не отдают. Халява кончилась. За сим откланиваюсь, к сожалению действительно не в то место попал, т.к. по волнующим меня проблемам (см. задачу о дебиторке) ни одного дельного совета не получил. Обмен знаниями не бывает одностронним, хочу делюсь, хочу не делюсь. Без обид.