Описание вариантов развертывания

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

Общие сведения о моделях развертывания

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

Как и виртуальные машины, База данных SQL можно развернуть с помощью различных методов, включая PowerShell, Azure CLI или портал Azure.

Отдельная база данных

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

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

Эластичные пулы

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

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

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

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

Общие сведения о моделях приобретения

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

На основе виртуальных ядер

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

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

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

Модель приобретения виртуальных ядер предлагает три варианта уровня служб:

Уровень служб	Возможность
Общего назначения	Этот уровень служб предназначен для менее интенсивных операций и предлагает экономичный баланс вычислительных ресурсов и параметров хранения. Он включает как подготовленные, так и бессерверные уровни вычислений, обеспечивая гибкость в соответствии с различными требованиями рабочей нагрузки при оптимизации бюджета.
Критически важный для бизнеса	Этот уровень идеально подходит для приложений, требующих низкой задержки и высокопроизводительного хранилища. Она поддерживает OLTP в памяти и включает встроенную реплику только для чтения. Кроме того, он предлагает больше памяти на ядро и использует локальное хранилище SSD, что делает его идеальным для рабочих нагрузок с учетом производительности.
Гипермасштабирование	Этот уровень предназначен для приложений с большими базами данных и высокими требованиями к пропускной способности. Гипермасштабирование предоставляет расширенные функции горизонтального масштабирования, что позволяет добавлять вычислительные узлы по мере увеличения размера данных. Она поддерживается исключительно в отдельных базах данных SQL и обеспечивает значительное масштабирование ресурсов хранилища и вычислительных ресурсов за пределами уровней служб общего назначения и критически важный для бизнеса уровней служб.

На основе DTU

В модели DTU существует три уровня служб: "Базовый", "Стандартный" и "Премиум". Ресурсы вычислений и хранилища зависят от уровня DTU, предлагая диапазон возможностей производительности с фиксированными ограничениями хранения, хранением резервных копий и затратами.

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

• Инициирование операции масштабирования, требующей внутренней отработки отказа.
• Добавление или удаление баз данных из эластичного пула.

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

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

Выполнение резервного копирования и восстановления

Azure предоставляет удобные возможности резервного копирования и восстановления для База данных SQL. Ниже приведены некоторые ключевые функции:

Непрерывное резервное копирование

База данных SQL Azure обеспечивает регулярное резервное копирование, непрерывно копируя их в геоизбыточное хранилище для чтения (RA-GRS). Полные резервные копии выполняются еженедельно, разностные резервные копии каждые 12–24 часа и резервные копии журналов транзакций каждые 5–10 минут.

геовосстановлением;

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

Восстановление на определенный момент времени (PITR)

Позволяет настроить определенную политику хранения на определенный момент времени для каждой базы данных, начиная от 1 до 35 дней (по умолчанию — семь дней). Базы данных также можно восстановить в определенный момент времени на одном сервере с помощью портал Azure, PowerShell, CLI или REST API.

Долгосрочное хранение (LTR)

Долгосрочное хранение эффективно в сценариях, требующих настройки политики хранения сверх срока, предоставляемого Azure. Можно задать политику хранения до 10 лет, и этот параметр по умолчанию отключен.

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

Включение автоматической настройки

Автоматическая настройка — это мощная встроенная функция, которая применяет машинное обучение для оптимизации производительности запросов. Он автоматически определяет возможности настройки и реализует их для повышения эффективности базы данных.

В настоящее время автоматическая настройка включает следующие функции:

• Определение дорогостоящих запросов
• Принудительное выполнение последнего плана хорошего выполнения
• Добавление индексов.
• Удаление индексов.

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

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

Использование эластичного запроса

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

Эластичные запросы поддерживают следующие сценарии секционирования:

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

Эта гибкость позволяет эластичным запросам эффективно управлять и запрашивать данные в нескольких базах данных.

настраивать задания обработки эластичных баз данных;

Функция эластичного задания служит заменой агент SQL Server для База данных SQL Azure, аналогично функции администрирования нескольких серверов в локальном экземпляре SQL Server.

С помощью эластичных заданий можно выполнять команды T-SQL в различных целевых развертываниях, включая База данных SQL, База данных SQL эластичные пулы и База данных SQL в картах сегментов. Эти ресурсы базы данных могут охватывать различные подписки и регионы Azure. Возможность параллельного выполнения полезна для автоматизации задач обслуживания базы данных, обеспечения эффективности и согласованности в развертываниях.

Перемещение данных с помощью Синхронизация данных SQL

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

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

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

Дополнительные сведения о настройке Синхронизации данных SQL см. учебнике Настройка Синхронизации данных SQL между базами данных в Базе данных SQL Azure и SQL Server.