Показатели эффективности вычисляемых членов в SSAS

Question

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

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

Answer 1

Рассчитанные элементы практически не влияют на обработку или на другие запросы. Добавьте столько, сколько захотите!

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

Посмотрите на каждую возможность сделать расчетный элемент фактической частью вашего куба, если он используется очень часто. Кроме того, узнайте и полюбите заявление scope. Пока вычисляемый член scope d все еще вычисляется во время выполнения, оператор scope предоставляет ему готовый план выполнения, поэтому он имеет тенденцию быть быстрее. Я часто создаю член в DSV, а затем scope для моих вычисляемых членов большого объема.

Answer 2

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

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

Еще одна вещь, которую вы можете сделать, это создать любые промежуточные подсчитанные элементы, которые не должны использоваться конечным пользователем как скрытые, у этого не будет никаких влиять на производительность; но будет де-загромождать куб с точки зрения конечных пользователей.