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

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

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

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