Пользователь
0,0
рейтинг
9 июля 2015 в 05:22

Разработка → Сможет ли Microsoft Azure найти такой индекс, который не смог найти ваш DBA?


Небольшой, но интересный анонс для тех, кто пользуется Azure SQL DB.
1-го июля вышел в публичное тестирование Index Advisor для Azure SQL Database.

Index Advisor – инструмент, доступный всем пользователям Azure SQL DB (V12) для создания non-clustered индексов. Index Advisor (IA) выдаёт список рекомендуемых индексов для вашей базы данных. Помогает их создать, а также автоматически протестировать! Анализируя нагрузку запросов и характер доступа к данным, IA выбирает те индексы, которые, по его мнению, принесут наибольший прирост производительности индивидуально для вашего сценария.



Так выглядит главная панель Index Advisor



На портале Microsoft Azure, помощник показывает таблицу с рекомендуемыми индексами. Каждая запись характеризует индекс по положительному влиянию на базу данных, показывает колонки и таблицу на которых будет создан индекс, а также время создание рекомендации.

В чём привлекательность Index Advisor?


Index Advisor работает совершенно прозрачно для пользователя. Сначала он подбирает вам список из нескольких индексов, создание которых максимально повысит производительность базы данных.
Затем, вы «заказываете» создание индекса, и в течение 48 часов вы получите отчет о проделанной работе.

Почему нужно 48 часов, чтобы создать индекс?


Все дело в том, что после создания индекса, Index Advisor проверит насколько хорошо этот он вписался в вашу рабочую нагрузку и, если результат негативный (производительность упала), Index Advisor автоматически удалит созданный им индекс.
48 часов, это максимально время, обычно операция заканчивается быстрее. Всё это без всякого вмешательства со стороны, и без потери соединения (ну и конечно данных).

Что это значит для меня?


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

Как мне попробовать?


Для того что бы попробовать Index Advisor вам необходимо:
  • Azure SQL Database на сервере V12
  • База данных которая использовалась в течении некоторого времени.

Важно отметить, что пока Index Advisor даёт рекомендации и позволяет создавать только non-clustered индексы.

Поехали:


  1. Заходим на портал
  2. Выбираем базу данных и в разделе Operations записываемся на публичное тестирование Index Advisor.
  3. Если у вас уже есть рекомендации, поздравляю! Вам повезло, сразу приступайте к оптимизации вашей базы данных.
  4. В противном случае, придётся подождать пару дней, пока Index Advisor накопит достаточно информации.
  5. Выбираем индекс из первой таблицы и нажимаем “Create Index” на панели справа.
    (Для любопытных: Если нажать “View Script”, то можно увидеть код матрицы посмотреть какой SQL запрос будет выполнен для создания индекса)



Когда создание и тестирование закончится, индекс появится в таблице оконченных операций.



Справа, результативность индекса: 2 запроса выполняютсяна 42% быстрее. Индекс занимает 22MB

Вот и всё!

Эй, а что это за …? Или ой, как круто!


Все чаще Микрософт старается слушать своих пользователей предоставляя разные механизмы обратной связи.
Если вам понравился Index Advisor и его рекомендации, не стесняйтесь об этом сказать. Ну а если он напортачил, или предложил создать глупый индекс, не стесняйтесь вдвойне и сообщите, нажав кнопку “Feedback”.



Документация на MSDN
Disclaimer: Я участвую в работе команды Index Advisor и постараюсь ответь на ваши вопросы, если они появятся.
Андрей Антюфеев @sitox
карма
4,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (15)

  • 0
    Для обычного, не-облачного SQL Server такое появится?
    • +2
      Уже давно есть Tuning Advisor идущая в комплекте. Работает по тому же принципу, от туда наверняка и взято ядро. Профайлинг — анализ — результаты. Причем стандартный умеет не только индексы. И уверен, что есть миллион других приложений, из разряда редгейтов и так далее.
      • 0
        Скорее используется общее ядро — системные DMV sys.dm_db_missing_index_groups, sys.dm_db_missing_index_group_stats, sys.dm_db_missing_index_details.
        Возможно, используется расширенная оценка для определения, насколько индекс ухудшит производительность вставки и сколько места займет.
        • 0
          Индекс действительно создаётся, и наблюдается в течении некоторого времени, если производительность падает, то он удаляется.
  • 0
    База данных которая использовалась в течении некоторого времени.

    Использовалась после включения IA или вообще?
    Если второй вариант, то ничего не рекомендует. Если первый, то сколько ждать?
    • 0
      Телеметрия собирается после создания базы данных, включение Index Advisor на это не влияет. (так же как она не влияет на производительность)
      Так может случиться, что ваша схема не требует улучшения в данный момент, тогда IA ничего не будет рекомендовать. (Поздравляю!)

      Когда IA обнаружит постоянную нагрузку, которую можно уменьшить с помощью индекса, вы увидите новую рекомендацию.
      Процесс ожидания зависит от вашей нагрузки, и IA должен быть уверен, прежде чем рекомендовать. Могу сказать, что пару часов будет точно недостаточно.

      Вероятно, в будущем, модель оповещения о рекомендации измениться от pull (когда вы проверяете каждую базу данных) на push, когда вам приходит скажем письмо о новой рекомендации.

      • 0
        Это база от рабочего приложения и оно уже давно вышло в люди.
        В свое время я довольно плотно наблюдал за временем выполнения отдельных запросов и создавал правильные индексы. Возможно поэтому и нет рекомендаций.
        Эх, не удалять же индексы ради теста…
        • 0
          Да, удалять индексы не стоит.
          Надеюсь в следующий раз, Index Advisor поможет вам сэкономить время и силы на наблюдении за запросами.
  • 0
    Index Advisor видит хинты в запросах? Наблюдал как заблуждается стандартный Index Advisor на БД Sharepoint (там в процедурах куча хинтов понаписано).
    • 0
      Нет, Index Advisor не смотрит на текст запроса. Он смотрит на характер доступа к данным и нагрузку. Если нагрузка постоянная и есть место для улучшения, он рекомендует индекс.

      Насколько я понимаю, подсказки в запросах, говорят какой план выполнения запроса выбрать. И скорее всего этот план уже достаточно хороший.
      (В этом SharePoint очень строг, разработчики предпочитают все контролировать сами)
      • 0
        Просто поделюсь наболевшим: из-за прибитых планов к запросу, анализатор постоянно советует создать бесполезные индексы(у вас, я так понял, случиться откат, раз есть наблюдение после). Разработчики SharePoint творят странные вещи, создают табличную функцию с параметрами и по этим параметрам прибивают план в запросе функции. Это гениальное решение идеально пока не встречается запрос использующий это идеальное творение в своих целях: select * from dbo.zzz(flag1,flag2) where Field2='1'. План не перестраивается оптимально и БД ложится. Запрос системный.
        • 0
          К сожалению не знаком с SharePoint насколько глубоко, чтобы помочь. Могу только посоветовать описать очень подробно проблему на сайте вроде Stackoverflow. Может кто-нибудь из команды SharePoint следит за этим. :)
  • 0
    1) Можно чуть подробней про анализ характер доступа к данным? Сотни индексов не будет создавать на таблицах где идут постоянные IUD?
    2) Есть прогнозный показатель размера индекса скажем через год? (После старта проекта он 10 MB, а через год уже 10GB)
    3) В алгоритме оценки участвует параметр степени влияния времени выполнения запроса на другие запросы? Если бы Index Advisor умел ускорять индексами запросы которые долго блокируют ресурсы это было бы явным шагом вперед по сравнению со стандартным анализом CPU, read, duration.
    4) Рекомендовать удалить индекс умеет? Скорей всего будут появляться индексы покрывающие предыдущие.
    Было бы интересно видеть сколько секунд времени будет экономиться в день от ввода индекса. (пожелания, мысли в слух)
    • 0
      Лучше поздно, чем никогда :)

      1) Index Advisor рекомендует те индексы, которые помогают конкретным запросам. (так же оценивает предполагаемое влияние). Так может случиться, что созданный индекс, не будет таким эфективным. (в основном потому что характер нагрузки изменился). Для этого существует этап верификации, когда оценивается общая картина нагрузки, и если созданый индекс ухудшает её, он автоматически удаляется.
      2) Это интересная идея, но пока Index Advisor не может предсказать как будет себя вести только что созданный индекс. Во многом потому что тут много переменных,(нагрузка, использование и т.д.) для того что бы дать предсказание хорошего качества.
      3) Это очень интересная идея, на данный момент Index Advisor не рассматривает влияние индекса на продолжительность запросов, кол-во блокировок. Но это то, на что бы обязательно обратим внимание в следующих версиях.
      4) Сейчас нет, но мы рабоает над этим функционалом. Скоро мы будем выдавать рекомендации, какие индексы не используются и их можно удалить. Stay tuned, как говорится ;)
  • 0
    Не туда

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