2013-02-28 3 views
0

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

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

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

23 размеров, не КПЭ, 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 

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

ответ

1

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

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

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

+0

Спасибо, это действительно полезно. Например, Dim1 имеет более 7 миллионов строк. Время сборки составляет более 3 часов в режиме реального времени и 8 часов на UAT. Производительность запроса шокирует - я не знаю никаких отчетов, которые занимают менее 30 секунд для запуска, а некоторые не будут запускаться вообще - у него заканчивается память, просматривая 3 измерения с 2 фильтрами. Единственными используемыми инструментами конечного пользователя являются SSRS 2008 (NOT R2) ... – Elatesummer

+0

Для времени сборки я бы посмотрел на индексацию в таблице Dim1. SSAS будет генерировать множество запросов SELECT DISTINCT, каждый из которых может привести к сканированию таблицы. Для выполнения запросов я хотел бы рассмотреть конструкцию Aggregate и MDX - сглаженный MDX, созданный SSRS, может быть неэффективным. –

+0

Еще раз спасибо - очень полезно !! – Elatesummer

Смежные вопросы