Azure SQL Database и Fabric SQL Database: различия в стоимости и вычислительных ресурсах

By Mirko Peters · 2026-10-21

Сравнение стоимости вычислительных ресурсов Azure SQL Database и Fabric SQL Database, масштабирования без сервера, емкостных единиц, экономики хранения и компромиссов в функциональности.

Automatically translated with AI from the original post. Read the English original

Выбор между Azure SQL Database и Fabric SQL Database сводится к пониманию того, чем отличаются распределение вычислительных ресурсов, поведение масштабирования и емкостные единицы. Хотя обе базы работают на одном надежном движке SQL, интеграция Fabric с OneLake и модели общей емкости создают особые архитектурные и стоимостные соображения для организаций, которые строят работу на данных.

Главное

• Fabric SQL Database использует общие емкостные единицы (CU) Fabric, а не отдельные уровни vCore Azure.
• Вычислительные ресурсы масштабируются до нуля и автоматически освобождаются после 15 минут бездействия, что позволяет экономить деньги.
• Хранилище тарифицируется непрерывно, ежечасно, тогда как резервные копии бесплатны в пределах размера основной базы данных.
• Встроенное автоматическое зеркалирование исключает ручные конвейеры ETL, поскольку в режиме реального времени заполняет OneLake файлами Delta Parquet.
• Традиционная Azure SQL Database предоставляет выделенные эластичные пулы и задания SQL Server Agent, которые в средах Fabric работают иначе.

Вычисления: vCore или емкостные единицы

При миграции нагрузок или планировании новой облачной архитектуры ключевое различие между классическим Azure SQL и Fabric SQL заключается в управлении вычислительными ресурсами. В отдельной Azure SQL Database вы выделяете выделенные vCore или вычисления без сервера, которые напрямую привязаны к конкретному экземпляру базы данных. Лимиты масштабирования, окна обслуживания и уровни производительности вы настраиваете для каждой базы отдельно.

Fabric SQL Database, напротив, черпает вычислительную мощность из общего пула емкости Fabric вашей организации. Такая модель общих ресурсов означает, что база данных делит бюджет с отчетами Power BI, конвейерами Data Factory и lakehouse. Пересчет между емкостными единицами Fabric (CU) и мощностью базы данных выполняется динамически и скрыто от пользователя. Например, выделение 64 емкостных единиц примерно соответствует 24,5 vCore для нагрузки вашей базы данных. Такой единый пул предотвращает фрагментацию ресурсов, характерную для окружений с множеством баз данных, и позволяет динамически распределять ресурсы между всеми элементами аналитического рабочего пространства.

Масштабирование без сервера и правила оплаты простоя

Оба варианта баз данных используют архитектуру без сервера: они увеличивают ресурсы во время пиковых запросов и уменьшают их, когда нагрузка спадает. Однако механика оплаты простоя особенно важна для прогнозирования бюджета. Fabric SQL Database отслеживает активность непрерывно. Если база полностью простаивает 15 минут без входящих запросов, она освобождает все вычислительные ресурсы, и стоимость вычислений падает до нуля.

Чтобы избежать задержки холодного старта для следующего пользователя, Microsoft применяет намеренный буферный период хранения. Если база данных работает интенсивно две минуты, а затем затихает, вам выставляют счет за эти две активные минуты плюс 15 дополнительных минут вычислений в режиме ожидания, всего 17 минут. Хранилище же остается неизменным и тарифицируется каждый час, независимо от того, обрабатывает ли база транзакции или простаивает.

Экономика хранения и резервного копирования

Управление хранилищем в Fabric SQL Database даёт существенные преимущества по стоимости по сравнению с устаревшими конфигурациями. Поскольку база данных автоматически запускает непрерывное зеркалирование в OneLake, ваши оперативные данные дублируются в открытые файлы Delta Parquet. Этот открытый формат гарантирует, что данные никогда не окажутся запертыми в закрытом хранилище: любой инструмент, умеющий читать формат Delta, может выполнять запросы непосредственно к зеркальной копии.

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

Эксплуатационные компромиссы: что вы получаете и что теряете

Хотя основной движок SQL одинаков на обеих платформах, выбор Fabric SQL Database вместо Azure SQL Database требует оценки конкретных компромиссов по функциональности. Понимание того, чего нет в реализации Fabric, позволяет избежать неожиданных архитектурных препятствий на этапе разработки.

Функции, уникальные для классического Azure SQL

Отдельные базы данных Azure SQL нативно поддерживают эластичные пулы с указанием по имени, что даёт администраторам баз данных детальный контроль над группировкой баз. Они также включают классический SQL Server Agent, на который многие устаревшие приложения полагаются при планировании хранимых процедур и задач обслуживания.

Нативные преимущества Fabric SQL

Fabric SQL устраняет административные накладные расходы на настройку внешних конвейеров репликации. Как только вы создаёте базу данных, зеркалирование автоматически активируется для всех поддерживаемых таблиц без необходимости ручной настройки ETL. Кроме того, решение нативно интегрируется с Git для управления исходным кодом и поддерживает трёхчастные имена, что позволяет легко объединять оперативные таблицы с Lakehouse и Warehouse в одном запросе. Полное представление о том, как эти компоненты связаны между собой, вы получите, прослушав полный выпуск: там эксперты и практики делятся анализом и стратегиями для современных архитекторов данных.

Часто задаваемые вопросы

Как выставляется счёт за простаивающую базу данных Fabric SQL?

Оплата вычислительных ресурсов продолжается в течение 15 минут после завершения последнего запроса, чтобы база данных оставалась «разогретой», после чего затраты на вычисления падают до нуля. Хранение тарифицируется ежечасно независимо от активности.

Нужно ли вручную настраивать зеркалирование, чтобы данные попали в OneLake?

Нет. Зеркалирование запускается автоматически в момент создания базы данных Fabric SQL и непрерывно синхронизирует ваши реляционные таблицы в OneLake в виде открытых файлов Delta Parquet без пользовательского кода ETL.

Можно ли использовать SQL Server Agent для планирования заданий в Fabric SQL Database?

SQL Server Agent в Fabric SQL Database недоступен. Вместо него Microsoft рекомендует использовать конвейеры Data Factory или задания Apache Airflow для планирования и автоматизации.

Как выставляется счёт за резервные копии в Fabric SQL?

Резервные копии для восстановления на момент времени бесплатны в пределах общего объёма хранилища активной базы данных. Оплата за место под резервные копии начинается только тогда, когда объём резервных копий превышает размер основной базы данных.