Динамическое масштабирование ресурсов базы данных с минимальным временем простоя — База данных SQL Azure и Управляемый экземпляр SQL Azure

  • Статья

Применимо к:База данных SQL Azure Управляемый экземпляр SQL Azure

База данных SQL Azure и Управляемый экземпляр SQL Azure позволяют динамически добавлять дополнительные ресурсы в базу данных с минимальным временем простоя. Однако в течение короткого времени подключение теряется в базе данных, что может быть устранено с помощью логики повторных попыток.

Обзор

Когда спрос на ваше приложение увеличится с нескольких устройств и клиентов до миллионов, Базу данных SQL Azure и Управляемый экземпляр SQL можно будет моментально масштабировать с минимальным временем простоя. Масштабируемость является одной из важнейших характеристик PaaS (платформы как услуги), которая позволяет при необходимости динамически добавлять дополнительные ресурсы в службу. База данных SQL Azure позволяет легко изменять выделенные для баз данных ресурсы (загрузку ЦП, объем памяти, пропускную способность операций ввода-вывода и объем хранения).

При этом вы можете избежать проблем с производительностью, которые возникают при более интенсивном использовании приложения и которые нельзя устранить с помощью индексации или методов переопределения запросов. Благодаря возможности добавления ресурсов вы можете оперативно реагировать на ситуации, когда база данных достигает текущих ограничений ресурсов и ей требуются дополнительные ресурсы для обработки входящих рабочих нагрузок. База данных SQL Azure также позволяет уменьшать объем ресурсов, когда они не нужны, и, таким образом, снижать расходы.

Вам не нужно беспокоиться о приобретении оборудования и изменении базовой инфраструктуры. Вы сможете легко выполнить масштабирование базы данных с помощью ползунка на портале Azure.

Scale database performance

База данных SQL Azure поддерживает модель приобретения на основе единиц DTU и модель приобретения на основе виртуальных ядер, а Управляемый экземпляр SQL Azure — только модель приобретения на основе виртуальных ядер.

  • В модели приобретения на основе единиц DTU набор вычислительных операций, памяти и ресурсов ввода-вывода предоставляется на трех уровнях обслуживания: "Базовый", "Стандартный" и "Премиум". Каждый уровень предусматривает поддержку различных рабочих нагрузок баз данных. Для каждого уровня производительности на уровнях обслуживания предусмотрено отдельное сочетание этих ресурсов, к которым можно добавить ресурсы хранилища.
  • Модель приобретения на основе виртуальных ядер позволяет выбрать количество виртуальных ядер, объем памяти и размер и скорость хранилища. Эта модель приобретения предлагает три уровня служб: общего назначения, "Критически важный для бизнеса" и "Гипермасштабирование".

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

Примечание.

Ниже указаны важные исключения, когда изменить уровень служб базы данных невозможно:

  • Базы данных, использующие функции, которые доступны только на уровнях служб "Критически важный для бизнеса" и "Премиум", невозможно переключить на уровень служб "Стандартный" или "Общего назначения". В настоящее время единственным таким компонентом является OLTP в памяти.
  • Базы данных, изначально созданные на уровне служб "Гипермасштабирование", не могут быть перенесены на другие уровни служб. Если вы ранее перенесли существующую Базу данных SQL Azure на уровень служб "Гипермасштабирование", можно отменить миграцию базы на уровень служб общего назначения в течение 45 дней после первоначальной миграции в гипермасштабирование. Если вы хотите перенести базу данных на другой уровень служб, например, "Критически важный для бизнеса", сначала выполните обратную миграцию на уровень служб общего назначения, а затем выполните соответствующую миграцию. Дополнительные сведения см. в разделе Обратная миграция с уровня служб "Гипермасштабирование".

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

Служба "База данных SQL Azure" поддерживает возможность динамического масштабирования баз данных.

  • Для отдельной базы данных можно воспользоваться моделями на основе DTU или виртуальных ядер, чтобы определить максимальное количество ресурсов, которые будут назначены каждой базе данных.
  • Эластичные пулы позволяют определять максимальный предел использования ресурсов для каждой группы баз данных в пуле.

Управляемый экземпляр Azure SQL также поддерживает масштабирование:

  • Управляемый экземпляр использует режим виртуальных ядер и позволяет определять максимальное число ядер ЦП и максимальный объем хранилища, выделяемый экземпляру. Ресурсы, выделенные управляемому экземпляру, будут общими для всех баз данных в этом экземпляре.

Совет

Динамическое масштабирование позволяет клиентам изменять выделение ресурсов вручную или программно. Возможность динамического масштабирования доступна для всех База данных SQL Azure и Управляемый экземпляр SQL Azure ресурсов.

Помимо поддержки динамического масштабирования, уровень бессерверных серверов в База данных SQL Azure поддерживает автомасштабирование. Базы данных на бессерверном уровне масштабируют ресурсы автоматически в пределах заданного клиентом диапазона в зависимости от спроса на рабочую нагрузку. Для масштабирования базы данных не требуется никаких действий клиента.

Влияние операций вертикального увеличения и уменьшения масштаба

Запуск действия вертикального увеличения и уменьшения масштаба в любом из упомянутых выше вариантов приведет к перезапуску процесса ядра СУБД и перемещению его на другую виртуальную машину, если это необходимо. Перемещение процесса ядра СУБД на новую виртуальную машину — это оперативный процесс, в ходе которого можно продолжать работать с существующей службой Базы данных SQL Azure. Когда целевое ядро СУБД будет готово к обработке запросов, открытые подключения к текущему ядру СУБД будут завершены, и будет выполнен откат незафиксированных транзакций. Будут осуществлены новые подключения к целевому ядру СУБД.

Примечание.

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

Примечание.

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

Альтернативные методы масштабирования

Масштабирование ресурсов — это самый простой и эффективный способ повышения производительности базы данных без изменения кода базы или приложения. В некоторых случаях для эффективной и экономичной обработки рабочей нагрузки может быть недостаточно даже самых высоких уровней служб, объемов вычислительных ресурсов и оптимизации производительности. Тогда вы можете воспользоваться дополнительными вариантами масштабирования базы данных:

  • Масштабирование для чтения — это функция, при использовании которой вы получаете одну реплику данных только для чтения с возможностью выполнения ресурсоемких запросов только для чтения, таких как отчеты. Реплика только для чтения будет обрабатывать рабочую нагрузку только для чтения, не влияя на использование ресурсов базы данных-источника.
  • Сегментирование базы данных — это набор методов, который позволяет разделять данные по нескольким базам данных и масштабировать их независимо друг от друга.

Следующие шаги