Уровень служб "Гипермасштабирование"

Область применения: База данных SQL Azure

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

  • уровни "Общего назначения" или "Стандартный";
  • уровни "Критически важный для бизнеса" или "Премиум";
  • Уровень "Гипермасштабирование"

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

Примечание

Каковы возможности ценовой категории "Гипермасштабирование"?

Уровень служб "Гипермасштабирование" в службе "База данных SQL Azure" предоставляет следующие дополнительные возможности:

  • Поддержка размера базы данных до 100 ТБ.
  • Быстрое резервное копирование базы данных (на основе моментальных снимков файлов, хранящихся в хранилище BLOB-объектов Azure) независимо от размера без влияния операций ввода-вывода на вычислительные ресурсы.
  • Быстрое восстановление баз данных (на основе файлов моментальных снимков) за несколько минут, а не часов или дней (вне зависимости от размера операции с данными).
  • Более высокая общая производительность благодаря высокой пропускной способности ведения журнала транзакций и ускоренной фиксации транзакций независимо от объемов данных.
  • Быстрое горизонтальное увеличение масштаба. Вы можете подготовить одну или несколько реплик только для чтения, чтобы переносить на них рабочие нагрузки чтения и использовать эти реплики в качестве серверов горячей замены.
  • Быстрое увеличение масштаба. Вы можете постоянно увеличивать масштаб вычислительных ресурсов, чтобы размещать крупные рабочие нагрузки по мере необходимости, а затем уменьшать их масштаб, когда они не нужны.

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

Кроме того, время, необходимое для создания резервных копий базы данных или увеличения/уменьшения масштаба, больше не привязано к объему данных в базе данных. Резервные копии баз данных уровня "Гипермасштабирование" могут создаваться практически мгновенно. Увеличивать или уменьшать масштаб баз данных с десятками терабайт данных можно за считаные минуты. Вы больше не ограничены первоначальными вариантами конфигурации.

Дополнительные сведения о размерах вычислительных ресурсов для уровня служб "Гипермасштабирование" см. в разделе Характеристики уровней служб.

Кому рекомендуется использовать уровень служб "Гипермасштабирование"

Уровень служб "Гипермасштабирование" предназначен для всех клиентов, которым требуется более высокая производительность и доступность, быстрое резервное копирование и восстановление, а также высокая масштабируемость хранилища и вычислений. Сюда входят клиенты, которые переходят в облако для модернизации своих приложений, а также клиенты, которые уже используют другие уровни служб в базе данных Azure SQL. Уровень служб "Гипермасштабирование" поддерживает широкий спектр рабочих нагрузок базы данных, от чистой OLTP до чистой аналитики. Он оптимизирован для рабочих нагрузок OLTP и гибридных транзакций и аналитической обработки (HTAP).

Важно!

Эластичные пулы не поддерживают уровень служб "Гипермасштабирование".

Модель ценообразования для ценовой категории "Гипермасштабирование"

Уровень служб "Гипермасштабирование" доступен только в модели на основе виртуальных ядер. Ввиду новой архитектуры модель ценообразования несколько отличается от уровней служб "Общего назначения" или "Критически важный для бизнеса".

  • Среда выполнения приложений

    Цена за единицу вычислений ценовой категории "Гипермасштабирование" на реплику. Цена Преимущество гибридного использования Azure автоматически применяется к высокодоступным и именованным репликам. Пользователи могут настроить общее количество вторичных реплик с высоким уровнем доступности от 0 до 4 в зависимости от требований к доступности и масштабируемости, а также создать до 30 именованных реплик для поддержки различных рабочих нагрузок чтения с горизонтальным масштабированием.

  • Хранилище.

    Указывать максимальный объем данных при настройке базы данных ценовой категории "Гипермасштабирование" не нужно. На уровне служб "Гипермасштабирование" счета за использование хранилища для базы данных выставляются на основе фактического использования. Хранилище автоматически выделяется от 10 ГБ до 100 ТБ и увеличивается с шагом в 10 ГБ при необходимости.

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

Сравнение ограничений по ресурсам

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

Общего назначения Гипермасштабирование Уровень "Критически важный для бизнеса"
Сценарии применения Предлагает бюджетные сбалансированные варианты вычислительных ресурсов и ресурсов хранилища. Большинства рабочих нагрузок. Автоматически масштабируемое хранилище размером до 100 ТБ, быстрое вертикальное и горизонтальное масштабирование вычислительных ресурсов, быстрое восстановление базы данных. OLTP-приложения с большим количеством транзакций и минимальной задержкой операций ввода-вывода. Обеспечивает наивысшую устойчивость к сбоям и быструю отработку отказов с помощью несколько синхронно обновляемых реплик.
Объем вычислительных ресурсов От 1 до 80 виртуальных ядер От 2 до 80 виртуальных ядер1 От 2 до 80 виртуальных ядер
Тип хранилища Удаленное хранилище класса Premium (для каждого экземпляра) Не связанное хранилище с локальным кэшем SSD (для каждого экземпляра) Сверхбыстрое локальное хранилище SSD (для каждого экземпляра)
Размер хранилища1 От 5 ГБ до 4 ТБ До 100 ТБ От 5 ГБ до 4 ТБ
ОПЕРАЦИЙ ВВОДА-ВЫВОДА 500 операций ввода-вывода в секунду на виртуальное ядро при 7000 операций ввода-вывода максимально Гипермасштабирование — это многоуровневая архитектура с кэшированием на нескольких уровнях. Эффективное число операций ввода-вывода в секунду зависит от рабочей нагрузки. 5000 операций ввода-вывода при 200 000 операций ввода-вывода максимально
Доступность 1 реплика, без горизонтального увеличения масштаба для чтения, высокий уровень доступности с избыточностью между зонами, без локального кэша Несколько реплик, до 4 масштабирования для чтения, высокий уровень доступности с избыточностью между зонами, частичный локальный кэш 3 реплики, горизонтальное увеличение масштаба для чтения до 1 реплики, высокая доступность, избыточная между зонами высокая доступность, полный локальный кэш
Резервные копии Выбор геоизбыточного, избыточного между зонами или локально избыточного хранилища резервных копий, хранение на протяжении 1–35 дней (по умолчанию — 7 дней) Выбор геоизбыточного, избыточного между зонами или локально избыточного хранилища резервных копий, хранение на протяжении 1–35 дней (по умолчанию — 7 дней) Выбор геоизбыточного, избыточного между зонами или локально избыточного хранилища резервных копий, хранение на протяжении 1–35 дней (по умолчанию — 7 дней)

1 Эластичные пулы не поддерживаются на уровне служб "Гипермасштабирование".

Примечание

Краткосрочное хранение резервных копий в течение 1–35 дней для баз данных уровня "Гипермасштабирование" теперь доступно в предварительной версии.

Архитектура распределенных функций

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

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

Архитектура

См. дополнительные сведения об архитектуре распределенных функций с Гипермасштабированием.

Преимущества масштабирования и производительности

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

Создание и администрирование баз данных с Гипермасштабированием

Вы можете создавать базы данных уровня "Гипермасштабирование" и управлять ими с помощью портал Azure, Transact-SQL, PowerShell и Azure CLI. См . краткое руководство. Создание базы данных уровня "Гипермасштабирование".

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

Если вы хотите перенести базу данных на другой уровень служб, например "Критически важный для бизнеса", сначала выполните обратную миграцию на уровень служб "Общего назначения", а затем измените уровень служб.
Узнайте, как выполнить обратный перенос с уровня "Гипермасштабирование", а также об ограничениях обратной миграции.

Высокий уровень доступности базы данных в варианте развертывания "Гипермасштабирование"

Как и со всеми другими уровнями служб, "Гипермасштабирование" гарантирует устойчивость данных для зафиксированных транзакций независимо от доступности реплики вычислений. Длительность простоя, вызванного недоступностью первичной реплики, зависит от типа отработки отказа (запланированной и незапланированной), от того, включена ли избыточность между зонами, а также от наличия по меньшей мере одной реплики высокой доступности. При плановой отработке отказа (т. е. в случае события обслуживания) система либо создает новую первичную реплику перед инициированием отработки отказа, либо использует существующую реплику высокой доступности в качестве цели отработки отказа. При внеплановой отработке отказа (т. е.в случае сбоя оборудования, относящегося к первичной реплике) система использует реплику высокой доступности в качестве цели отработки отказа, если таковая существует, или создает новую первичную реплику на основе пула доступных вычислительных ресурсов. В последнем случае продолжительность простоя выше из-за дополнительных действий, необходимых для создания новой первичной реплики.

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

Резервное копирование и восстановление

Операции резервного копирования и восстановления для баз данных с гипермасштабированием работают на основе моментальных снимков файлов. Это позволяет выполнять такие операции практически мгновенно. Так как в архитектуре гипермасштабирования резервное копирование и восстановление выполняются на уровне хранилища, значительно сокращается объем необходимых вычислений и нагрузка на реплики вычислительных ресурсов. Дополнительные сведения см. в разделе Резервные копии с Гипермасштабированием и избыточность хранилища.

Аварийное восстановление для баз данных уровня "Гипермасштабирование"

Если необходимо восстановить базу данных уровня "Гипермасштабирование" в базе данных SQL Azure в регионе, отличном от того, на котором она размещена, в рамках операции аварийного восстановления или детализации, перемещения или любой другой причины, основной метод заключается в выполнении географического восстановления базы данных. Геовосстановление доступно только в том случае, если для избыточности хранилища выбрано геоизбыточное хранилище (RA-GRS).

Подробнее см. статью Восстановление базы данных "Гипермасштабирование" в другом регионе.

Известные ограничения

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

Проблема Описание
Краткосрочное хранение резервных копий Краткосрочное хранение резервных копий в течение 1–35 дней для баз данных уровня "Гипермасштабирование" теперь доступно в предварительной версии. Обычную базу данных невозможно восстановить так же, как базу данных уровня "Гипермасштабирование", и наоборот.

Для баз данных, перенесенных на уровень служб "Гипермасштабирование" из других уровней служб базы данных SQL Azure, созданные перед миграцией резервные копии сохраняются в течение периода хранения резервных копии, настроенного для базы данных-источника. Восстановление резервной копии перед миграцией в течение периода хранения резервных копий базы данных поддерживается с помощью командной строки. Эти резервные копии можно восстановить с любым уровнем служб, кроме уровня "Гипермасштабирование".
Долгосрочное хранение резервных копий Долгосрочное хранение резервных копий для баз данных уровня "Гипермасштабирование" теперь доступно в предварительной версии.
Изменение уровня служб с уровня "Гипермасштабирование" на уровень общего назначения поддерживается непосредственно в ограниченных сценариях Обратная миграция с уровня "Гипермасштабирование" позволяет клиентам, которые недавно перенесли существующую базу данных Azure SQL на уровень служб "Гипермасштабирование", перейти на общего назначения уровень, если гипермасштабирование не соответствует их потребностям. Обратная миграция инициируется изменением уровня службы, но по сути это перемещение определенного объема данных между разными архитектурами. Для баз данных, созданных на уровне служб "Гипермасштабирование", нельзя выполнить обратную миграцию. Узнайте об ограничениях для обратной миграции.

Для баз данных, которые не имеют права на обратную миграцию, единственным способом перехода с уровня служб "Гипермасштабирование" на уровень служб, отличный от "Гипермасштабирования", является экспорт и импорт с помощью BACPAC-файла или других технологий перемещения данных (массовое копирование, Фабрика данных Azure, Azure Databricks, службы SSIS и т. д.). Экспорт и импорт bacpac из портал Azure, из PowerShell с помощью Командлета New-AzSqlDatabaseExport или New-AzSqlDatabaseImport, из Azure CLI с помощью az sql db export и az sql db import, а также из REST API не поддерживается. Импорт и экспорт BACPAC для баз данных (до 200 ГБ) уровня "Гипермасштабирование" поддерживается с помощью SSMS и SqlPackage версии 18.4 и более поздних. Для больших баз данных экспорт/импорт BACPAC может занять много времени и может завершиться ошибкой по различным причинам.
Эластичные пулы В настоящее время эластичные пулы не поддерживаются с БД уровня "Гипермасштабирование".
Миграция баз данных с помощью объектов In-Memory OLTP В режиме "Гипермасштабирование" поддерживается подмножество объектов OLTP In-Memory, включая типы таблиц, оптимизированные для памяти, табличные переменные и модули, скомпилированные в собственном формате. Однако если в переносимой базе данных присутствуют какие-либо In-Memory объекты OLTP, переход с уровней служб "Премиум" и критически важный для бизнеса на уровень "Гипермасштабирование" не поддерживается. Чтобы перенести такую базу данных на уровень "Гипермасштабирование", все объекты OLTP In-Memory и их зависимости должны быть удалены. После переноса базы данных эти объекты можно создать заново. Устойчивые и неустойчивые таблицы, оптимизированные для памяти, в настоящее время не поддерживаются в гипермасштабировании и должны быть изменены на дисковые таблицы.
Сжатие базы данных DbCC SHRINKDATABASE, DBCC SHRINKFILE или установка AUTO_SHRINK на уровне базы данных, в настоящее время не поддерживаются для баз данных с гипермасштабированием.
Проверка целостности базы данных В настоящее время команда DBCC CHECKDB не поддерживается для баз данных уровня служб "Гипермасштабирование". В качестве обходного решения можно использовать команды DBCC CHECKTABLE ('имя_таблицы') WITH TABLOCK и DBCC CHECKFILEGROUP WITH TABLOCK. Дополнительные сведения об управлении целостностью данных в базе данных SQL Azure см. в статье Целостность данных в базе данных SQL Azure.
Задания обработки эластичных баз данных Использование базы данных уровня "Гипермасштабирование" в качестве базы данных заданий не поддерживается. Но задания обработки эластичных баз данных могут применяться к базам данных уровня "Гипермасштабирование" так же, как и к любой другой Базе данных SQL Azure.
Синхронизация данных Использование базы данных уровня "Гипермасштабирование" в качестве центральной базы данных или базы данных метаданных синхронизации не поддерживается. Однако база данных с уровнем служб "Гипермасштабирование" может быть рядовой базой данных в топологии "Синхронизация данных".

Дальнейшие действия

Дополнительные сведения о Гипермасштабировании в Базе данных SQL Azure см. в следующих статьях: