Typy baz danych w praktyce: kiedy SQL, kiedy NoSQL, kiedy analityka Kusto

Dlaczego pytanie o najlepszą bazę danych jest błędne

Przez trzydzieści lat pracy jz danymi słyszałem to pytanie setki razy: która baza danych jest lepsza? SQL Server czy MongoDB? PostgreSQL czy Cassandra? Oracle czy Cosmos DB? Za każdym razem muszę odpowiadać tym samym: to pytanie jest źle postawione.

Wyobraźmy sobie, że pytamy mechanika, który klucz jest najlepszy. Odpowiedź zależy od tego, co chcemy odkręcić. Klucz nasadowy świetnie sprawdzi się przy śrubach sześciokątnych, ale do rur potrzebujesz klucza nastawnego. Podobnie jest z bazami danych. Każda z nich powstała, aby rozwiązać konkretny problem, a nie po to, żeby zastąpić wszystkie inne.

W praktyce produkcyjnej rzadko spotykam systemy oparte na jednej technologii bazodanowej. Typowa architektura średniej wielkości firmy obejmuje SQL Server do obsługi transakcji biznesowych, Redis jako cache, Elasticsearch do wyszukiwania pełnotekstowego, a ostatnio coraz częściej Azure Data Explorer do analizy telemetrii. I to nie jest nadmiarowa złożoność; to świadome dopasowanie narzędzi do problemów.

Bazy relacyjne SQL: fundament systemów transakcyjnych

Zacznijmy od tego, co znam najlepiej. SQL Server, PostgreSQL, Oracle, MySQL; bazy relacyjne pozostają fundamentem systemów, w których liczy się jedno: dane muszą być poprawne. Zawsze. Bez wyjątków.

Wyobraźmy sobie system bankowy, który przetwarza przelew między kontami. Operacja jest prosta: zmniejsz saldo na koncie A, zwiększ saldo na koncie B. Ale co, jeśli po pierwszej operacji nastąpi awaria? Bez właściwych mechanizmów pieniądze znikają. Właśnie dlatego istnieje model ACID.

ACID w praktyce, nie w teorii

ACID to nie akademicki skrót do zapamiętania na egzamin. To zestaw gwarancji, które codziennie chronią integralność danych w produkcji:

• Atomicity (niepodzielność): transakcja wykonuje się w całości albo wcale. W SQL Server implementowana przez mechanizm logów transakcyjnych, gdzie każda zmiana jest najpierw zapisywana do logu, a dopiero potem do plików danych.
• Consistency (spójność): baza przechodzi z jednego poprawnego stanu do drugiego. Ograniczenia CHECK, klucze obce, triggery; wszystko to pilnuje, żeby dane zawsze spełniały reguły biznesowe.
• Isolation (izolacja): współbieżne transakcje nie widzą swoich częściowych zmian. SQL Server oferuje różne poziomy izolacji, od READ UNCOMMITTED po SERIALIZABLE, a od wersji 2014 także SNAPSHOT ISOLATION opartą na wersjonowaniu wierszy.
• Durability (trwałość): zatwierdzone dane przetrwają awarię. Write-ahead logging gwarantuje, że nawet przy nagłym zaniku zasilania można odtworzyć stan bazy.

Kiedy SQL jest jedynym sensownym wyborem

Z mojego doświadczenia wynika, że bazy relacyjne są niezastąpione w następujących scenariuszach:

• Systemy finansowe i rozliczeniowe: każda złotówka musi się zgadzać. Nie ma miejsca na eventual consistency, gdy księgowość zamyka miesiąc.
• Systemy zamówień i inventory: stan magazynowy musi być dokładny. Overselling (sprzedaż towaru, którego nie ma) to problem biznesowy, który rozwiązujemy na poziomie bazy danych poprzez odpowiednie blokady i izolację transakcji.
• Systemy z wieloma relacjami między danymi: gdy model danych naturalnie tworzy sieć powiązań (klient > zamówienie > pozycje > produkty > kategorie > dostawcy), SQL z JOIN-ami jest znacznie bardziej elegancki niż ręczne składanie danych w aplikacji.
• Raportowanie operacyjne z gwarancją spójności: gdy zarząd pyta o obroty z ostatniego miesiąca, odpowiedź musi być precyzyjna i powtarzalna.

Po blisko 30  latach w branży mogę powiedzieć jedno: nie spotkałem jeszcze systemu finansowego produkcyjnej klasy, który działałby na bazie NoSQL jako primary storage dla transakcji pieniężnych. Eventual consistency i pieniądze to połączenie, które kończy się pozwami.

Koszty modelu relacyjnego

Oczywiście SQL nie jest darmowy w sensie architektonicznym. Za spójność płacimy:

• Sztywnością schematu: każda zmiana struktury wymaga ALTER TABLE, często z przestojem lub długim czasem wykonania na dużych tabelach.
• Ograniczeniami skalowania horyzontalnego: sharding w bazach relacyjnych jest trudny. Można to robić (np. przez partycjonowanie), ale to zawsze kompromis.
• Złożonością przy hierarchicznych danych: przechowywanie dokumentów JSON w SQL Server jest możliwe od wersji 2016, ale nie jest to naturalne środowisko dla takich struktur.

NoSQL: elastyczność kosztem odpowiedzialności

NoSQL to nie jest jedna technologia. To cała rodzina podejść, które łączy jedno: świadoma rezygnacja z części gwarancji SQL na rzecz innych korzyści. Zanim wybierzesz NoSQL, musisz zrozumieć, z czego rezygnujesz i dlaczego.

Bazy dokumentowe: MongoDB, Cosmos DB, Couchbase

Bazy dokumentowe przechowują dane jako dokumenty JSON (lub BSON). Każdy dokument może mieć inną strukturę, co daje ogromną elastyczność.

Praktyczny przykład: system zarządzania produktami w e-commerce. Telewizor ma zupełnie inne atrybuty niż sukienka czy książka. W SQL musielibyśmy tworzyć tabelę z setkami kolumn (większość NULL dla większości produktów) albo złożony model EAV (Entity-Attribute-Value), który jest koszmarem wydajnościowym. W MongoDB każdy produkt to dokument z własnymi atrybutami.

Ale uwaga: gdy klient składa zamówienie zawierające produkty, powiązanie między zamówieniem a produktami wymaga przemyślenia. Czy osadzamy kopię produktu w zamówieniu? Co gdy cena się zmieni? W SQL mamy klucze obce i jasne reguły. W dokumentowych bazach ta odpowiedzialność spoczywa na programiście.

Bazy key-value: Redis, DynamoDB, Memcached

Key-value to najprostsza możliwa abstrakcja: klucz i wartość. Nic więcej. Ta prostota przekłada się na niesamowitą wydajność; Redis potrafi obsłużyć setki tysięcy operacji na sekundę na pojedynczym węźle.

W praktyce używam Redis w niemal każdym projekcie, ale nie jako primary storage. To warstwa cache przed SQL Serverem, sesje użytkowników, liczniki, kolejki. Dane, które mogę odtworzyć z primary storage, jeśli Redis je straci.

DynamoDB z kolei świetnie sprawdza się jako primary storage dla danych, gdzie znamy klucz dostępu. Profil użytkownika po user_id, konfiguracja po config_key. Ale gdy potrzebujesz wyszukiwania po różnych kryteriach, DynamoDB wymaga secondary indexes, które mają swoje ograniczenia i koszty.

Bazy szerokokolumnowe: Cassandra, HBase, ScyllaDB

Cassandra została zaprojektowana do jednego celu: obsługi ogromnych wolumenów zapisów rozproszonych globalnie. Facebook, Netflix, Apple; wszyscy używają Cassandry do przypadków, gdzie write throughput jest kluczowy.

Typowy przypadek użycia: system śledzenia zdarzeń IoT. Miliony urządzeń wysyłają odczyty co sekundę. SQL Server by się zakrztusił. Cassandra przyjmie wszystko, rozłoży po węzłach, zreplikuje między datacenterami.

Ale: odpytywanie Cassandry wymaga znajomości partition key. Nie zapytasz dowolnie jak w SQL. Modelowanie danych w Cassandrze zaczyna się od pytań, które będziesz zadawać, a nie od encji które masz. To fundamentalna zmiana myślenia.

CAP theorem w praktyce

Twierdzenie CAP mówi, że rozproszony system może gwarantować tylko dwie z trzech właściwości: Consistency, Availability, Partition tolerance. W praktyce partycje sieciowe się zdarzają, więc wybierasz między C a A.

SQL Server w trybie synchronicznej replikacji Always On wybiera C: gdy replika jest niedostępna, zapisy czekają. Cassandra domyślnie wybiera A: system działa, nawet gdy część węzłów jest niedostępna, ale możesz odczytać nieaktualne dane.

Żaden wybór nie jest lepszy. Zależy od tego, co jest gorsze dla Twojego biznesu: chwilowa niedostępność czy nieaktualne dane.

Systemy analityczne: Kusto i Azure Data Explorer

Trzecia kategoria baz danych odpowiada na zupełnie inne pytania. Nie chodzi o pojedyncze transakcje ani o dostęp do konkretnych rekordów. Chodzi o analizę wzorców w milionach lub miliardach zdarzeń.

Czym jest Kusto (Azure Data Explorer)

Azure Data Explorer (ADX), z językiem zapytań Kusto Query Language (KQL), to silnik analityczny zoptymalizowany pod kątem danych szeregów czasowych, logów i telemetrii. Microsoft używa go wewnętrznie do analizy danych z Azure, Office 365, Windows.

Główne cechy ADX:

• Kolumnowe przechowywanie danych: dane są kompresowane kolumnowo, co oznacza, że zapytanie analizujące jedną kolumnę z tabeli miliardrektordowej nie musi czytać pozostałych kolumn.
• Append-only: dane są dodawane, nie modyfikowane. To nie jest baza do CRUD; to baza do analizy historii.
• Natywna obsługa szeregów czasowych: funkcje takie jak make-series, series_fit_line, anomaly detection są wbudowane w język.
• Streaming ingestion: dane mogą napływać w czasie rzeczywistym i być dostępne do analizy w sekundach.

KQL vs SQL: różne podejście do tych samych danych

KQL wygląda inaczej niż SQL, bo rozwiązuje inne problemy. Prosty przykład; znalezienie wzorców w logach:

W SQL napisałbyś złożone zapytanie z GROUP BY, HAVING, może CTE. W KQL:

requests | where timestamp > ago(1h) | summarize count() by bin(timestamp, 5m), resultCode | render timechart

Ten pipe-based syntax jest intuicyjny dla analityków, którzy myślą sekwencyjnie: weź dane, przefiltruj, zagreguj, zwizualizuj.

Praktyczne zastosowania ADX

Z mojego doświadczenia ADX sprawdza się rewelacyjnie w:

• Analiza logów aplikacyjnych: gdy coś się wysypało o 3:00 w nocy, chcesz szybko przeszukać miliony linii logów. ADX zrobi to w sekundach.
• Telemetria IoT: tysiące czujników generuje odczyty co sekundę. ADX pozwala wykrywać anomalie, trendy, korelacje.
• Security analytics: wykrywanie wzorców ataków wymaga analizy milionów zdarzeń sieciowych. Microsoft Sentinel pod spodem używa ADX.
• Metryki biznesowe w czasie rzeczywistym: dashboardy pokazujące co dzieje się teraz, nie co działo się wczoraj.

Największa zmiana myślenia przy przejściu na ADX: przestajesz pytać o pojedyncze rekordy, a zaczynasz pytać o wzorce. Nie interesuje Cię konkretny request, który się wysypał. Interesuje Cię, czy takich requestów jest więcej niż zwykle i co je łączy.

Architektura poliglotyczna: jak to wszystko połączyć

W praktyce produkcyjnej projektuję systemy, które wykorzystują wszystkie trzy podejścia jednocześnie. Typowa architektura nowoczesnej aplikacji może wyglądać tak:

• SQL Server: primary storage dla danych transakcyjnych (użytkownicy, zamówienia, płatności)
• Redis: cache dla często odczytywanych danych, sesje użytkowników
• Cosmos DB: dane produktowe z elastycznym schematem, replikowane globalnie dla niskich latencji
• Event Hub + ADX: wszystkie zdarzenia systemowe trafiają do Event Hub, a stamtąd do ADX do analizy

Przepływ danych między systemami

Kluczowe jest zaprojektowanie przepływu danych. Przykład:

Użytkownik składa zamówienie. Transakcja zapisuje się do SQL Server (ACID, musi być poprawnie). Jednocześnie event OrderPlaced trafia do Event Hub. Z Event Hub event jest konsumowany przez różne systemy: aktualizację cache w Redis, indeksowanie w Elasticsearch do wyszukiwania, zapis do ADX do analityki.

SQL Server jest source of truth dla stanu zamówienia. Ale historia zdarzeń w ADX pozwala odpowiedzieć na pytania typu: ile zamówień było anulowanych w ostatnim tygodniu według regionu i kategorii produktu?

Zarządzanie spójnością między systemami

Największym wyzwaniem architektury poliglotycznej jest spójność. Gdy dane żyją w wielu miejscach, mogą się rozjechać.

Strategie, które stosuję:

• Single source of truth: zawsze jest jeden system który jest autorytatywny. Inne są derived, można je odbudować.
• Event sourcing: zamiast synchronizować stan, propaguję zdarzenia. Każdy system sam decyduje, jak je interpretować.
• Idempotentne handlery: operacje można bezpiecznie powtórzyć. Gdy event dotrze dwukrotnie, wynik jest ten sam.
• Monitoring rozbieżności: regularne porównywanie stanów między systemami. Gdy cache rozjeżdża się z primary storage, alert.

Praktyczne wskazówki: jak podejmować decyzje

Na zakończenie chcę dać konkretne kryteria, które stosuję przy wyborze technologii dla konkretnego przypadku:

Wybierz SQL gdy:

• Poprawność danych jest ważniejsza niż wydajność
• Masz złożone relacje między encjami
• Potrzebujesz transakcji obejmujących wiele tabel
• Raportowanie wymaga gwarancji spójności
• Zespół zna SQL i model relacyjny

Rozważ NoSQL gdy:

• Schemat danych zmienia się często lub jest niejednorodny
• Potrzebujesz skalowania horyzontalnego ponad możliwości single-node
• Wzorzec dostępu jest prosty (lookup by key)
• Możesz zaakceptować eventual consistency
• Write throughput jest krytyczny

Sięgnij po ADX/Kusto gdy:

• Analizujesz logi, metryki, zdarzenia
• Dane mają charakter szeregów czasowych
• Wolumen danych jest ogromny, ale zapytania są analityczne, nie transakcyjne
• Potrzebujesz wykrywania anomalii, trendów, korelacji
• Dane są append-only; nie modyfikujesz historii

Złożoność nie znika, ona się przemieszcza

Na koniec chcę podkreślić najważniejszą lekcję z lat praktyki: złożoność nigdy nie znika. Można ją tylko przenieść w inne miejsce.

Gdy upraszczasz schemat danych, przenosząc go do dokumentowej bazy, złożoność zarządzania spójnością przesuwa się do aplikacji. Gdy skalisujesz poziomo z Cassandrą, pojawia się złożoność modelowania danych pod query patterns. Gdy przyspieszasz analizę z ADX, musisz zadbać o pipeline ingestion i jakość danych źródłowych.

Nie ma darmowych lunchów. Ale można świadomie wybrać, gdzie chcesz płacić. I to jest właśnie istota architektury danych: nie wybór najlepszej technologii, ale świadoma alokacja złożoności tam, gdzie zespół potrafi ją najlepiej obsłużyć.