Коллеги, добрый день.

Есть два вопроса по оптимизации модели данных для большого объема данных:
1. Начиная с какого объема данных в месяц есть смысл включать стандартное парциционирование?
2. Начиная с какого объема данных есть смысл создавать новые кубы для кварталов или годов например (с учетом включенного парциционирования) или это бессмысленно?

Куб уже работает или проектируется? Cколько записей в кубе?
Как часто к этому кубу будут доступаться различными отчетами?
По моему мнению, партицирование надо делать тогда, когда другие направления повышения производительности исчерпаны.

Вот именно тогда уже бывает поздно... особенно логическое партицирование. Это надо делать на этапе проектирования системы - то есть хорошо подумать о мощности данных, о нагрузке. Это прежде всего проектное решение, котрое накладывает ограничение на архитектуру - как минимум надо думать о количестве партиций и продумавать прицип логического партицирования -> все отчеты надо строить на мультиках -> продумывать механизм определения инфопровайдера при выполнении отчета для ускорения выборки.

А ваш подход приведет к тому, что придется либо трахаться с ремоделлингом по ночам - и не факт что он пройдет, с перезаливкой данных или с перепроектированием всех отчетов - как минимум портирование всех запросов на мультик... а если таких запросов штук 200 - 300 - тогда да поможет вам бог...

Модель данных проектируется.
Количество запросов к кубам пока точно сказать не могу. Оценка объема данных по движениям материалов примерно 300 тыс в день. Аналитики пока крайне стандартные (материал, завод, вид движения, класс оценки материала, поставщик, номер документа в DSO).
Получается около 30 млн в квартал.

Есть еще вопрос, если смысл разделять кубы для движений и остатков (в стандарте 0IC_C03 не имеет вида движений) или сделать фарш в одном кубе?

У всего есть своя цена сопровождения. Если вы весь SAP контент замените на мультикубы, то от этого будет хуже только вам. Переход на новую версию и прочие апргрейды выйдут боком. Для обычных кубов должно хватать штатных средств повышения производительности, а
партицирование должно применятся осознанно и исключительно для больших объемов данных. Порою, не справившись с вопросами с производительности в части сжатия, агрегирования, настроек СУБД или других путей разработчики видят единственный выход в партицировании.

30 млн записей - это реально много, возможно вам реально не обойтись без партицирования.

Абсолютно верно! И эта осознанность должна быть проявлена на этапе проектирования системы, а не на этапе поддержки!

Правильно ли я понял, Вы рекомендуете вообще избегать Z-кубов и изначально держаться кубов из контента?

Без z кубов не обойтись, но там, где это возможно - дешевле и практичнее использовать контентные кубы.
Плюсы стандарта - готовые отчеты, готовая документация, минимум проблем с апгрейдом, минимум кода и прочие преимущества стандарта.
В реалиях не все так пушисто, стандарт требует адаптации и доработки. По мне так лучше стандарт не ковырять, а адаптировать Z копии стандарта.
С другой стороны, как только объем внедрения будет очень большим , что делать с таким большим количеством Z разработок?
Прибавьте к проблемам текучку кадров и будете пожизненно сидеть на текущей версии.

Два куба делать не надо. По кубу 0ic_c03 есть "How to inventory .... чего там ", обязательно почитайте и потренеруйтесь. Если захотите делать второй куб
с остатками , подумайте над экстрактором. Экстрактор 2lis_03_bx (остатки) корректно снимает данные при условии, что пользователи не проводят в это время мат. документы, возможно в новых версиях R/3 и BW по другому, но использовать его на постоянку не реально.
Сам расширял копию куба 0ic_c03 видом движения , все ок.

Какие у вас объемы данных? Используете ли физическое партиционирование?

относительно вас немного, раз в 10-30 меньше. Вопрос о применении партицирования изучался теоретически, когда остро встали проблемы с производительностью. К счастью, разобрались с проблемами без партицирования.

Обязательно разделять на вашем объеме данных. Здесь два момента.
1) Дело в том, что многие признаки, необходимые для анализа движений, теряют свой смысл как признаки некумулятивного куба запасов. Примеров много: вид движений, поставщик, класс оценки - только из вашего списка;
2) Некумулятивный куб запасов работает по определению медленно. Количество признаков лучше минимизировать, оставив только основные 3-5 + признаки времени, еи и технические. Все остальные - навигационные атрибуты основных признаков.

Наконец, в отраслевых решениях контента кубы запасов и движений разделены. Например, в ритейле.

Это, как правильно написали коллеги, архитектурные вопросы. Варианты могут быть разные.

1. Стандартное (физическое) партицирование включено "по умолчанию". Таблица F партицируется по реквестам. Ничего дополнительно делать не нужно. Дальше интереснее. Если вы планируете сжимать ваши запросы в кубах, а логические партиции более одного месяца/финансового периода, то имеет смысл включить физическое партицирование. В этом случае с большой вероятностью производительность повысится. В некоторых случаях пропорционально количеству партиций. Из минусов - потеряете немного дискового пространства, ну, и если сжимать запросы не будете, то только потеряете, в т.ч. и по производительности, безо всякого положительного эффекта. Опять же не все БД его поддерживают;
2. При хорошем проектировании и сбалансированных измерениях куб со 100 млн. записей в таблице фактов может вполне себе работать и всех устраивать. Многое зависит от аппаратного обеспечения и требований ко времени ожидания данных в отчете. Но все равно ни разу не видел, чтобы такие кубы быстро работали. Это плохое решение. Логическое партицирование - дело непростое. Обычно пользуюсь следующим эмпирическим критерием для его использования - 20-30 млн. записей. Все что больше надо логически партицировать. У мультика сильно проседает производительность при большом количестве кубов. SAP называет приблизительную цифру 5. Это следует учитывать и искать компромисс между размером логических партиций и количеством кубов. Есть несколько шаманских нот и хау-тушка, после применения которых эффект от логического партицирования проявляется во всей силе.