Нельзя просто так взять и ответить на этот вопрос, не приняв во внимание целый ряд факторов.

Многие думают, что необходимо переходить на табличную модель, ибо она новее и лучше. Но часто это нецелесообразно или даже невозможно в принципе. Однако поговорим об этом чуть позже.

Многомерная модель

Многомерная база данных имеет определенную структуру и позволяет нам генерировать отчеты очень быстро. Когда-то, для создания многомерных баз данных, многомерная модель была единственным решением. Эта модель не менялась со времен SQL Server 2005. Если посмотреть что нового в каждом выпуске Analysis Services, то станет ясно, что большинство новшеств связано именно с табличной моделью.

Табличная модель

Табличная модель появилась в SQL Server 2012 и активно развивается, а каждая последующая версия включают новые возможности.

Табличная модель работает на другом движке (xVelocity) и она разработана для быстрого выполнения колоночных запросов, потому что использует колоночное хранение (многомерные модели используют строковое хранение), в дополнение к хорошему сжатию данных. Данные хранятся в оперативной памяти (режим in-memory), поэтому очень важно, чтобы на сервере было много памяти и очень быстрый процессор. Диски для табличной модели не так важны. Одним из основных преимуществ табличной модели является то, что некоторые запросы в ней работают быстрее (например, очень быстро работают с измерениями на основе distinct count) и она имеет высокую степень сжатия — 1/10 (ниже приведена ссылка с описанием принципа сжатия), в то время как в многомерной модели лишь 1/3. Степень сжатия указана примерная, разумеется, она может колебаться, в зависимости от данных.

Аппаратная часть

Следует отметить, что аппаратная часть, используемая для многомерных баз данных, в большинстве случаев не может использоваться для табличной модели. Табличная модель напрямую зависит от объема оперативной памяти. Чем больше памяти, тем выше производительность. Если памяти будет недостаточно, табличная модель просто перестанет работать, без всяких предупреждений.

Частота процессора также очень важна для табличной модели.

Еще раз: для табличной модели диски имеют второстепенное значение, однако очень важен объем ОЗУ и скорость ЦП.

Так сколько же нужно памяти? Есть такое выражение — чем больше, тем лучше! Но оно очень абстрактное и невозможно для понимания, хотелось бы чего-то более осязаемого, правда? С одной стороны есть простая формула <Размер реляционной БД>/10*2, но не нужно забывать, что есть пользователи, которые будут подключаться к табличной БД, а значит, SSAS нужна еще память — для кэширования запросов, так же нужна память для ОС и кэша ядра SQL Server (если SSAS и реляционная БД находятся на одной машине). В табличной модели есть возможность создавать вычисляемые таблицы и колонки, следовательно, они будут увеличивать размер табличной БД, не смотря на то, что реляционная БД осталась в прежних размерах.

Почему в формуле результат деления размера БД умножается на два? Потому что по умолчанию процессинг выполняется в буфере (по сути, рядом с основной моделью создается временная копия табличной БД), в то время, как основная модель продолжает существовать и работать в неизменном виде (до удачного завершения процессинга, после которого данные основной модели заменяются на данные из буфера, а в случае ошибки все остается без изменений). Поэтому будьте внимательны, при выборе редакции SQL Server. Если размер табличной БД получается больше 5 ГБ, то редакция Standard (с ограничением в 16 ГБ для SSAS, в которые входит и кэш), скорее всего, не подойдет! При недостатке кэша будут жуткие тормоза.

Более подробные статьи об объеме необходимой памяти можно посмотреть здесь и здесь

Статистика по использованию табличных и многомерных моделей

По данным из этой статьи проводился опрос среди 440 участников вебинара о сравнении двух моделей, из которых ответили 212 человек (~48%), на тему «Какую модель вы используете — табличную или многомерную?»:

• Обе – 61 (~ 29%)
• Многомерную – 75 (~ 35%)
• Другую – 43 (~ 20%)
• Табличную – 33 (~ 16%)

Переход

Если вы уже используете многомерную модель и она устраивает, то лучше на ней и остаться. Если есть основания полагать, что табличная модель может решить ваши потребности, то есть смысл задуматься о переходе. Но переход от многомерной к табличной модели — непростая задача. В основном все придется делать вручную и легкого способа перехода с помощью волшебного конвертера не существует. Можно создать специализированные средства для перехода, используя такие инструменты как SSIS, PowerShell или другие.

Так же следует понимать, что в многомерных моделях есть функционал, который не поддерживается в табличных моделях, например — Обратная запись.

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

Обратите на это внимание, прежде чем начинать переход.

Новый проект

Для новых проектов обычно рекомендуют использовать табличную модель, если, конечно, не требуется функционал, который поддерживается только в многомерной модели. Для тех, кто раньше не сталкивался с аналитикой, табличная модель будет более понятна, потому что похожа на обычную реляционную БД. К тому же, тех функций, что она поддерживает, в большинстве случаев достаточно для полноценной работы.

Рекомендации

Если Вы все же решитесь использовать табличную модель, то позвольте дать совет как не наступить на грабли.

В табличной модели есть вычисляемые столбцы. С их помощью в любое из измерений можно добавить поле, которое отсутствует в реляционной БД, и прописать формулу расчета. Например, добавить в таблицу Клиенты поля с названиями страны и области, которые хранится в соседней таблице. Вычисляемы столбцы хранятся в табличной БД и заполняются в момент процессинга.

Казалось бы — красота, логика хранится в метаданных модели, не нужно исправлять представления для добавления поля, но есть нюанс. Чтобы его понять, давайте посмотрим на на этапы процессинга:

1. Получение данных из реляционной БД
2. Сжатие данных
3. Расчет вычисляемых значений и показателей

Из этапов процессинга вырисовываются 2 проблемы:

1. Наличие вычисляемого столбца увеличивает время процессинга
2. Вычисляемые столбцы не сжимаются

Т.е. не стоит злоупотреблять вычисляемыми столбцами, не смотря на их удобство.

В этой статье на пальцах рассказывается за счет чего происходит сжатие данных.

Еще несколько советов о повышении скорости процессинга табличной модели