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

  • Статья

Применимо к:База данных SQL Azure

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

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

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

Примечание.

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

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

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

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

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

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

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

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

Примечание.

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

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

Примечание.

Упрощенная цена на База данных SQL Azure Гипермасштабирование прибыла! Просмотрите новую ценовую категорию для База данных SQL Azure объявления о гипермасштабировании и сведения об изменении цен см. в разделе База данных SQL Azure Гипермасштабирование — более низкие, упрощенные цены!.

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

  • Подготовленные вычислительные ресурсы:

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

  • Бессерверные вычисления:

    Выставление счетов за бессерверные вычисления основано на использовании. Дополнительные сведения см. в разделе "Бессерверный уровень вычислений" для База данных SQL Azure.

  • Хранение.

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

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

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

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

ㅤ Общего назначения Критически важный для бизнеса Гипермасштабирование
Оптимально для Предлагает варианты бюджетных сбалансированных вычислений и хранилища. Приложения OLTP с высокой скоростью транзакций и низкой задержкой ввода-вывода. Обеспечивает высокую устойчивость к сбоям и быстрой отработке отказа с помощью нескольких горячих реплика. Самый широкий спектр рабочих нагрузок. Автоматически масштабируемое хранилище размером до 100 ТБ, быстрое вертикальное и горизонтальное масштабирование вычислительных ресурсов, быстрое восстановление базы данных.
Объем вычислительных ресурсов 2–128 виртуальных ядер 2–128 виртуальных ядер 2–128 виртуальных ядер 1
Тип хранилища Удаленное хранилище класса Premium (для каждого экземпляра) Сверхбыстрое локальное хранилище SSD (для каждого экземпляра) Разложенное хранилище с локальным кэшем SSD (на вычислительные реплика)
Размер хранилища1 От 1 ГБ до 4 ТБ От 1 ГБ до 4 ТБ 10 ГБ – 100 ТБ
ОПЕРАЦИЙ ВВОДА-ВЫВОДА 320 операций ввода-вывода в секунду на виртуальное ядро с максимальной скоростью 16 000 операций ввода-вывода в секунду 4000 операций ввода-вывода в секунду на виртуальное ядро с максимальным числом операций ввода-вывода в секунду 327 680 операций ввода-вывода в секунду 327 680 операций ввода-вывода в секунду с максимальным локальным SSD
Гипермасштабирование — это многоуровневая архитектура с кэшированием на нескольких уровнях. Эффективные операции ввода-вывода в секунду зависят от рабочей нагрузки.
Память и виртуальные ядра 5.1 ГБ 5.1 ГБ 5,1 ГБ или 10,2 ГБ
Доступность Один реплика, без горизонтального масштабирования чтения, избыточной между зонами высокой доступности Три реплика, одно горизонтальное масштабирование, избыточное между зонами. Несколько реплика, до четырех масштабируемых операций чтения, избыточной между зонами.
Резервные копии Выбор локально избыточного хранилища (LRS), избыточного между зонами (ZRS) или геоизбыточного хранилища (GRS)
Срок хранения 1–35 дней (семь дней по умолчанию) с доступным сроком хранения до 10 лет		 Выбор локально избыточного хранилища (LRS), избыточного между зонами (ZRS) или геоизбыточного хранилища (GRS)
Срок хранения 1–35 дней (семь дней по умолчанию) с доступным сроком хранения до 10 лет		 Выбор локально избыточного хранилища (LRS), избыточного между зонами (ZRS) или геоизбыточного хранилища (GRS)
Срок хранения 1–35 дней (семь дней по умолчанию) с доступным сроком хранения до 10 лет
Цены и выставление счетов Оплачиваются: виртуальное ядро, зарезервированное хранилище и хранилище резервных копий.
Плата за операции ввода-вывода в секунду не взимается.		 Оплачиваются: виртуальное ядро, зарезервированное хранилище и хранилище резервных копий.
Плата за операции ввода-вывода в секунду не взимается.		 Взимается плата за виртуальные ядра для каждого реплика, выделенного хранилища данных и хранилища резервных копий.
Плата за операции ввода-вывода в секунду не взимается.
Моделискидок 2 Зарезервированные экземпляры
Преимущество гибридного использования Azure 3
Подписки для разработки и тестирования категорий Корпоративная и с оплатой по мере использования		 Зарезервированные экземпляры
Преимущество гибридного использования Azure 3
Подписки для разработки и тестирования категорий Корпоративная и с оплатой по мере использования		 Зарезервированные экземпляры
Преимущество гибридного использования Azure 3
Подписки для разработки и тестирования категорий Корпоративная и с оплатой по мере использования

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

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

3 По состоянию на декабрь 2023 года Преимущество гибридного использования Azure недоступны для новых баз данных гипермасштабирования или в подписках разработки и тестирования. Существующие базы данных гипермасштабирования с подготовленными вычислительными ресурсами могут продолжать использовать Преимущество гибридного использования Azure для экономии затрат на вычисления до декабря 2026 года. Дополнительные сведения см. в блоге о ценах на гипермасштабирование.

Вычислительные ресурсы

Настройка оборудования ЦП Память
Серия Standard (5-е поколение) Подготовленные вычисления
— Intel® E5-2673 v4 (Broadwell) 2,3 ГГц, Intel® SP-8160 (Skylake)1, Intel® 8272CL (Каскадное озеро) 2,5 ГГц1, Intel® Xeon® Platinum 8370C (Ice Lake)1, AMD EPYC 7763v (Милан) процессоры
— Подготовка до 80 виртуальных ядер (с поддержкой технологии Hyper-Threading)

Бессерверные вычисления
— Intel® E5-2673 v4 (Broadwell) 2,3 ГГц, Intel® SP-8160 (Skylake)1, Intel® 8272CL (Каскадное озеро) 2,5 ГГц1, Intel® Xeon® Platinum 8370C (Ice Lake)1, AMD EPYC 7763v (Милан) процессоры
— автомасштабирование до 80 виртуальных ядер (гиперпоток)
— Соотношение памяти к виртуальным ядрам динамически адаптируется к памяти и использованию ЦП на основе спроса на рабочую нагрузку и может составлять не более 24 ГБ на виртуальное ядро. Например, в определенный момент времени рабочая нагрузка может использоваться и взиматься за 240 ГБ памяти и только 10 виртуальных ядер.		 Подготовленные вычисления
5,1 ГБ на виртуальное ядро.
— подготовка до 625 ГБ

Бессерверные вычисления
— автомасштабирование до 24 ГБ на виртуальное ядро
— автомасштабирование до 240 ГБ макс.
Серия Premium - Intel® Xeon® Platinum 8370C (Ice Lake), процессоры AMD EPYC 7763v (Милан)
— Подготовка до 128 виртуальных ядер (с поддержкой технологии Hyper-Threading)		 5,1 ГБ на виртуальное ядро.
Оптимизированная для памяти серии "Премиум" - Intel® Xeon® Platinum 8370C (Ice Lake), процессоры AMD EPYC 7763v (Милан)
— Подготовка до 80 виртуальных ядер (с поддержкой технологии Hyper-Threading)		 — 10,2 ГБ на виртуальное ядро

1 В sys.dm_user_db_resource_governance динамическом представлении управления оборудование для баз данных с помощью процессоров Intel® SP-8160 (Skylake) отображается в качестве поколения 6-го поколения, поколение оборудования для баз данных с помощью Intel 8272CL (Каскадное озеро) отображается как Gen7, а оборудование для баз данных с® помощью Intel®® Xeon Platinum 8370C (Ice Lake) или AMD® EPYC® 7763v (Милан) отображается как Gen8. Для заданного размера вычислительных ресурсов и конфигурации оборудования ограничения ресурсов одинаковы независимо от типа ЦП. Дополнительные сведения см. в разделе об ограничениях ресурсов для отдельных баз данных и эластичных пулов.

Бессерверный сервер поддерживается только на оборудовании серии "Стандартный" (5-го поколения).

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

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

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

Схема, на которой показана архитектура гипермасштабирования.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для баз данных, перенесенных на уровень служб "Гипермасштабирование" из других уровней служб базы данных SQL Azure, созданные перед миграцией резервные копии сохраняются в течение периода хранения резервных копии, настроенного для базы данных-источника. Восстановление резервной копии перед миграцией в течение периода хранения резервных копий базы данных поддерживается с помощью командной строки. Эти резервные копии можно восстановить с любым уровнем служб, кроме уровня "Гипермасштабирование".
Эластичные пулы Эластичные пулы теперь доступны в предварительной версии.
Миграция баз данных с помощью объектов In-Memory OLTP В режиме "Гипермасштабирование" поддерживается подмножество объектов OLTP In-Memory, включая типы таблиц, оптимизированные для памяти, табличные переменные и модули, скомпилированные в собственном формате. Тем не менее, если в базе данных переносятся объекты OLTP в памяти, миграция с уровней служб Premium и критически важный для бизнеса на гипермасштабирование не поддерживается. Чтобы перенести такую базу данных на уровень "Гипермасштабирование", все объекты OLTP In-Memory и их зависимости должны быть удалены. После переноса базы данных эти объекты можно создать заново. Устойчивые и не устойчивые таблицы, оптимизированные для памяти, в настоящее время не поддерживаются в гипермасштабировании и должны быть изменены на таблицы дисков.
Сжатие базы данных DBCC SHRINKDATABASE, DBCC SHRINKFILE или параметр AUTO_SHRINK on на уровне базы данных, в настоящее время не поддерживаются для баз данных с гипермасштабированием.
Проверка целостности базы данных В настоящее время команда DBCC CHECKDB не поддерживается для баз данных уровня служб "Гипермасштабирование". DBCC CHECKTABLE ('TableName') WITH TABLOCK и DBCC CHECKFILEGROUP WITH TABLOCK можно использовать в качестве обходного решения. Дополнительные сведения об управлении целостностью данных в базе данных SQL Azure см. в статье Целостность данных в базе данных SQL Azure.
Задания обработки эластичных баз данных Использование базы данных гипермасштабирования в качестве базы данных задания не поддерживается. Но задания обработки эластичных баз данных могут применяться к базам данных уровня "Гипермасштабирование" так же, как и к любой другой Базе данных SQL Azure.
Синхронизация данных Использование базы данных Гипермасштабирования в качестве концентратора или базы данных метаданных синхронизации не поддерживается. Однако база данных с уровнем служб "Гипермасштабирование" может быть рядовой базой данных в топологии "Синхронизация данных".
Оборудование уровня служб уровня "Премиум" уровня "Гипермасштабирование" Оборудование серии "Премиум" и оборудование, оптимизированное для памяти, не поддерживает бессерверный уровень вычислений.
Доступность в регионах Высокомасштабируемое оборудование уровня "Премиум" и "Премиум", оптимизированное для памяти, доступно в ограниченных регионах Azure. Список см. в разделе "Доступность серии "Премиум" с гипермасштабированием.

Связанный контент