Tabele i kolumny, czy może grafy, dokumenty i mapy, czyli jaki mamy wybór planując bazy danych?

W dzisiejszych czasach zamknięcie się w jednym modelu może okazać się niewystarczające. Już na etapie planowania projektu, warto rozważyć, jak przeprowadzona zostanie implementacja baz danych, oraz jaki silnik najlepiej nada się do naszych rozwiązań.

Spośród wielu istniejących struktur danych, najczęściej wybieranymi są relacyjne (SQL), lub nierelacyjne (NoSQL). W tym wpisie postaram się pokazać kluczowe różnice pomiędzy tymi strukturami, oraz o czym należy pamiętać podejmując decyzję o implementacji.

Relacyjne bazy danych – SQL

Jedną z najczęściej używanych struktur danych jest relacyjna baza danych nazywana SQL – Structured Query Language. Idea, za którą stoi tworzenie relacyjności, powstała z potrzeby rozwiązania pewnego problemu. We wczesnych latach rozwoju baz danych aplikacje zapisywały dane w swojej własnej strukturze. W związku z tym chcąc tworzyć aplikacje na podstawie tych danych należało bardzo dobrze znać tę strukturę, co było kosztowne i czasochłonne. Ciężko było znaleźć specjalistów, którzy mieliby wystarczającą wiedzę domenową w zakresie danego biznesu. Dodatkowo, nie ujednolicono jeszcze wtedy podejścia do wyszukiwania brakujących informacji takich jak np. nieznany adres, numer telefonu.

Problem ten próbowano rozwiązać poprzez podstawienie kilku specjalnych wartości mających wypełnić luki w rekordach. Jednak dopiero Edgar Frank Codd wpadł na genialny w swej prostocie pomysł. W 1979 roku zaproponował on pojedynczą wartość NULL. Ta mała rewolucja w całości zmieniła podejście, rozszerzając logikę dwuwartościową typową dla operatorów boolean (Tak, Nie) o porównania do logiki trójwarstwowej. Mówiąc w skrócie, od tej pory na każde pytanie dało się odpowiedzieć: Tak, Nie, Nieznane/Null. Rozwiązanie natychmiast znalazło zastosowanie. Chwilę później firma znana jako Relational Software (obecnie Oracle) wypuściła na rynek pierwszy komercyjny relacyjny system zarządzania bazą danych (RDBMS, czyli Relational Database Management Systems). Od tej pory model relacyjny na dobre zagościł jako dominujący system do przechowywania danych.

Kluczem do zrozumienia strukturyzowania danych będzie zapoznanie się z podstawowymi pojęciami – czyli czym jest baza danych. Jest to zbiór tabel oraz narzędzi, które stosuje się do przekształcania i wyszukiwania danych w danym przedsiębiorstwie. Podstawowe konstrukcje, jakie powinien znać tester to:

• Schemat – kontener zawierający wszystkie obiekty wymienione poniżej. Charakteryzuje go możliwość nadawania uprawnień na wybranym obiekcie. Każdy utworzony przez użytkownika bazy danych schemat będzie przypisany do niego domyślnie
• Tabela – zbiór ujednoliconych rekordów opisujących dany obiekt. Przykładem może być tabela Pracownicy, która będzie zawierała wszystkie rekordy związane z pracownikami danego przedsiębiorstwa
• Rekord – pojedynczy wiersz w tabeli. Dla przykładu, będzie to jeden z pracowników tabeli Pracownicy
• Pole – jedno wybrane pole z wiersza, które przechowuje jedną daną
• Klucze główne i obce.

Dane strukturyzuje się poprzez zastosowanie relacji, czyli połączeń między tabelami. Żeby dobrze to zobrazować, rozważmy przykład następującej relacji między tabelami. Istnieją tabele Placówka oraz Pracownicy. Tabela Pracownicy, oprócz kolumn przeznaczonych na dane osobowe pracowników przedsiębiorstwa posiada kolumnę id_pracownika. Tabela Placówka posiada dane związane z wybraną placówką przedsiębiorstwa oraz dodatkowe powiązanie poprzez kolumnę id_pracownika. W tej relacji Pracownicy.id_pracownika będzie kluczem głównym, a Placówka.id_pracownika kluczem obcym tabeli Pracownicy powielając się w innej tabeli (Placówka). W ten sposób każda z tych dwóch tabel ma identyczne, unikatowe wartości po których można powiązać pracowników z placówką, w której pracują.

Tworząc wyżej wspomniane tabele baz danych i powiązania między nimi, tworzymy relacyjną bazę danych. Tę integralność danych opisuje się skrótem ACID:

• Atomicity – Niepodzielność transakcji. Jak sama nazwa wskazuje, dana transakcja ma się wykonać w całości, lub w ogóle. Przykładem zastosowania będzie np. transakcja bankowa, w której nie może dojść do sytuacji, w której pieniądze znikną w czasie jej przetwarzania
• Consistency – Spójność transakcji. Po wykonaniu transakcji system ma pozostać spójny, tj. spełniać pewne zdefiniowane reguły
• Isolation – Izolacja transakcji. Idealnym przykładem izolacji transakcji będzie próba pobrania środków z jednego konta przez dwie osoby jednocześnie. Systemy zadbają, aby (zależnie od konfiguracji) transakcje nie widziały wprowadzanych przez siebie zmian. Najprawdopodobniej wykonają się jedna po drugiej, a system zachowa się zgodnie z jego obecnym stanem (np. pierwsza transakcja się wykona, druga zostanie odrzucona ponieważ obecny stan systemu wskazywał na brak środków na koncie)
• Durability – Trwałość. System potrafi uruchomić się i zaprezentować nienaruszone i aktualne dane.

Zgodność z ACID chroni integralność danych, definiując dokładnie, czym jest transakcja i jak współdziała z bazą danych. Zapobiega to utracie synchronizacji tabel w bazie, co jest bardzo ważne w przypadku transakcji finansowych. Gwarantuje również ważność transakcji nawet w obliczu błędów, awarii technologii i katastrofalnych wydarzeń.

Jeśli Twoje dane są bardzo ustrukturyzowane i zgodność z ACID jest koniecznością, SQL to świetny wybór. Z drugiej strony, jeśli Twoje wymagania dotyczące danych nie są jasne lub jeśli Twoje dane są nieustrukturyzowane, NoSQL może być najlepszym rozwiązaniem. W nieustannie rozwijającym się świecie, gdzie wymagane jest gromadzenie ogromnej ilości nieprzetworzonych danych potrzebne było rozwiązanie, które będzie w stanie wyjść poza ograniczenia obecnych modeli. Wobec tego klasyczne silniki coraz częściej zastępowane są poprzez architektury rozproszone, które zasilanie są przez tzw. nierelacyjne bazy danych.

Nierelacyjne bazy danych – NoSQL

Jeśli SQL znaczy Structured Query Language, to czy NoSQL będzie jego zaprzeczeniem?

Po przeczytaniu tego akronimu wydawać by się mogło, że w tym podejściu następuje całkowite odejście od tradycyjnego modelu. Sam termin został po raz pierwszy użyty przez Carlo Strozziego dla jego open source’owej wersji relacyjnej bazy danych Strozzi NoSQL. Sam skrótowiec NoSQL jest efektem współpracy społeczności na kanale IRC #cassandra, która to w 2009 roku została poproszona o pomysły na możliwie najkrótszą nazwę nowego podejścia do baz danych. Tymczasem, bardziej niż „no SQL”, akronim oznacza „not only SQL” i w swoim założeniu ma nie usuwać relacyjnego modelu baz danych, a uzupełniać go. Jednym z argumentów popierających tę tezę jest chociażby fakt, że NoSQL dalej umożliwia obsługę języka SQL (zależnie od wyboru rozwiązania). Obserwując trend powolnego odchodzenia od modelu relacyjnego, Strozzi sugeruje dodawać do znaczenia dodatkowy skrót NoREL. Łącząc te dwa skróty możemy mieć więc pełny obraz, w jakim kierunku zmierza ten model baz danych. Z połączenia tych dwóch terminów wychodzi nam: not only REL, not only SQL.

Sama potrzeba utworzenia takich baz danych pojawiła się już pod koniec lat 60. XX wieku, aby poradzić sobie z problemem horyzontalnej skalowalności do klastrów maszyn. Innymi słowy – potrzebowaliśmy rozwiązania gotowego obsłużyć struktury danych, do których stale dodaje się nowe serwery (np. chmurowe). Innymi problemami, które takie podejście miało zaadresować były wciąż zwiększające się ilości wolumenów danych, które w pewnym momencie stanowiły poważne wyzwanie dla mniej wydajnych serwerów.

Na początku XXI wieku nastąpił prawdziwy wybuch popularności tego rozwiązania, kiedy to rosnący giganci jak Google Inc. zbudowali swoją wysoce skalowalną przeglądarkę Google i szereg aplikacji powiązanych jak Gmail, Google Maps, Google Earth. W rezultacie takie rozproszone systemy plików mogły w pełni opierać się na strukturze NoSQL. Wspomnianą strukturę można opisać jako cztery oddzielne typy baz danych:

• Rodziny kolumn – odpowiedniki tabel w SQL zawierające klucze-wartości jako jej rzędy
• Bazy Dokumentów – w swoim założeniu kodujące dane do popularnych formatów takich jak: XML, JSON, YAML, lub BSON (dla wartości binarnych)
• Grafy – wykresy ze skończoną liczbą relacji między nimi
• Bazy klucz-wartość (mapy/słowniki) – metoda modelowania danych w formie map lub słowników. Przechowują np. obrazy, dane sesji, zawartość koszyka zakupów.

Dla porównania modelu nierelacyjnego z relacyjnym,w tym drugim modelu mamy tylko dwa typy baz danych: OLTP (On-Line Transactional Processing) oraz OLAP (On-Line Analytical Processing).

Co jednak cechuje NoSQL to fakt, że przechowywane dane nie wymagają predefiniowanego schematu, jak w przypadku bazy danych SQL. Podejście to zapewnia znacznie większą szybkość niektórych operacji i pozwala na elastyczność w planowaniu zarządzania bazą danych. Nie budujemy czystych relacji, a gromadzimy, analizujemy i badamy korelacje między dużymi ilościami nieustrukturyzowanych danych. Odpowiedzialne są za to dynamiczne schematy, które zgodnie z założeniami są skalowalne horyzontalnie. Wobec tego wszelkie dane jakie trafiają do systemu mogą pozostać nieustrukturyzowane i pozostawione do dalszej obróbki. Dobrym przykładem tego podejścia są współczesne media społecznościowe, w których profiluje się dla nas reklamy, artykuły, wiadomości, komentarze itd. To właśnie takie podejście pozwala, poza samą identyfikacją użytkownika, sprofilować jego upodobania, prawdopodobieństwo nabycia danego produktu ale również przenieść go dokładnie w to samo miejsce, w którym ostatnio skończył pracę.

Interakcja z bazą NoSQL różni się od tradycyjnego podejścia. Podczas przeglądania relacyjnej bazy danych użytkownik projektuje precyzyjne zapytania, które później są w stanie odpytać bazę i wyświetlić oczekiwane wyniki. W przypadku nierelacyjnej bazy danych są to najczęściej żądania wysłane za pomocą API, a dane przekazywane są w gotowych obiektach takich jak JSON, XML lub innych im podobnych. Mówiąc w skrócie – dane przekazywane są wraz z ich kompletnym schematem.

NoSQL nie spełnia założeń ACID, przez co opracowany musiał zostać kompromis, który nazwano modelem BASE:

• Basically Available – oznacza to, że chociaż baza danych gwarantuje dostępność danych, baza danych może nie uzyskać żądanych danych lub dane mogą być w zmiennym lub niespójnym stanie
• Soft State – stan bazy może zmienić się w czasie
• Eventually Consistent – baza danych ostatecznie stanie się spójna, a w przyszłości dane będą rozpropagowane wszędzie.

Mając więc rozumienie na temat tych dwóch podejść, rozważmy główne różnice występujące między nimi.

Główne różnice między SQL a NoSQL

Wyszukiwanie danych

• SQL to popularny język programowania, który istnieje od ponad 45 lat, więc jest już bardzo rozwinięty i dobrze znany. Skutecznie wykonuje zapytania oraz szybko pobiera i edytuje dane. Jest bardzo lekki i deklaratywny, dzięki czemu jest łatwy do nauczenia. W związku z tym zapytania nie wymagają mocno technicznego doświadczenia
• NoSQL zapewnia ogromną elastyczność w zakresie typów danych, które można przechowywać, ale ze względu na potencjalnie duże różnice w strukturach danych zapytania nie są tak wydajne, jak w przypadku bazy danych SQL. Podczas tworzenia technologii baz danych NoSQL programiści koncentrowali się na skalowalności i elastyczności, a nie wydajności zapytań. Aby więc uruchamiać zapytania NoSQL, trzeba wykonywać dodatkowe przetwarzanie danych. W zależności od używanej bazy danych NoSQL może być konieczne zaimplementowanie pewnego poziomu MapReduce.

Skalowalność

• SQL skaluje się w pionie, co oznacza, że wymagane będzie zwiększenie pojemność pojedynczego serwera (wymieniając procesor, pamięć RAM lub dysk SSD), aby skalować bazę danych. Zostały zaprojektowane do działania na jednym serwerze w celu zachowania integralności danych, więc nie są łatwe do skalowania
• NoSQL skaluje się w poziomie, co oznacza, że możesz dodać więcej serwerów, aby zasilać rosnącą bazę danych. Jest to ogromna przewaga, jaką NoSQL ma nad SQL. Zdolność baz danych NoSQL do skalowania poziomego wiąże się z brakiem struktury danych. Ponieważ NoSQL wymaga znacznie mniej struktury niż SQL, każdy przechowywany obiekt jest prawie samowystarczalny i niezależny. W ten sposób obiekty można łatwo przechowywać na wielu serwerach bez konieczności łączenia ich. Nie dotyczy to języka SQL, w którym każdy wiersz tabeli i kolumna muszą być powiązane. Analogią do skalowania w pionie i poziomie może być tort weselny. Dzięki SQL możesz nakarmić więcej osób, dodając więcej warstw do tortu weselnego. W NoSQL’u byłby to „słodki stół” z babeczkami weselnymi.

Schematy

• Schemat odnosi się do planu bazy danych, czyli sposobu organizacji danych. Relacyjne bazy danych SQL są lepszą opcją dla aplikacji, które wymagają transakcji wielorzędowych, takich jak system księgowy lub dla starszych systemów, które zostały zbudowane dla struktury relacyjnej
• Bazy danych NoSQL są znacznie lepiej dostosowane do dużych zbiorów danych, ponieważ elastyczność jest ważnym wymaganiem, które spełnia ich dynamiczny schemat.

Kiedy używać SQL?

• SQL jest najłatwiejszym językiem używanym do komunikacji z RDBMS
• W podejściu analitycznym umożliwia analizowanie trendów behawioralnych i dostosowanie wyników do własnych potrzeb
• Tworzenie niestandardowych pulpitów nawigacyjnych, tzw. dashboardów
• Pozwala szybko przechowywać i pobierać dane z bazy danych
• Wybierany, kiedy chcemy używać funkcji JOIN i wykonywać złożone zapytania.

Kiedy używać NoSQL?

• Gdy obsługa ACID nie jest potrzebna
• kiedy tradycyjny model RDBMS nie wystarczy
• Przy użyciu danych wymagających elastycznego schematu
• Kiedy ograniczenia i walidacja nie musi być implementowana w bazie danych
• Gdy wymagane jest pobranie danych z rozproszonych źródeł
• Do przechowywania danych tymczasowych, takich jak koszyki, lista życzeń i dane sesji.

Podczas poszukiwania najlepszego rozwiązania należy mieć na uwadze wady i zalety obydwu tych rozwiązań. Mam jednak nadzieję, że tak kompleksowe omówienie tematu pomoże wam w dobraniu właściwego dla siebie rozwiązania i rozbudzi waszą ciekawość do pogłębiania wiedzy z zakresu obydwu rozwiązań. Jedno jest pewne – obydwa rozwiązania stają się niemal nieodzowną częścią pracy testera oprogramowania. Warto więc poświęcić im trochę czasu.

Chcesz lepiej zrozumieć aplikacje i systemy, które testujesz? Dołącz do ModernTester, poznaj najpotrzebniejsze narzędzia, frameworki oraz języki programowania i ćwicz na specjalnie przygotowanych środowiskach testowych: Platforma e-learningowa ModernTester