Работа с большими наборами результатов в службах SQL Server Analysis Services

У меня есть база данных, содержащая данные о статьях, структурах и производителях. Это означает, что статья связана с 1 производителем и с N структурными узлами (представьте, что это узлы классификации статей).

Запрос статей с использованием T-SQL с множеством условий в настоящее время слишком медленный, чтобы его можно было использовать для электронного магазина, даже с хорошим оборудованием и правильно проиндексированными таблицами. (должно быть меньше 1 секунды). Теперь мне интересно, имеет ли смысл обращаться к этим данным через OLAP-куб. Я уже разработал один для получения агрегатов, таких как: Сколько товаров производителя X существует ниже узла Y рекурсивно?

Эти агрегации довольно быстрые, теперь мне интересно, имеет ли смысл также извлекать целые наборы результатов статей через кубы. Значение: Дайте мне рекурсивно каждый идентификатор статьи производителя X, который существует ниже узла Y. Поскольку наборы результатов могут быть довольно большими, запрос занимает еще больше времени.

Поэтому мой вопрос: есть ли способ справиться с большими наборами результатов в SSAS, или это совершенно неправильное направление, в котором я иду?


sql-server performance olap ssas cubes
person driAn    schedule 08.05.2009    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

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

person Eric    schedule 08.05.2009
comment
Да, но примите во внимание такие вещи, как сортировка и разбиение по страницам: предположим, что конечный пользователь в пользовательском интерфейсе выбрал один из довольно популярных узлов структуры, результатом будет 30 000 статей. Теперь я хочу, чтобы они были отсортированы по имени и ограничены только первыми 100 (или 200-300 и т. д.). больше реально нельзя.. - person driAn; 08.05.2009
comment
Да, это так. Независимо от того, какой интерфейс вы используете, вы можете ограничить набор строк, а также использовать функцию ORDER в MDX (у большинства интерфейсов есть кнопка для этого) для их сортировки. Я бы сказал, что списки Top 10 проще в SSAS, чем в SQL. При этом, насколько хорошо вы знаете MDX? - person Eric; 08.05.2009
comment
Что ж, проблема с TOP в том, что он работает плохо, если вы хотите получить статьи от 29 500 до 30 000, используя T-SQL, вы можете выполнять всевозможные настройки, чтобы получить только «страницу строк», которая вам действительно нужна. Как вы справляетесь с этим в MDX? Я сосу в MDX, поэтому я ищу мнения, подобные вашему. - person driAn; 08.05.2009
comment
Вы можете использовать Except, чтобы скрыть строки выше и ниже определенного индекса и отсортировать их по своему усмотрению. Учитывая все это, действительно ли нам нужно пролистывать 30 000 статей? Я имею в виду, кто это будет делать? Какую информацию они действительно ищут? Возможно, мы сможем добиться от них более целенаправленного подхода. - person Eric; 08.05.2009
comment
Пользователь, скорее всего, перейдет к листовым узлам структуры, когда останется всего ‹ 100 статей, а затем начнет листать их. Однако мы хотим обеспечить такое же поведение при отображении содержимого родительских/корневых узлов. Поэтому код должен быть способен справляться с этой нагрузкой. Итак, вы предлагаете «Кроме»? посмотрю на это.. - person driAn; 08.05.2009