SQL Server - вставка новых данных ухудшает производительность запросов - PullRequest
0 голосов
/ 18 сентября 2018

У нас есть база данных SQL Server 4-5 ТБ.Самая большая таблица размером около 800 ГБ содержит 100 миллионов строк.4-5 других сопоставимых таблиц составляют 1 / 3-2 / 3 этого размера.Мы прошли процесс создания новых индексов для оптимизации производительности.Несмотря на то, что производительность, безусловно, улучшилась, мы увидели, что недавно вставленные данные были самыми медленными для запроса.

Это приложение для финансовой отчетности с инструментом BI, работающим поверх базы данных.Данные загружаются в течение ночи и продолжаются поздним утром, хотя большая часть данных загружается к 7 утра.Пользователи начинают запрашивать данные около 8 часов утра с помощью инструмента BI и больше всего беспокоятся о последних (ежедневных) данных.

Я хотел бы знать, приводит ли добавленные данные к тому, что индексы выходят из строя.Можем ли мы что-нибудь сделать, чтобы мы получили лучшую производительность на вновь введенных данных, чем на старых.Я надеюсь, что хорошо объяснил проблему здесь.Дайте мне знать в случае любой недостающей информации.Спасибо

Редактировать 1

Позвольте мне немного описать архитектуру.У меня есть базовая таблица (назовем ее Base) с датой, id в качестве кластерного индекса.В нем около 50 столбцов. Затем у нас есть 5 производных таблиц (Derived1, Derived2, ...) в соответствии с различными типами метрик, которые также имеют Date, Id в качестве кластеризованного индекса и ограничение внешнего ключа для базовой таблицы.

Таблицы Derived1 и Derived2 имеют 350+ столбцов.Производные 3,4,5 имеют около 100-200 столбцов.Существует одно большое представление, созданное для объединения всех таблиц данных из-за ограничений инструмента BI.Дата, ID - это объединяющие столбцы для всех таблиц, соединяющихся для формирования представления (поэтому я создал кластерный индекс для этих столбцов).Основное беспокойство связано с производительностью инструмента BI.Инструмент BI всегда использует представление и обычно отправляет похожие запросы на сервер.

Есть и другие индексы для других столбцов фильтрации.Главный вопрос остается - как предотвратить ухудшение производительности.Кроме того, я хотел бы знать,

  1. Если NCI на дату, ID на всех таблицах будет лучше ставить в дополнение к кластерному индексу на дату, ID.
  2. Имеет ли смысл иметь 150 столбцов, включенных в NCI для производных таблиц?

Ответы [ 2 ]

0 голосов
/ 20 сентября 2018

У вас есть около 100 миллионов строк, растущих каждый день с новыми порциями, и эти новые порции обычно выбираются.Я должен использовать секционированные индексы с этими числами, а не обычные индексы.Ваше решение на сервере SQL будет разделение.Взгляните на разделение sql и посмотрите, сможете ли вы его принять.Разделение - это форма кластеризации, когда группы данных совместно используют физический блок.Например, если вы используете год и месяц, все записи 2018-09 года будут иметь одинаковое физическое пространство и их легко найти.Таким образом, если вы выбираете записи с этими фильтрами (и более того), это похоже на то, что таблица имеет размер 2018-09 записей.Это не совсем точно, но это очень похоже на это.Будьте осторожны со значениями данных для разбиения - в отличие от стандартных кластеров PK, где каждое значение является уникальным, столбец (столбцы) разделения должен приводить к хорошему набору различных уникальных комбинаций, таким образом, разделов.

Если вы не можете использовать разделы, вы должнысоздайте «разделы» самостоятельно, используя обычные индексы.Это потребует некоторых экспериментов.Основная идея - это данные (число?), Указывающие, например, волну или набор волн импортированных данных.Как и данные, импортированные сегодня и в следующие 10 дней, будет волна «1».Следующие 10 дней будут «2» и так далее.Фильтруя по последним, например, 10 волнам, вы работаете по последним 100-дневным импортам, эффективно пропуская все остальные данные.Грубо говоря, если вы разделите свои существующие 100 миллионов строк на 100 волн и начнете с волны 101 и начнете искать волны 90 или больше, тогда у вас будет 10 миллионов строк для поиска, если SQL правильно введен, чтобы сначала использовать новый индекс (будет в конечном итоге)

0 голосов
/ 19 сентября 2018

Это широкий вопрос, особенно не зная вашей системы.Но я бы попробовал обновить статистику вручную по индексам / таблицам, как только вы закончите загрузку данных.С такими большими таблицами маловероятно, что вы будете манипулировать достаточным количеством строк, чтобы вызвать автоматическое обновление.Без чистой статистики у SQL Server не будет точной гистограммы ваших данных.

Далее погрузитесь в свои планы выполнения и посмотрите, какие операторы самые дорогие.

...