Уровень служб "Гипермасштабирование"
Применимо к:
База данных SQL Azure
База данных SQL Azure основана на архитектуре ядра СУБД SQL Server, которая соответствует облачной среде, чтобы даже в случае сбоя инфраструктуры обеспечить высокий уровень доступности. Существует три варианта уровня служб в модели приобретения виртуальных ядер для База данных SQL Azure:
- Общее назначение
- Критически важный для бизнеса
- Уровень "Гипермасштабирование"
Уровень служб "Гипермасштабирование" подходит для всех типов рабочих нагрузок. Его облачная архитектура предоставляет независимо масштабируемые вычислительные ресурсы и хранилище для поддержки самых разнообразных традиционных и современных приложений. Вычислительные ресурсы и ресурсы хранилища в гипермасштабировании значительно превышают ресурсы, доступные на уровнях общего назначения и критически важный для бизнеса.
См. подробнее об уровнях служб Общего назначения и Критически важный для бизнеса в рамках модели приобретения на основе виртуальных ядер. Сравнение модели приобретения на основе виртуальных ядер с моделью приобретения на основе DTU см. в статье "Сравнение моделей приобретения на основе виртуальных ядер и DTU" База данных SQL Azure.
Уровень служб "Гипермасштабирование" в настоящее время доступен только для База данных SQL Azure, а не для Управляемый экземпляр SQL Azure.
Каковы возможности ценовой категории "Гипермасштабирование"?
Уровень служб "Гипермасштабирование" в службе "База данных SQL Azure" предоставляет следующие дополнительные возможности:
- Быстрое увеличение масштаба— вы можете в постоянном времени масштабировать вычислительные ресурсы, чтобы обеспечить высокую нагрузку при необходимости, а затем масштабировать вычислительные ресурсы, если это не требуется.
- Быстрое горизонтальное увеличение масштаба. Вы можете подготовить одну или несколько реплик только для чтения, чтобы переносить на них рабочие нагрузки чтения и использовать эти реплики в качестве серверов горячей замены.
- Автоматическое масштабирование, масштабирование и выставление счетов для вычислений на основе использования бессерверных вычислений.
- Оптимизированная цена и производительность для группы баз данных гипермасштабирования с различными требованиями к ресурсам с эластичными пулами.
- Автоматическое масштабирование хранилища с поддержкой до 128 ТБ базы данных или размером 100 ТБ эластичного пула.
- Более высокая общая производительность благодаря высокой пропускной способности ведения журнала транзакций и ускоренной фиксации транзакций независимо от объемов данных.
- Быстрое резервное копирование базы данных (на основе моментальных снимков файлов) независимо от размера без влияния ввода-вывода на вычислительные ресурсы.
- Быстрое восстановление базы данных или копирование (на основе моментальных снимков файлов) в минутах, а не в часах или днях.
Уровень служб "Гипермасштабирование" устраняет многие практические ограничения, традиционно наблюдаемые в облачных базах данных. В то время как большинство других баз данных ограничены ресурсами, доступными на одном узле, базы данных на уровне служб "Гипермасштабирование" не имеют таких ограничений. Благодаря гибкой архитектуре хранилища его объем растет по мере необходимости. На самом деле базы данных уровня "Гипермасштабирование" не создаются с определенным максимальным размером. База данных гипермасштабирования растет по мере необходимости, и плата взимается только за выделенную емкость хранилища. Для рабочих нагрузок интенсивного чтения уровень служб "Гипермасштабирование" обеспечивает быстрое горизонтальное увеличение масштаба путем подготовки дополнительных реплик при необходимости перенести рабочие нагрузки.
Кроме того, время, необходимое для создания резервных копий базы данных или увеличения/уменьшения масштаба, больше не привязано к объему данных в базе данных. Базы данных гипермасштабирования создаются практически мгновенно. Вы также можете масштабировать базу данных в десятках терабайтов вверх или вниз в течение нескольких минут в подготовленном вычислительном уровне или использовать бессерверные для автоматического масштабирования вычислений. Вы больше не ограничены первоначальными вариантами конфигурации.
Дополнительные сведения о размерах вычислительных ресурсов для уровня служб "Гипермасштабирование" см. в разделе Характеристики уровней служб.
Кому рекомендуется использовать уровень служб "Гипермасштабирование"
Уровень служб "Гипермасштабирование" предназначен для всех клиентов, которым требуется более высокая производительность и доступность, быстрое резервное копирование и восстановление, а также быстрое хранилище и масштабируемость вычислений. Он подходит как клиентам, которые выполняют миграцию в облако для модернизации своих приложений, так и клиентам, которые уже используют другие уровни служб в Базе данных SQL Azure. Уровень служб "Гипермасштабирование" поддерживает широкий спектр рабочих нагрузок базы данных от чистой OLTP до чистой аналитики. Он оптимизирован для рабочих нагрузок OLTP и гибридной транзакции и аналитической обработки (HTAP).
Модель ценообразования для ценовой категории "Гипермасштабирование"
Примечание.
Упрощенная цена на База данных SQL Azure Гипермасштабирование прибыла! Просмотрите новую ценовую категорию для База данных SQL Azure объявления о гипермасштабировании и сведения об изменении цен см. в разделе База данных SQL Azure Гипермасштабирование — более низкие, упрощенные цены!.
Уровень служб "Гипермасштабирование" доступен только в модели на основе виртуальных ядер. Ввиду новой архитектуры модель ценообразования несколько отличается от уровней служб "Общего назначения" или "Критически важный для бизнеса".
Подготовленные вычислительные ресурсы:
Цена за единицу вычислений ценовой категории "Гипермасштабирование" на реплику. Пользователи могут настроить общее количество вторичных реплик высокой доступности от 0 до 4 в зависимости от требований к доступности и масштабируемости и создать до 30 именованных реплик для поддержки различных рабочих нагрузок масштабирования чтения.
Бессерверные вычисления:
Выставление счетов за бессерверные вычисления основано на использовании. Дополнительные сведения см. в разделе "Бессерверный уровень вычислений" для База данных SQL Azure.
Хранение.
Указывать максимальный объем данных при настройке базы данных ценовой категории "Гипермасштабирование" не нужно. На уровне служб "Гипермасштабирование" счета за использование хранилища для базы данных выставляются на основе фактического использования. Хранилище автоматически выделяется в диапазоне от 10 ГБ до 128 ТБ и увеличивается в 10 ГБ при необходимости.
Дополнительные сведения о ценах на гипермасштабирование см. в База данных SQL Azure ценах.
Архитектура распределенных функций
Гипермасштабирование разделяет подсистему обработки запросов и компоненты, которые обеспечивают долгосрочное хранение и устойчивость данных. Эта архитектура позволяет плавно масштабировать емкость хранилища по мере необходимости (до 128 ТБ) и быстро масштабировать вычислительные ресурсы.
На следующей схеме показана функциональная архитектура гипермасштабирования:
См. дополнительные сведения об архитектуре распределенных функций с Гипермасштабированием.
Преимущества масштабирования и производительности
Благодаря возможности быстро развертывать и свертывать дополнительные вычислительные узлы, предназначенные только для чтения, архитектура уровня "Гипермасштабирование" предоставляет значительные возможности масштабирования для чтения и также может освобождать первичный вычислительный узел для обслуживания большего количества запросов на запись. Кроме того, вычислительные узлы можно быстро увеличивать или уменьшать в масштабе благодаря архитектуре уровня "Гипермасштабирование" с общим хранилищем. Вычислительные узлы только для чтения в гипермасштабировании также доступны на бессерверном уровне вычислений, который автоматически масштабирует вычисления на основе спроса на рабочую нагрузку.
Высокий уровень доступности базы данных в варианте развертывания "Гипермасштабирование"
Как и со всеми другими уровнями служб, "Гипермасштабирование" гарантирует устойчивость данных для зафиксированных транзакций независимо от доступности реплики вычислений. Длительность простоя, вызванного недоступностью первичной реплики, зависит от типа отработки отказа (запланированной и незапланированной), от того, включена ли избыточность между зонами, а также от наличия по меньшей мере одной реплики высокой доступности. В плановая отработка отказа (например, в случае события обслуживания) система создает новую первичную реплику перед запуском отработки отказа или использует существующую реплику высокой доступности в качестве целевого объекта отработки отказа. В не плановая отработка отказа (например, сбой оборудования на первичной реплике), система использует реплику высокой доступности в качестве целевой точки отработки отказа, если она существует, или создает новую первичную реплику из пула доступной вычислительной емкости. В последнем случае продолжительность простоя выше из-за дополнительных действий, необходимых для создания новой первичной реплики.
Вы можете выбрать период обслуживания, который позволяет создавать прогнозируемые и менее разрушительные события обслуживания для рабочей нагрузки.
Соглашение об уровне обслуживания для уровня служб "Гипермасштабирование" см. в статье Соглашение об уровне обслуживания для базы данных SQL Azure.
Буферный пул, расширение отказоустойчивого буферного пула и непрерывная подготовка
В гипермасштабировании базы данных Azure существует отдельное разделение между вычислительными ресурсами и хранилищем. Хранилище содержит все страницы базы данных в одной базе данных и может быть выделено на нескольких компьютерах по мере роста базы данных. Однако вычислительный узел кэширует только то, что используется в последнее время. Наиболее горячие страницы вычислений хранятся в памяти в структуре, называемой буферным пулом (BP). Он также хранится в локальном SSD, расширении отказоустойчивого буферного пула (RBPEX), поэтому данные можно получить быстрее при перезапуске вычислительного процесса.
В облачной системе вычислительные ресурсы могут перемещаться на разные компьютеры по мере необходимости. Уровень вычислений может иметь несколько реплик. Один является основным и получает все обновления, а другие — вторичные реплики. В случае первичного сбоя одна из вторичных реплик высокой доступности может быстро повысить уровень до первичной в процессе, называемом отработкой отказа. Вторичная реплика может не содержать кэш в ее BP и RBPEX, оптимизированный для основной рабочей нагрузки.
Непрерывная подготовка — это процесс, который собирает сведения о том, какие страницы являются самыми горячими во всех вычислительных репликах. Эти сведения агрегируются, а вторичные реплики высокой доступности используют список самых горячих страниц, соответствующих типичной рабочей нагрузке клиента. Это заполняет как BP, так и RBPEX самыми горячими страницами, постоянно выполняя изменения в рабочей нагрузке клиента.
Без непрерывной начальной подготовки реплики BP и RBPEX не наследуются новыми репликами высокой доступности и восстанавливаются только во время рабочей нагрузки пользователя. Непрерывная подготовка экономит время и предотвращает несогласованную производительность, так как не ожидается, прежде чем кэши полностью гидратируются. При непрерывной подготовке новые вторичные реплики высокого уровня доступности сразу же начнут приступать к подготовке данных BP и RBPEX. Это поможет обеспечить производительность более согласованно, так как происходит отработка отказа.
Непрерывная примыка работает в обоих способах: вторичные реплики высокой доступности кэшируют страницы, используемые в первичной реплике, и первичный кэширует страницы с рабочей нагрузкой из вторичных реплик.
Примечание.
Непрерывная подготовка в настоящее время находится в закрытой предварительной версии и недоступна для бессерверных баз данных. Дополнительные сведения и согласие на непрерывную приматку см . в блоге: усовершенствования гипермасштабирования за ноябрь 2024 г.
Резервное копирование и восстановление
Операции резервного копирования и восстановления для баз данных с гипермасштабированием работают на основе моментальных снимков файлов. Это позволяет выполнять такие операции практически мгновенно. Так как архитектура гипермасштабирования использует уровень хранилища для резервного копирования и восстановления, нагрузка на обработку и производительность реплик вычислений уменьшается. Дополнительные сведения см. в разделе Резервные копии с Гипермасштабированием и избыточность хранилища.
Аварийное восстановление для баз данных уровня "Гипермасштабирование"
Если необходимо восстановить базу данных уровня "Гипермасштабирование" в базе данных SQL Azure в регионе, отличном от того, на котором она размещена, в рамках операции аварийного восстановления или детализации, перемещения или любой другой причины, основной метод заключается в выполнении географического восстановления базы данных. Геовосстановление доступно только в том случае, если для избыточности хранилища выбрано геоизбыточное хранилище (RA-GRS).
Подробнее см. статью Восстановление базы данных "Гипермасштабирование" в другом регионе.
Сравнение ограничений по ресурсам
Уровни служб на основе виртуальных ядер различаются на основе доступности базы данных, типа хранилища, производительности и максимального размера хранилища. Эти различия описаны в следующей таблице:
| ㅤ | Общего назначения | Критически важный для бизнеса | Гипермасштабирование |
|---|---|---|---|
| Оптимально для | Предлагает варианты бюджетных сбалансированных вычислений и хранилища. | Приложения OLTP с высокой скоростью транзакций и низкой задержкой ввода-вывода. Обеспечивает высокую устойчивость к сбоям и быстрой отработке отказа с помощью нескольких реплик горячего резервного копирования. | Самый широкий спектр рабочих нагрузок. Размер хранилища автомасштабирования до 128 ТБ, быстрое вертикальное и горизонтальное масштабирование вычислительных ресурсов, быстрое восстановление базы данных. |
| Объем вычислительных ресурсов | 2–128 виртуальных ядер | 2–128 виртуальных ядер | 2–128 виртуальных ядер |
| Тип хранилища | Удаленное хранилище класса Premium (для каждого экземпляра) | Сверхбыстрое локальное хранилище SSD (для каждого экземпляра) | Отсоединяемое хранилище с локальным кэшем SSD (на реплику вычислений) |
| Размер хранилища | От 1 ГБ до 4 ТБ | От 1 ГБ до 4 ТБ | 10 ГБ – 128 ТБ |
| ОПЕРАЦИЙ ВВОДА-ВЫВОДА | 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 лет |
| Цены и выставление счетов | Оплачиваются: виртуальное ядро, зарезервированное хранилище и хранилище резервных копий. Плата за операции ввода-вывода в секунду не взимается. |
Оплачиваются: виртуальное ядро, зарезервированное хранилище и хранилище резервных копий. Плата за операции ввода-вывода в секунду не взимается. |
Взимается плата за виртуальные ядра для каждой реплики, выделенного хранилища данных и хранилища резервных копий. Плата за операции ввода-вывода в секунду не взимается. |
| Моделискидок 1 | Зарезервированные экземпляры Преимущество гибридного использования Azure 2 Корпоративные и разработка и тестирование с оплатой по мере использования подписки |
Зарезервированные экземпляры Преимущество гибридного использования Azure 2 Корпоративные и разработка и тестирование с оплатой по мере использования подписки |
Зарезервированные экземпляры Преимущество гибридного использования Azure 2 Корпоративные и разработка и тестирование с оплатой по мере использования подписки |
1 Упрощенная цена на База данных SQL Гипермасштабирование прибыла в декабре 2023 года. Дополнительные сведения см. в блоге о ценах на гипермасштабирование.
2 По состоянию на декабрь 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-го поколения).
Создание и администрирование баз данных с Гипермасштабированием
Вы можете создавать и администрировать базы данных с Гипермасштабированием с помощью портала Azure, Transact-SQL, PowerShell и Azure CLI. Дополнительные сведения см . в кратком руководстве по созданию базы данных гипермасштабирования.
| Операция | Сведения | Подробнее |
|---|---|---|
| Создание базы данных гипермасштабирования | Базы данных ценовой категории "Гипермасштабирование"доступны только при использовании модели приобретения на основе виртуальных ядер. | Примеры того, как создать базу данных уровня "Гипермасштабирование", см. в статье Краткое руководство. Создание базы данных уровня "Гипермасштабирование" в Базе данных SQL Azure. |
| Перевод существующей базы данных на уровень "Гипермасштабирование" | Перенос существующей базы данных в базе данных SQL Azure на уровень "Гипермасштабирование"— это операция с размером данных. | Узнайте, как перенести существующую базу данных на уровень "Гипермасштабирование". |
| Обратная миграция базы данных Гипермасштабирования на уровень служб общего назначения | Если вы ранее перенесли существующую Базу данных SQL Azure на уровень служб "Гипермасштабирование", можно отменить миграцию базы и вернуть ее на уровень служб "Общего назначения" в течение 45 дней после первоначальной миграции на уровень "Гипермасштабирование". Если вы хотите перенести базу данных на другой уровень служб, например "Критически важный для бизнеса", сначала выполните обратную миграцию на уровень служб "Общего назначения", а затем измените уровень служб. |
Узнайте, как выполнить обратный перенос с уровня "Гипермасштабирование", а также об ограничениях обратной миграции. |
Сжать
Операции сжатия баз данных и файлов в настоящее время находятся в предварительной версии для База данных SQL Azure гипермасштабирования. Дополнительные сведения о предварительной версии см. в разделе "Сжатие" для База данных SQL Azure гипермасштабирования.
Известные ограничения
Это текущие ограничения для уровня служб "Гипермасштабирование". Мы активно работаем над удалением максимально возможного множества этих ограничений.
| Проблема | Описание |
|---|---|
| Сжатие блокируется при отключении TDE | В настоящее время операции сжатия баз данных и файлов не поддерживаются при отключении прозрачное шифрование данных (TDE) в База данных SQL Azure гипермасштабировании. |
| Восстановление базы данных из других уровней служб | Обычную базу данных невозможно восстановить так же, как базу данных уровня "Гипермасштабирование", и наоборот. Для баз данных, перенесенных на уровень служб "Гипермасштабирование" из других уровней служб базы данных SQL Azure, созданные перед миграцией резервные копии сохраняются в течение периода хранения резервных копии, настроенного для базы данных-источника. Восстановление резервной копии перед миграцией в течение периода хранения резервных копий базы данных поддерживается с помощью командной строки. Эти резервные копии можно восстановить с любым уровнем служб, кроме уровня "Гипермасштабирование". |
| Миграция баз данных с помощью объектов In-Memory OLTP | В режиме "Гипермасштабирование" поддерживается подмножество объектов OLTP In-Memory, включая типы таблиц, оптимизированные для памяти, табличные переменные и модули, скомпилированные в собственном формате. Тем не менее, если в базе данных переносятся объекты OLTP в памяти, миграция с уровней служб Premium и критически важный для бизнеса на гипермасштабирование не поддерживается. Чтобы перенести такую базу данных на уровень "Гипермасштабирование", все объекты OLTP In-Memory и их зависимости должны быть удалены. После переноса базы данных эти объекты можно создать заново. Устойчивые и не устойчивые таблицы, оптимизированные для памяти, в настоящее время не поддерживаются в гипермасштабировании и должны быть изменены на таблицы дисков. |
| Проверка целостности базы данных | В настоящее время команда DBCC CHECKDB не поддерживается для баз данных уровня служб "Гипермасштабирование". DBCC CHECKTABLE ('TableName') WITH TABLOCK и DBCC CHECKFILEGROUP WITH TABLOCK можно использовать в качестве обходного решения. Дополнительные сведения об управлении целостностью данных в базе данных SQL Azure см. в статье Целостность данных в базе данных SQL Azure. |
| Задания обработки эластичных баз данных | Использование базы данных гипермасштабирования в качестве базы данных задания не поддерживается. Но задания обработки эластичных баз данных могут применяться к базам данных уровня "Гипермасштабирование" так же, как и к любой другой Базе данных SQL Azure. |
| Синхронизация данных | Использование базы данных Гипермасштабирования в качестве концентратора или базы данных метаданных синхронизации не поддерживается. Однако база данных с уровнем служб "Гипермасштабирование" может быть рядовой базой данных в топологии "Синхронизация данных". |
| Оборудование уровня служб уровня "Премиум" уровня "Гипермасштабирование" | Оборудование серии "Премиум" и оборудование, оптимизированное для памяти, не поддерживает бессерверный уровень вычислений. |
| Доступность в регионах | Высокомасштабируемое оборудование уровня "Премиум" и "Премиум", оптимизированное для памяти, доступно в ограниченных регионах Azure. Список см. в разделе "Доступность серии "Премиум" с гипермасштабированием. |
Связанный контент
- Часто задаваемые вопросы о гипермасштабировании
- Сравнение моделей приобретения на основе виртуальных ядер и DTU База данных SQL Azure
- Управление ресурсами в базе данных SQL Azure
- Ограничения ресурсов для отдельных баз данных с использованием модели приобретения виртуального ядра
- Сравнение функций: База данных SQL Azure и Управляемый экземпляр SQL Azure
- Архитектура распределенных функций с гипермасштабированием
- Управление базой данных гипермасштабирования