NoSQL

Bazy NoSQL różnią się modelem danych, sposobem skalowania i kompromisami między spójnością, dostępnością oraz opóźnieniami. Warto sprawdzić typ operacji, strukturę danych, wymagania dotyczące replikacji, partycjonowania i obsługi zapytań, a następnie dopasować model dokumentowy, grafowy, klucz-wartość albo rodzin kolumn do konkretnego przypadku użycia. Przykładowo MongoDB sprawdza się przy elastycznych dokumentach, Cassandra przy dużym wolumenie zapisów rozproszonych, Redis przy bardzo szybkich operacjach w pamięci, a Neo4j przy analizie relacji i ścieżek. Ten temat przerabiamy praktycznie na szkoleniu: Wstęp do NoSQL (NOSQL).

Modelowanie danych w MongoDB polega na takim doborze struktury dokumentów, aby odpowiadała rzeczywistym wzorcom odczytu i zapisu, a nie schematowi znanemu z baz relacyjnych. Trzeba przeanalizować, kiedy stosować zagnieżdżanie, kiedy referencje, jak budować indeksy oraz jak ograniczać koszt agregacji, sortowania i operacji na tablicach. Przykładem dobrej decyzji jest zapisanie danych podrzędnych w jednym dokumencie, gdy aplikacja najczęściej odczytuje je razem i nie wymaga częstych niezależnych aktualizacji. Jeśli chcesz przećwiczyć to krok po kroku, zobacz: Bazy danych NoSQL - MongoDB (MONGODB).

Cassandra to rozproszona baza NoSQL oparta na modelu rodziny kolumn, zaprojektowana pod wysoką dostępność, skalowalność poziomą i obsługę dużych strumieni zapisów. Przed wdrożeniem należy ocenić klucz partycji, poziomy spójności, strategię replikacji, rozkład danych między węzłami oraz to, czy model zapytań da się zaprojektować pod konkretne ścieżki odczytu. Typowym zastosowaniem są systemy telemetryczne, logowe lub transakcyjne o dużej liczbie zapisów, rozłożone między wiele serwerowni. Wersję warsztatową (z konfiguracją i przykładami) znajdziesz w programie szkolenia: Bazy danych NoSQL - Cassandra (CASSANDRA).

Najczęstsze błędy obejmują przenoszenie schematów SQL bez zmiany sposobu modelowania, zły dobór kluczy partycjonowania, nieprawidłowe ustawienia replikacji oraz pomijanie ograniczeń modelu spójności. Należy zweryfikować wzorce dostępu do danych, politykę indeksowania, mechanizmy failover, sposób obsługi transakcji i wpływ shardingu lub partycjonowania na wydajność operacji. Przykładem błędu jest wybór klucza shardowania o niskiej kardynalności, który prowadzi do nierównego obciążenia klastra i wąskich gardeł. To jedno z zagadnień omawianych podczas szkolenia: Wstęp do NoSQL (NOSQL).

Optymalizacja zapytań w NoSQL polega na powiązaniu struktury danych z rzeczywistym sposobem odczytu, a indeksów z konkretnymi filtrami, sortowaniem i agregacjami. Trzeba sprawdzić plany wykonania, selektywność pól, koszt skanowania, wpływ indeksów wielopolowych lub pomocniczych oraz to, czy zapytania nie wymuszają nadmiarowego przetwarzania po stronie serwera. Przykładowo w MongoDB analiza explain plan może pokazać, że zapytanie korzysta z pełnego skanu kolekcji zamiast z indeksu złożonego dopasowanego do filtra i sortowania. Dokładnie ten zestaw narzędzi i workflow ćwiczymy podczas szkolenia: Bazy danych NoSQL - MongoDB (MONGODB).

Elasticsearch służy do indeksowania i wyszukiwania danych, a Kibana do ich profilowania, wizualizacji i budowy pulpitów na podstawie wzorców indeksów. W praktyce warto sprawdzić strukturę dokumentów, podział na shardy i repliki, role węzłów, sposób zasilania indeksów oraz to, jakie metryki i agregacje mają trafić na dashboardy. Przykładem może być analiza logów aplikacyjnych, w której Elasticsearch agreguje dane po czasie i typie zdarzenia, a Kibana prezentuje trendy, błędy i obciążenie usług. Ten temat przerabiamy praktycznie na szkoleniu: Wstęp do NoSQL (NOSQL).