Какова максимальная емкость куба SSAS

Извиняюсь, если разместил это не в том месте. Я понимаю, что на этот вопрос очень сложно ответить, так как существует слишком много вариантов, но любые советы или указатели будут очень признательны.

У нас есть невероятно большой, громоздкий, плохо спроектированный куб. Это ужасный тип «один куб, чтобы править всеми», как показано ниже. Обратите внимание, что Измерения с именами, которые могут выдать место, где я работаю, были запутаны.

Что я пытаюсь понять, так это то, сколько данных может хранить куб, исходя из общего эмпирического правила. Я (и несколько экспертов, на которых я не претендую!) заявили руководству, что если они продолжат добавлять данные (и атрибуты) в куб на текущем уровне, он выйдет из строя. Нам бы хотелось найти способ выяснить, будет ли это в этом году, в следующем году, в этом месяце и т. д., и да, я знаю, что здесь не будет точной формулы ответа. Любые рекомендации были бы очень полезны, так как я не могу найти их в Интернете; только лучшая практика для сборки, и я уже знаю, что это не соответствует этому! Я пытаюсь получить одобрение бюджета на его переделку, отсюда и вопрос...

23 измерения, без KPI, 4 расчетных показателя и 46 других показателей

[Dim 1] - 11 attributes
    no hierarchies
    4 address lines, email address, full name, postcode, text provider type
[Area Detail] - 21 attributes
    no hierarchies
    2 address lines, postcode, various name and code fields (string)
[Area Main 1 Month Prior] - 5 attributes
    2 hierarchies
[Area Main 4 Months Prior] - 5 attributes
    2 hierarchies
[Area Main Dimension] - 5 attributes
    2 hierarchies
[Type Dim 1] - 1 attributes
    no hierarchies
[Date Dimension] - 36 attributes
    4 hierarchies
[Event Dimension] - 29 attributes
    no hierarchies
    includes 5 dates which are not linked to date dimension but actually entered
[Event Rank Dimension] - 18 attributes
    no hierarchies
[Event Track Dimension] - 21 attributes
    no hierarchies
    14 date fields
    7 comment fields (freetext)
[History Date Dimension] - 4 attributes
    no hierarchies
    all date data
[Dim 2] - 5 attributes
    no hierarchies
    all freetext fields apart from code
[Official Date Dimension] - 9 attributes
    no hierarchies
    Date field and data about the date
[Previous Dim 2 Dimension] - 4 attributes
    no hierarchies
[xxx Current Record Dimension] - 1 attribute
    no hierarchies
[xxx Dimension] - 102 attributes
    no hierarchies
    4 address fields, postcode, 2 email fields, website
[xxx Dimension 1 Month Prior] - as above
[xxx Dimension 4 Months Prior] - as above
[Dim 3] - 12 attributes
    no hierarchies
[Question Dimension] - 11 attributes
    1 hierarchy
    4 large text fields
[yyy Combination Dimension] - 1 attribute
    no hierarchies
[yyy Current Record Dimension] - 1 attribute
    no hierarchies
[yyy Status Dimension] - 3 attributes
    no hierarchies
[Response Dimension] - 4 attributes
    no hierarchies
    2 large text fields
[zzz Area Dimension] - 4 attributes
    no hierarchies
    2 text fields
[zzz Type Dimension] - 1 attribute
    no hierarchies

Я надеюсь, что это имеет смысл, но рад предоставить/уточнить детали.


person Elatesummer    schedule 28.02.2013    source источник


Ответы (1)


По моему опыту, опубликованные вами метрики в основном относятся к удобству использования — добавление дополнительных измерений и мер не приведет к «сбою» вашего куба. У меня есть успешные стабильные кубы со многими другими измерениями и мерами, например. вдвое и более.

«Один куб, чтобы управлять ими всеми» — это архитектурное усовершенствование, представленное в SQL 2005. Он оптимизирует время сборки, хранение и производительность запросов. С SQL Enterprise Edition вы можете представить его фрагменты как «перспективы», но я не фанат. Я предпочитаю следовать тщательно спланированному именованию измерений и мер, поскольку большинство клиентских инструментов сортируют эти объекты в алфавитном порядке.

Что может привести к проблемам с кубом и, возможно, в конечном итоге к «отказу», так это объем данных в больших измерениях и группах мер. Размеры менее 1 м рядов обычно не драматичны. Группы мер длиной до 100 м строк также обычно хорошо сочетаются с некоторыми базовыми агрегатами. Чем больше это, тем больше вам придется потрудиться над дизайном. Я стремлюсь к времени отклика менее 5 секунд для 95% запросов с помощью простых инструментов для конечных пользователей, например. Эксель 2010+.

person Mike Honey    schedule 01.03.2013
comment
Спасибо, это действительно полезно. Например, Dim1 имеет более 7 миллионов строк. Время сборки составляет более 3 часов в реальном времени и 8 часов в UAT. Производительность запросов шокирует — я не знаю ни одного отчета, выполнение которого занимает менее 30 секунд, а некоторые вообще не запускаются — ему не хватает памяти, просматривая 3 измерения с 2 включенными фильтрами. Единственными используемыми инструментами конечного пользователя являются SSRS 2008 (НЕ R2)... - person Elatesummer; 01.03.2013
comment
Во время сборки я бы посмотрел на индексацию таблицы Dim1. Службы SSAS будут генерировать множество запросов SELECT DISTINCT, каждый из которых может привести к сканированию таблицы. Для производительности запросов я бы посмотрел на агрегированный дизайн и дизайн MDX - сглаженный MDX, созданный SSRS, может быть неэффективным. - person Mike Honey; 04.03.2013
comment
Еще раз спасибо - очень помогло!! - person Elatesummer; 04.03.2013
comment
@Elatesummer: так полезно для вас, что вы не проголосовали и не приняли в качестве ответа! - person Mitch Wheat; 12.09.2013
comment
Митч, несмотря на ваш несколько оскорбительный тон, спасибо за напоминание - я действительно думал, что отметил это как ответ, и, похоже, нет, я сделаю это прямо сейчас! - person Elatesummer; 13.09.2013
comment
Тон не был оскорбительным. И комментарий послужил своей цели. - person Mitch Wheat; 04.09.2015
comment
В моем комментарии выше я должен был сказать: во время сборки я бы посмотрел на индексацию SQL в таблице Dim1. В настоящее время это идеально индекс columnstore. - person Mike Honey; 21.02.2019