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 використовує спільні одиниці ємності Fabric (CU), а не окремі рівні vCore Azure.
• Обчислювальні ресурси масштабуються до нуля й автоматично вивільняються після 15 хвилин бездіяльності, щоб заощадити витрати.
• Зберігання тарифікується безперервно щогодини, тоді як сховище резервних копій безкоштовне до розміру основної бази даних.
• Вбудоване автоматичне дзеркалювання усуває ручні конвеєри ETL, оскільки наповнює файли Delta Parquet в OneLake у реальному часі.
• Традиційна Azure SQL Database надає виділені elastic pools і завдання SQL Server Agent, з якими середовища Fabric працюють інакше.

Розуміння обчислень: vCore проти одиниць ємності

Під час міграції навантажень або планування нової хмарної архітектури фундаментальна відмінність між традиційним Azure SQL і Fabric SQL полягає в керуванні обчисленнями. В окремій Azure SQL Database ви виділяєте виділені vCore або обчислення Serverless, які безпосередньо прив’язані до вашого окремого екземпляра бази даних. Ви керуєте лімітами масштабування, вікнами обслуговування та рівнями продуктивності для кожної бази окремо.

Натомість 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 Database?

Оплата обчислювальних ресурсів триває ще 15 хвилин після завершення останнього запиту, щоб база даних залишалася «теплою», після чого витрати на обчислення падають до нуля. Сховище тарифікується щогодини незалежно від активності.

Чи потрібно вручну налаштовувати дзеркалювання, щоб дані потрапили в OneLake?

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

Чи можна використовувати SQL Server Agent для планування завдань у Fabric SQL Database?

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

Як тарифікуються резервні копії у Fabric SQL?

Резервні копії для відновлення на певний момент часу повністю безкоштовні в межах загального розміру сховища активної бази даних. Ви платите за сховище резервних копій лише тоді, коли обсяг резервних копій перевищує розмір основної бази даних.