Настройка производительности для огромной таблицы (SQL Server 2008 R2)

14

Справочная информация: у
меня есть таблица фактов в фазе UAT. Задача загрузить данные за 5 лет в Prod (ожидаемый размер записей 400 млн.). В настоящее время он имеет только 2 года данных в тесте.

Особенности стола:

  1. Количество Размеров ~ 45
  2. Меры ~ 30
  3. Неаддитивные меры и другие столбцы ~ 25
  4. Текущий размер данных ~ 200 миллионов (данные за 2 года)
  5. Представление времени: 3 разных представления месяца: фискальное / календарное / скорректированное (т. Е. Одна и та же строка может приходиться на разные месяцы в зависимости от того, какой вид ищется)
  6. Только один вид будет требоваться за один раз пользователем. (т. е. в запросе будет использоваться только один столбец месяца, он останавливает нас для разделения по времени)
  7. Индексы: 1 Кластерный индекс на натуральных ключах (8 столбцов). Создан 3, охватывающий некластеризованные индексы, один на столбец каждого месяца, включая несколько SK измерений (FK) и все меры).
  8. Индексы огромные (всего 190 ГБ) из-за этого.
  9. Пространство не ограничено (выделено 1 ТБ)
  10. 64 ГБ оперативной памяти доступно на сервере.
  11. Сжатие таблицы также сделано.

Требование:
запросы к этой таблице фактов должны давать результат в течение 30 секунд (общие запросы выбирают сумму (меру), присоединяющуюся к группе Dims по значениям Dim). Отчеты создаются непосредственно над таблицей фактов.

Проблема:
любой запрос, включающий столбцы, доступные в индексе, работает нормально, но если мы включим любые другие столбцы, которых нет в include .. Это отстой. Это займет более 5-10 минут. Может ли кто-нибудь предложить какое-нибудь решение, где оно прекрасно работает для любого размера / столбца, который мы выберем Может ли представление индекса помочь в этой ситуации?

user1801862
источник

Ответы:

6

Обновление до SQL Server 2012 и использование хранилищ столбцов . Они процветают в этих требованиях. Серьезно, загрузите ознакомительную версию и попробуйте. Удалите все индексы, удалите кластеризованный индекс, просто добавьте некластеризованный индекс columnstore ко всем столбцам и добавьте в него вращение. Я видел такие же случаи, как и у вас, которые сократили время выполнения до 2-3 секунд, в основном из-за включения исключения сегмента . Некоторые дополнительные чтения:

Ремус Русану
источник
0

Будет ли индексированное представление решить вашу проблему? Насколько актуальными должны быть данные? Вы можете создать индексированное представление для нескольких перестановок. Но с таким количеством мер и мер вы можете быстро выйти из космоса!

Как насчет использования SSD?

Nick.McDermaid
источник
Данные будут обновляться каждый месяц. Сколько времени потребуется, чтобы обновить вид?
Если ваш существующий запрос занимает 5-10 минут, то индексированное представление займет 5-10 минут. По завершении, когда вы выполняете тот же запрос, он возвращается, как если бы он выходил из таблицы (то есть немедленно). Индексированное представление предварительно запускает определенный фрагмент SQL. Если вы отправляете SQL, который соответствует ему, он берет его из индексированного представления, а не запускает его заново. Основным преимуществом индексированного представления является то, что вам не нужно изменять существующие запросы, они будут автоматически его использовать. Недостатком является то, что вам приходится создавать один для нескольких различных комбинаций.
Nick.McDermaid
Но я не советую вам создавать несколько индексированных представлений, чтобы ускорить процесс - у вас не хватит времени и дискового пространства в конце концов. Это может быть просто одна вещь, чтобы положить в свой арсенал.
Nick.McDermaid
и, пожалуйста ... посмотрите на магазины, как предлагалось!
Nick.McDermaid