Ну, это зависит. Давайте начнем с определения проблемы.
- Многомерный SSAS работает лучше при подаче упорядоченных данных на этапе обработки. Эта статья дает вам причину и понимание порядка данных.
- Обработка индекса и агрегации SSAS не исправит неупорядоченные исходные данные; следовательно, это не решит проблемы, описанные выше. Эти задачи обработки создают артефакты на основе полученных данных, и это не может исправить проблемы с самими данными.
- MS SQL Columnstore Index - это примерно новая технология хранения данных - сжатие columnstore применяется к таблицам кучи. Это дает быструю вставку (без индексов, без предварительной сортировки) по сравнению с таблицей с кластерным индексом. Недостаток - SELECT запрос к таблице с кластеризованным индексом, скорее всего, вернет строки, упорядоченные по базе кластерного индекса (если только вы не задали порядок с помощью оператора ORDER BY ), тогда как тот же запрос в кластерном хранилище столбцов таблица выдаст несортированные данные.
Эта проблема несортированных данных с индексом Clustered Columnstore затрагивает не только SSAS, но и снижает производительность запросов, когда CCI может сделать так называемое исключение сегмента . Есть несколько методов, чтобы победить это - сортировка данных перед преобразованием обычной таблицы в CCI или сортировка данных при загрузке в таблицу CCI.
- Основная проблема обсуждения , о котором вы упомянули , заключается в том, что упорядочение данных выполняется с помощью дополнительных представлений на уровне SQL. Затем автор определяет разделы на SSAS и сообщает, что сгенерированные SSAS запросы имеют неоптимальные планы выполнения.
Относительно производительности SSAS для неупорядоченных данных. Это, безусловно, будет неоптимальным, но в какой степени? Фактически, только тесты покажут это; это может зависеть от множества факторов - исходного набора данных, дизайна куба, запросов конечного пользователя. Рост кубических структур замедлит работу, но насколько? Из опыта - я бы потрудился и приложил усилия для обеспечения порядка данных, если куб больше 100 ГБ, а его самая большая группа разделов / мер составляет более 10% оперативной памяти, используемой SSAS. При других обстоятельствах я бы не стал беспокоиться о такой проблеме.
Данные для заказа из CCI. Во-первых, избегайте устаревшего синтаксиса
SELECT TOP 2147483647 ... FROM ... ORDER BY ...
Использовать ANSI-совместимый и менее ограничительный
SELECT ... FROM ... ORDER BY ... OFFSET 0 ROWS
Относительно неоптимального плана выполнения при использовании в определении раздела SSAS. К сожалению, механизм генерации запросов SSAS не допускает магического option (recompile). Опять же, если это серьезная проблема - определите табличную функцию (параметрическое представление) для достижения оптимального плана выполнения и используйте этот TVF в определении раздела SSAS.
Если это первая реализация проекта - я бы обошелся без таких мер и объявил бы это как риски проекта , которые требуют внимания к продуктивности и, возможно, - дополнительных усилий после.
К сожалению, восстановление индексов / агрегатов SSAS не улучшит ситуацию. При подаче в SSAS необходимо предварительно отсортировать данные на уровне запросов к БД.