Databases w Fabric: jak ocenić bazę aplikacji

SQL database w Microsoft Fabric warto oceniać jako bazę obsługującą konkretną aplikację: zapis zlecenia, zmianę statusu czy rezerwację zasobu. O wyborze powinny decydować poprawność transakcji, wymagany czas odpowiedzi i możliwość odtworzenia działania po awarii. Sama obecność bazy w platformie analitycznej nie dowodzi, że będzie właściwym miejscem dla każdego systemu firmy.

Jeśli odpowiadasz za obsługę zleceń, zacznij od jednego pytania: co musi się wydarzyć, żeby pracownik mógł bezpiecznie uznać operację za zakończoną? To pozwala oddzielić potrzeby aplikacji od potrzeb raportu, który później pokaże jej wyniki.

Co oznacza Databases w Fabric

Databases to obszar baz danych platformy. W tym artykule przyglądam się SQL database, czyli relacyjnej bazie transakcyjnej. Microsoft opisuje ją jako usługę wykorzystującą ten sam silnik co Azure SQL Database, przeznaczoną do obciążeń operacyjnych OLTP. Szczegóły i dostępne możliwości przedstawia dokumentacja SQL database w Fabric.

Przykładowym zastosowaniem jest aplikacja rejestrująca zlecenia i ich pozycje. Baza ma pilnować relacji między rekordami oraz wykonywać operacje zgodnie z zaprojektowanymi regułami. Nadal potrzebujesz schematu danych, kodu aplikacji, uprawnień i procedur utrzymania. Model usługi zarządzanej ogranicza część pracy infrastrukturalnej, ale nie przejmuje odpowiedzialności za logikę procesu.

Nie przenoś automatycznie ustaleń dotyczących SQL database na wszystkie produkty dostępne w obszarze Databases. Inny silnik lub model danych oznacza osobną ocenę zgodności aplikacji, integracji i ograniczeń.

Zapis operacyjny i odczyt analityczny to dwa zadania

SQL database automatycznie replikuje obsługiwane dane do OneLake. Operacyjna baza przechowuje dane w plikach właściwych silnikowi SQL, a kopia analityczna korzysta z formatu Delta Parquet. SQL analytics endpoint umożliwia odczyt tej kopii; nie służy do zapisywania zmian w bazie aplikacji. Zasady opisuje dokumentacja mirroringu SQL database.

Replikacja nie oznacza, że raport i aplikacja zawsze widzą ten sam moment. Potwierdzenie przyjęcia zamówienia powinno wynikać z zakończonej transakcji w systemie operacyjnym. Raport może chwilowo prezentować wcześniejszy stan. Tę różnicę trzeba uwzględnić w komunikatach dla użytkowników i w kontroli aktualności danych.

Potrzeba procesu	Co sprawdzić w projekcie	Dowód przed odbiorem
Zapis zlecenia i pozycji	Jedną transakcję obejmującą wymagane zmiany	Błąd jednej części nie zostawia niekompletnego zlecenia
Raport o nowych zleceniach	Opóźnienie kopii analitycznej	Porównanie czasu zapisu i dostępności w raporcie
Ponowienie po zerwanym połączeniu	Rozpoznawanie tej samej operacji	Druga próba nie tworzy drugiego zlecenia
Analiza historii statusów	Jawny sposób zapisywania zmian	Można odtworzyć kolejność zdarzeń

Nie zakładaj też, że automatyczna kopia zastępuje model historyczny. Jeżeli aplikacja nadpisuje status zlecenia, trzeba osobno zaprojektować zapis jego zmian, gdy analiza wymaga odpowiedzi na pytanie, jak długo trwał każdy etap.

Jak przygotować próbę wdrożenia

Wybierz reprezentatywny fragment procesu, a nie najłatwiejszy ekran demonstracyjny. Dla zleceń serwisowych może to być przyjęcie zgłoszenia, przypisanie technika i zmiana terminu. Włącz przypadek, w którym dwie osoby próbują zmienić ten sam rekord. Ustal, czy późniejsza operacja ma zostać odrzucona, czy wymaga świadomego zatwierdzenia konfliktu.

Zapisz oczekiwany rezultat jeszcze przed testem. Bez tego szybka odpowiedź aplikacji może zostać uznana za sukces mimo utraconej zmiany. Oceniaj czas wykonania i poprawność razem, na obciążeniu zbliżonym do godzin największego ruchu. Średnia z całego dnia potrafi ukryć problem występujący przy porannym przyjmowaniu zgłoszeń.

Osobno sprawdź ścieżkę użytkownika aplikacji i osoby czytającej raport. Test kontem administratora nie pokazuje, czy zwykły pracownik ma właściwy dostęp. Lista kontroli powinna obejmować również próbę odczytu danych, których danej roli nie wolno zobaczyć.

Przykład: ponowienie nie może podwoić zleceń

Rozważmy syntetyczny przykład, który nie opisuje wdrożenia klienta. Aplikacja wysyła 100 różnych zleceń. Przy 5 żądaniach połączenie zostaje przerwane już po zapisie, ale przed odebraniem potwierdzenia. Użytkownik ponawia te 5 operacji.

Jeżeli każde żądanie bezwarunkowo tworzy nowy rekord, baza może zawierać 105 zleceń. System działa i odpowiada, lecz wynik biznesowy jest błędny. Identyfikator operacji oraz właściwie zaprojektowana obsługa powtórzeń mają pozwolić rozpoznać te same żądania. Oczekiwanym wynikiem jest 100 zleceń, a nie 105.

To kryterium projektowe aplikacji, nie obietnica, że platforma samodzielnie rozpozna duplikat biznesowy. Zespół musi ustalić, co oznacza „to samo zlecenie”, oraz sprawdzić tę zasadę przy równoległych próbach zapisu. Podobnie trzeba przetestować anulowanie i korektę, zamiast ograniczać odbiór do tworzenia rekordów.

Utrzymanie też podlega odbiorowi

Obszar	Pytanie do zespołu	Materiał do decyzji
Odtwarzanie	Jak przywrócimy działanie po błędnej zmianie danych?	Wynik próby odtworzenia i zmierzony czas
Integracja	Które tabele i typy danych obejmuje kopia analityczna?	Sprawdzona lista dla rzeczywistego schematu
Koszt	Co zużywa zasoby podczas szczytu pracy?	Pomiar obciążenia oraz założenia kosztowe
Odpowiedzialność	Kto reaguje na błąd zapisu lub opóźnienie raportu?	Właściciel, zastępstwo i procedura zgłoszenia

Wspólna platforma może ułatwiać integrację, lecz nie stanowi uzasadnienia migracji działającej aplikacji. Porównaj koszt pozostawienia obecnej bazy i udostępnienia jej danych analityce z kosztem przeniesienia całego systemu. Uwzględnij zmiany połączeń, testy zgodności, przełączenie użytkowników i możliwość powrotu.

Jeśli potrzeba dotyczy głównie raportowania i łączenia danych z wielu systemów, przeczytaj także, kiedy wybrać Warehouse w Fabric. To pomaga oddzielić bazę aplikacji od hurtowni przeznaczonej do analizy.

Od czego zacząć w firmie

Na najbliższym spotkaniu wybierz jedną operację biznesową i zapisz jej warunki poprawności: co zostaje zapisane, kto może wykonać zmianę, jak rozpoznać powtórzenie oraz kiedy wynik ma być widoczny w raporcie. Następnie poproś zespół o demonstrację błędu i odzyskania poprawnego działania, nie tylko udanej ścieżki.

Powiązanie technologii z odpowiedzialnością i mierzalnym procesem opisuję szerzej w systemie wdrażania AI w firmie. Decyzję o bazie podejmij dopiero wtedy, gdy wynik próby daje się sprawdzić i ktoś odpowiada za jego utrzymanie po uruchomieniu.