Почему мой куб вычисляется так медленно на самом низком уровне детализации? - PullRequest
1 голос
/ 08 июля 2010

Я все еще изучаю веревки OLAP, кубов и SSAS, но я достигаю барьера производительности и не уверена, что понимаю, что происходит.

Итак, у меня есть простой куб, который определяет два простых измерения (тип и область), третью иерархию измерений времени (идет Год-> Квартал-> Месяц-> День-> Час-> 10-минута) и один мера (сумма в поле с именем Count). База данных отслеживает события: когда они происходят, какой тип, где они произошли. Таблица фактов представляет собой предварительно рассчитанную сводку событий для каждого 10-минутного интервала.

Итак, я настроил свой куб и использую браузер для одновременного просмотра всех моих атрибутов: общее количество по областям для каждого типа с течением времени, с детализацией от года до 10-минутного интервала. Отчеты по производительности аналогичны просмотру.

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

Я не понимаю. Я ожидаю, что переход на кварталы или годы займет больше всего времени, поскольку он должен объединять все данные. Переход к самому низкому показателю, сильно отфильтрованному до 180 ячеек (6 интервалов, 10 типов, 3 области), кажется, что он должен быть самым быстрым. Почему куб обрабатывает весь набор данных, а не только видимое подмножество? Почему самый высокий уровень агрегации такой быстрый, а самый низкий уровень такой медленный?

Самое главное, что я могу сделать с помощью конфигурации или дизайна, чтобы улучшить его?

Некоторые дополнительные детали, о которых я только что подумал, могут иметь значение: Это SSAS 2005, работающий на SQL Server 2005 и использующий Visual Studio 2005 для проектирования BI. Куб установлен (как по умолчанию) на полную MOLAP, но не разделен. Таблица фактов имеет 1 838 304 строки, так что это не сумасшедшая корпоративная база данных, но и не простая тестовая база данных. Нет разделения, и все компоненты SQL работают на одном сервере, к которому я получаю удаленный доступ со своей рабочей станции.

Ответы [ 3 ]

0 голосов
/ 08 июля 2010

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

Если предположить, что это не так, то, что Cade предлагает для создания измерения Date и измерения Timeбыло бы самым очевидным подходом, но в SSAS это было бы больше, чем нет.См. Эту статью для получения дополнительной информации: http://www.sqlservercentral.com/articles/T-SQL/70167/

Надеюсь, это поможет.

0 голосов
/ 09 июля 2010

Я бы также проверил, что у вас установлена ​​последняя версия sp для sql server 2005

В RTM-версии были некоторые проблемы с SSAS.

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

Если эти отношения не определены, механизм хранения SSAS будет сканировать больше данных, чем необходимо

больше информации: http://ms -olap.blogspot.com / 2008/10 / attribute-relations-example.html

Как указано выше, разделение даты и времени значительно уменьшит количество элементов измерения даты, что должно повысить производительность и улучшить аналитические возможности.

0 голосов
/ 08 июля 2010

Когда вы смотрите на минутный уровень - вы говорите обо всех событиях с 12:00 до 12:10 независимо от дня?

Я бы подумал, если вам нужно, чтобы это происходило быстрее (потому что, очевидно, этобудет сканировать все), вам нужно будет сделать две части вашего измерения «времени» ортогональными - создать измерение даты и измерение времени.

Если вы получаете 1 января 1900 г. в 12:0001.01.1900 12:10, я не уверен, что это может быть тогда ...

...