Azure SQL Database a Fabric SQL Database: różnice w kosztach i zasobach obliczeniowych

By Mirko Peters · 2026-10-21

Porównanie kosztów zasobów obliczeniowych Azure SQL Database i Fabric SQL Database, skalowania bezserwerowego, jednostek pojemności, ekonomii magazynowania oraz kompromisów funkcjonalnych.

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

Wybór między Azure SQL Database a Fabric SQL Database sprowadza się do zrozumienia, czym różnią się alokacja zasobów obliczeniowych, zachowania skalowania i jednostki pojemności. Oba rozwiązania działają na tym samym wydajnym silniku SQL, jednak integracja Fabric z OneLake oraz modele wspólnej pojemności wprowadzają odrębne kwestie architektoniczne i kosztowe dla organizacji opartych na danych.

Najważniejsze wnioski

• Fabric SQL Database korzysta ze wspólnych jednostek pojemności Fabric (CU), a nie z samodzielnych warstw vCore platformy Azure.
• Zasoby obliczeniowe skalują się do zera i zwalniają automatycznie po 15 minutach bezczynności, co pozwala ograniczyć koszty.
• Magazyn jest rozliczany w sposób ciągły, co godzinę, a miejsce na kopie zapasowe jest bezpłatne do rozmiaru bazy danych podstawowej.
• Wbudowana replikacja lustrzana eliminuje ręczne potoki ETL, zapełniając w czasie rzeczywistym pliki Delta Parquet w OneLake.
• Tradycyjna usługa Azure SQL Database udostępnia dedykowane elastyczne pule oraz zadania SQL Server Agent, które środowiska Fabric obsługują inaczej.

Zasoby obliczeniowe: vCore a jednostki pojemności

Podczas migracji obciążeń lub planowania nowej architektury chmurowej zasadnicza różnica między tradycyjnym Azure SQL a Fabric SQL dotyczy zarządzania zasobami obliczeniowymi. W samodzielnej bazie danych Azure SQL udostępniasz dedykowane vCore lub zasoby obliczeniowe bezserwerowe, które odpowiadają bezpośrednio danej instancji bazy danych. Limity skalowania, okna konserwacji i poziomy wydajności zarządzasz w ramach każdej bazy osobno.

Natomiast baza danych Fabric SQL czerpie moc obliczeniową z szerszej puli pojemności Fabric należącej do organizacji. Ten model wspólnych zasobów oznacza, że baza danych dzieli budżet z raportami Power BI, potokami Data Factory i lakehouse'ami. Przelicznik między jednostkami pojemności Fabric (CU) a mocą bazy danych jest obsługiwany dynamicznie w tle. Na przykład przydział 64 jednostek pojemności odpowiada z grubsza 24,5 vCore dla obciążenia bazy danych. Takie ujednolicone podejście do puli zapobiega fragmentacji zasobów typowej dla środowisk z wieloma bazami danych i umożliwia dynamiczne współdzielenie zasobów w obrębie przestrzeni roboczej analitycznej.

Skalowanie bezserwerowe i zasady rozliczania bezczynności

Obie oferty baz danych wykorzystują architekturę bezserwerową, która zwiększa zasoby w szczytowym okresie wykonywania zapytań i zmniejsza je, gdy ruch słabnie. Zasady rozliczania czasu bezczynności są jednak szczególnie istotne przy prognozowaniu budżetu. Baza danych Fabric SQL stale monitoruje aktywność. Jeśli baza danych jest całkowicie bezczynna przez 15 minut, bez przychodzących zapytań, zwalnia wszystkie zasoby obliczeniowe, a koszt zasobów obliczeniowych spada do zera.

Aby zapobiec opóźnieniom zimnego startu dla kolejnego użytkownika, firma Microsoft stosuje celowy bufor retencji. Jeśli baza danych pracuje intensywnie przez dwie minuty, a potem milknie, płacisz za te dwie aktywne minuty oraz dodatkowe 15 minut zasobów obliczeniowych w stanie gotowości, czyli łącznie 17 minut. Magazyn natomiast pozostaje stały i jest rozliczany co godzinę, niezależnie od tego, czy baza danych przetwarza transakcje, czy pozostaje uśpiona.

Koszty magazynowania i ekonomia kopii zapasowych

Zarządzanie magazynem w Fabric SQL Database przynosi znaczące oszczędności kosztów w porównaniu z dotychczasowymi rozwiązaniami. Ponieważ baza danych automatycznie uruchamia ciągłe mirroring do OneLake, Twoje rekordy operacyjne są powielane w otwartych plikach Delta Parquet. Ten otwarty format sprawia, że dane nigdy nie są uwięzione w zastrzeżonym silosie, a każde narzędzie potrafiące odczytać format Delta może wysyłać zapytania bezpośrednio do zreplikowanej kopii.

Ponadto ekonomia kopii zapasowych w ekosystemie Fabric jest mocno zoptymalizowana. Funkcja przywracania do punktu w czasie pozwala administratorom cofnąć stan bazy nawet o siedem dni, aby odzyskać dane po przypadkowym uszkodzeniu lub poważnych błędach użytkowników. Magazyn kopii zapasowych jest całkowicie bezpłatny do wielkości Twojej głównej bazy danych. Dodatkowe opłaty pojawiają się wyłącznie wtedy, gdy zajmowana przez kopie zapasowe przestrzeń przekracza rozmiar samej aktywnej bazy, co stanowi przewidywalną finansową poduszkę bezpieczeństwa przy długoterminowym przechowywaniu danych.

Kompromisy operacyjne: co zyskujesz, a co tracisz

Choć główny silnik SQL jest identyczny na obu platformach, wybór Fabric SQL Database zamiast Azure SQL Database wymaga oceny konkretnych kompromisów funkcjonalnych. Znajomość tego, czego brakuje w implementacji Fabric, pozwala uniknąć nieoczekiwanych przeszkód architektonicznych podczas tworzenia rozwiązania.

Funkcje unikalne dla tradycyjnego Azure SQL

Samodzielne bazy danych Azure SQL natywnie obsługują pule elastyczne według nazwy, dając administratorom baz danych szczegółową kontrolę nad grupowaniem baz. Zawierają również klasyczny SQL Server Agent, na którym wiele starszych aplikacji opiera harmonogramowanie procedur składowanych i zadań konserwacyjnych.

Natywne zalety Fabric SQL

Fabric SQL eliminuje obciążenie administracyjne związane z konfigurowaniem zewnętrznych potoków replikacji. Mirroring uruchamia się automatycznie po utworzeniu bazy danych, dla wszystkich obsługiwanych tabel, bez konieczności ręcznej konfiguracji ETL. Dodatkowo usługa natywnie integruje się z Git w zakresie kontroli źródła i obsługuje konwencję nazewnictwa trzyczłonowego, co pozwala łatwo łączyć tabele operacyjne z lakehouse'ami i magazynami w jednym zapytaniu. Aby uzyskać kompleksowy przegląd tego, jak te elementy do siebie pasują, posłuchaj pełnego odcinka, w którym eksperci przedstawiają analizę i praktyczne strategie dla nowoczesnych architektów danych.

Często zadawane pytania

Jak wygląda rozliczanie bezczynnej bazy Fabric SQL Database?

Opłaty za moc obliczeniową są naliczane przez 15 minut po zakończeniu wykonywania ostatniego zapytania, aby utrzymać bazę w gotowości, a następnie koszty obliczeń spadają do zera. Magazyn jest rozliczany co godzinę niezależnie od aktywności.

Czy muszę ręcznie skonfigurować mirroring, aby dane trafiły do OneLake?

Nie. Mirroring uruchamia się automatycznie w momencie utworzenia Fabric SQL Database i nieprzerwanie synchronizuje tabele relacyjne do OneLake jako otwarte pliki Delta Parquet, bez własnego kodu ETL.

Czy mogę użyć SQL Server Agent do harmonogramowania zadań w Fabric SQL Database?

SQL Server Agent nie jest dostępny w Fabric SQL Database. Zamiast tego Microsoft zaleca korzystanie z potoków Data Factory lub zadań Apache Airflow do harmonogramowania i automatyzacji.

Jak rozliczane są kopie zapasowe w Fabric SQL?

Kopie zapasowe przywracania do punktu w czasie są całkowicie bezpłatne do łącznego rozmiaru magazynu aktywnej bazy danych. Płacisz za magazyn kopii zapasowych wyłącznie wtedy, gdy ich rozmiar przekracza rozmiar głównej bazy danych.