Big Data w chmurze dla każdego?  

Termin „Big Data” oryginalnie został stworzony ponad 30 lat temu, ale jak wszystko w IT, w ciągu 3 dekad ewoluował i rozwijał się, towarzysząc ekspansji Internetu i źródeł informacji. Do niedawna był to termin opisujący systemy, na które mogły sobie pozwolić jedynie wielkie korporacje i wiodące startupy z dużym finansowaniem – wymagało to wszak wielkich nakładów kapitałowych na rozproszone klastry utrzymujące infrastrukturę Big Data. Nic dziwnego, że na wyłuskiwaniu informacji w wielkiej skali zbudowały swoją potęgę takie korporacje jak Google czy Facebook. Liderzy obserwujący, co się dzieje na rynku, nie mogli zaprzeczyć, że zbieranie i analiza dużych zbiorów danych może dać wymierne korzyści biznesowe.  

Chęć zbudowania nowej wartości w oparciu o wielkoskalową analizę danych rosła, ale brak było odpowiednich narzędzi, aby sprawdzić potencjał drzemiący w danych, jednocześnie zachowując rozsądne koszty (np. w modelu try-before-buy). Na tę potrzebę odpowiedzieli dostawcy platform chmurowych, oferując w ostatnich latach ogromną ilość usług zorientowanych na przetwarzanie danych – niektóre wprost w modelu PaaS (Platform-as-Service). W wyniku tego możemy zaobserwować eksplozję popularności systemów chmurowych Big Data. Po prostu dzisiaj już każdego stać na to, żeby spróbować wycisnąć ze swoich wielkich zbiorów danych maksimum informacji i… wartości.  

Przeczytaj także: Kim jest DevOps?

Ekosystem Azure’a a architektura Big Data 

Na przestrzeni kilkunastu lat ugruntowały się dwa podstawowe modele wysokopoziomowej architektury Big Data – Lambda i Kappa. Model Lambda może uchodzić za fundamentalny. W jego skład wchodzą: 

• Magazyny danych (ang. Stores). 
• Systemy przetwarzania wsadowego (ang. Batch Layer). 
• Systemy przetwarzania strumieniowego – w czasie zbliżonym do rzeczywistego (ang. Speed Layer, Near-Realitme – Stream Processing Systems). 
• Magazyny udostępniające dane i wyniki analiz (ang. Serving Layer). 
  
  

W modelu Lambda oba systemy przetwarzania danych są niezależne i równoległe. W międzyczasie powstała koncepcja architektury Kappa, w której model przetwarzania strumieniowego jest podstawowym elementem, a model przetwarzania wsadowego jest niejako procesem potomnym. Jest to model prostszy, ale bardziej wyspecjalizowany – odpowiedni w przypadku, gdy głównymi źródłami danych są dane napływające w czasie rzeczywistym (np. logi, tweety / wiadomości, komunikaty z urządzeń IoT).  

Usługi składowania danych (bez limitu) 

Centralnym elementem każdego systemu Big Data są magazyny danych. W nich przechowujemy ogromne ilości surowych (nieprzetworzonych) danych, które zebraliśmy ze źródeł, ale także zbiory „potomne” powstałe w procesie transformacji, korelacji i analizy danych źródłowych. Azure umożliwia przechowywanie danych w dwóch typach magazynów: Azure Storage (AS) i Azure Data Lake Storage (ADLS). W przypadku obu usług rozliczani jesteśmy za rozmiar składowanych danych i operacje na nich wykonane (podstawowe: zapis i odczyt oraz inne). Magazyn Azure Storage oprócz możliwości składowania dużych plików (Blob) ma też „wbudowane” dodatkowe usługi:  

• Files – serwer plików udostępniający pliki z wykorzystaniem protokołu SMB.  
• Tables – Baza NoSQL działająca na zasadzie Klucz / Wartość (Key / Value).  
• Queues – prosty system kolejkowy wymiany danych.  

Ponieważ każda z tych „dodatkowych” usług może łatwo zostać zastąpiona przez dedykowaną usługę Azure, to ciągle podstawową funkcją AS i ADLS jest składowanie dużych zbiorów danych.  

Przyjrzyjmy się im bardziej szczegółowo: 

Azure Blob Storage (ABS)  

ABS pojawił się na Azure kilka lat temu. Jego podstawowe cechy to: 

• Składowanie danych bez limitu (standardowy limit – który jednak można usunąć – to ponad 5 PB).  
• Limit dla pojedynczego pliku danych (blob) to 4,7 TB.  
• Występuje w dwóch podstawowych rodzajach (ang. Tiers) Standard i Premium (Premium jest lepiej przystosowany do obsługi plików o mniejszych rozmiarach). 
• Umożliwia składowanie w kilku warstwach (ang. Access Tiers) – Premium, Hot, Cool, Archive różniących się ceną, wydajnością i kosztem operacji – im „zimniejsza” warstwa, tym tańsze składowanie (przestrzeń), ale wolniejsze i droższe są operacje dostępu do danych. 

Azure Data Lake Storage (ADLS) 

Usługa ADLS została zbudowana jako rozszerzenie ABS, umożliwiając składowanie danych w hierarchicznym systemie plików (ang. Hierarchical Namespace) – ABS składuje bowiem bloby w prostym systemie plików, opartym na słowniku Klucz / Wartość (ang. Flat Namespace). Użycie hierarchicznego systemu plików to niewątpliwie udogodnienie, co można zaobserwować przy atomowych operacjach dotyczących dużej liczby blobów, jak np. przeniesienie w inne miejsce. ADLS z takim systemem plików jest też bardziej wydajny, ale są dwa punkty, w których przegrywa ze starszą usługą: 

1. Jest trochę droższy w zakresie koszów operacji na danych.  
2. Ma nieznacznie ograniczone możliwości, jeżeli chodzi o zabezpieczenie przed wszelkiego rodzaju katastrofami – magazyn ADLS może mieć redundantną kopię w innym rejonie świata, ale przełączenie na kopię może być uruchomione jedynie przez Microsoft, gdy zorientuje się, że coś nie działa. W przypadku starszej usługi ASB kopię może przełączyć sam użytkownik z poziomu portalu Azure’a. Niby to drobnostka, ale w przypadku systemów krytycznych dla biznesu może mieć znaczenie. 

Azure Stream Analytics (AStA) – przetwarzanie strumieniowe PaaS 

Jedną z ciekawszych usług przetwarzania danych udostępnionych przez Microsoft na platformie Azure jest Azure Stream Analytics (na potrzeby tego artykułu będę posługiwał się skrótem AStA, dla odróżnienia od ASA – Azure Storage Account i Azure Sunapse Analytics). Jako że jest to usługa strumieniowego przetwarzania danych udostępniona w modelu PaaS, nie dotkniemy tu „serwerów” ani nie wybierzemy rozmiaru pamięci naszego silnika przetwarzania danych. Prawie wszystkie parametry skali przetwarzania sprowadzają się do przypisania do zadania magicznego czynnika Streaming Units (SU). Większe ilości SU przyznają więcej mocy procesora, pamięci do zadania, a także przy większych ilościach SU – większą liczbę instancji przetwarzających strumień danych równolegle. Zadania AStA mogą być wykonywane na wirtualnych klastrach współdzielonych z innymi klientami Microsoftu (multi-tenant), jak również na izolowanym i dedykowanym klastrze (usługa Azure Stream Analytics Cluster) z zastrzeżeniem, że dedykowany klaster nie może alokować mniej jednostek niż 36 SU (oznacza to większy koszt startowy). 

AStA oferuje ciekawy sposób oprogramowania zadań przetwarzania strumieniowego. Zadania tworzy się tu w formie kwerendy (lub zestawu kwerend) z użyciem konkretnego rozszerzenia, języka T-SQL. Innymi słowy – kod zadania ASA wygląda jak SQL, z zastrzeżeniem, że niektóre „wirtualne tabele” z których ASA czyta i do których pisze, to w rzeczywistości źródła danych strumieniowych (zwykle kolejki) i zbiory wyjściowe (tu mamy pełną gamę możliwości zapisywania wyników do kolejek wyjściowych, zbiorów na Azure Storage, baz SQL i NoSQL, hurtowni czy systemu BI). Trudno się oprzeć wrażeniu, że jest to rozwiązanie odzwierciedlające możliwości platformy open-source zaproponowanej przez Confluent.io i opartej na systemie Kafka i języku KSQL. 

Jako że podstawą analizy strumieniowej jest analiza kontekstowa wymiarze czasu, to język T-SQL usługi ASA został wyposażony w specjalne funkcje pozwalające agregować wyniki kwerendy po kluczach i w odpowiednich interwałach czasowych (agregaty per okno czasowe). Mamy tutaj takie możliwości jak: 

• Tumbling Window – stała agregacja jedynie po czasie – podsumowanie i generowanie wyników następuje zawsze po określonej liczbie sekund (periodycznie). 
• Hoping Window – stała agregacja po czasie z przesunięciem – okna czasowe, w których obliczane są wyniki, mogą na siebie zachodzić, okno następne może się zacząć przed zakończeniem poprzedniego. 
• Sliding Window – dynamiczna agregacja po czasie z oknami czasowymi stałej długości – ale granice okien czasowych są wyznaczane przez kolejne rekordy pojawiające się na wejściu – okna czasowe zatem zaczynają się i kończą w nieustalonych z góry momentach. 
• Session Window – dynamiczna agregacja po czasie z oknami czasowymi różnej długości – okno czasowe jest wydłużane (sesja), jeżeli wybrane rekordy pojawiają się odpowiednio często. 

Innymi ciekawymi rozszerzeniami T-SQL na użytek ASA są funkcje geolokacyjne (ang. Geospatial Functions) oraz natywne możliwości czytania rekordów wejściowych, które są zakodowane w postaci obiektów najczęściej transportowanych wielkoskalowymi kolejkami AVRO i JSON. Jeżeli ktokolwiek chce szybko zbudować w Azure system strumieniowy, to z pewnością użycie AStA jest jednym z pomysłów, które warto rozważyć.  

Azure Synapse Analitics i Azure Databricks – pojedynek gigantów 

W ostatnim czasie podstawowym frameworkiem do analizy zbiorów Big Data stał się Spark. Jego niezaprzeczalne walory oparte na rozproszonym przetwarzaniu z użyciem samej tylko pamięci zostały docenione przez całą rzeszę użytkowników na świecie. Konsekwencją tej popularności jest pojawienie się Databricks – komercyjnej platformy początkowo zorientowanej na to redukowanie niedogodności związanych z zarządzaniem klastrami Sparka (Managed-Spark). W odpowiedzi na popularność Databricks Microsoft przygotował swoją wersję platformy analitycznej Big Data. Oba rozwiązania konkurują ze sobą, starając się sprostać wymaganiom nowoczesnych systemów Big Data – każdy w trochę innym modelu.  

Azure Synapse Analytics – hurtownia Big Data 

Azure Synapse Analytics wspiera bodaj najpopularniejszy model organizacji danych w nowoczesnych systemach danych. Wszystko zostało pomyślane w taki sposób, aby wspierać architekturę danych nazywaną kiedyś Two-Tier Data – zakładająca współistnienie dwóch równoległych głównych magazynów danych: 

• DataLake – jako magazynu przechowującego dane nieustrukturyzowane oraz wstępnie przetworzone  
• Hurtowni danych – jako źródła dla systemów BI. 

Ten dwutorowy model powstał, gdy zorientowano się, że nie istnieje jedno rozwiązanie odpowiadające potrzebom wszystkich popularnych przypadków użycia danych. Hurtownie są znacznie wygodniejsze jako źródła danych dla systemów opartych na SQL (w tym BI), ale dużo mniej wygodne, jeżeli chodzi o eksplorację danych (Data Science) oraz źródło danych do trenowania modeli sztucznej inteligencji (Machine Learning). Stąd pomysł, aby w systemie obydwa te byty istniały równolegle. 

Azure Synapse Analytics w pełni implementuje ten model. Centralnym elementem platformy jest tandem – wysoce skalowalna chmurowa hurtownia danych Azure Synapse DWH (Built-in pool) oraz środowisko zarządzalnych klastrów Spark do analiz danych w Data Lake. To jednak jeszcze nie wszystko. Pod jednym dachem Microsoft umieścił dodatkowe usługi przetwarzania danych.  

Znajdziemy tu zintegrowane: 

• Data Factory – usługa integracji danych. 
• Serverless SQL Pools – system serwerów SQL on-demand – gdzie użytkownik płaci jedynie za czas i zasoby zużyte do wykonania zapytania, bez ponoszenia kosztów serwera czy maszyny wirtualnej. 
• Data Explorer – usługa analizy danych. 

Każdą z tych usług można oprogramować w ich natywnym języku (SQL, KustoQL, Python, Scala, a nawet C#). 

Do dyspozycji mamy więc o wiele więcej niż prosty system hurtownia + Data Lake. Zyskujemy scentralizowaną platformę udostępniającą wszystko, co najlepsze pod dachem Microsoftu do analizy danych. Brawo za pomysł! 

Azure Databricks – architektura Lakehouse 

Azure Databricks jako bezpośrednia konkurencja Azure Synapse Analytics realizuje trochę inny model. Ta strategia wynika z faktu, że Databricks powstał jako środowisko do łatwego zastosowania Sparka i koncepcja silnika Big Data jako centralnego elementu pozostała tu silnie zakorzeniona. W ciągu dwóch ostatnich lat Databricks zorientował się jednak, że sam Spark nie wystarczy. Wraz ze swoimi partnerami rozbudował platformę o dodatkowe funkcjonalności prowadzące do powstania kompletnie nowego modelu platformy danych – Lakehouse Architecture.  

Koncepcja Lakehouse w skrócie bazuje na tym, że platforma ciągle polega na danych umieszczonych w Data Lake, ale udostępnia większość funkcjonalności dostępnych dotychczas tylko w hurtowniach: 

1. Transakcyjność – model ACID dla (niektórych) zbiorów Big Data.
2. Wsparcie wysoce wydajnego silnika zapytań SQL.
3. Mechanizmy kontroli dostępu do danych w Data Lake (Data Governance).
4. Wsparcie importu danych i orkiestracje ETL.

Model Lakehouse to naprawdę mała rewolucja. Zapewne nie będzie on aż tak wydajny jak model typu StarSchema w dobrej hurtowni danych, ale koncepcja Lakehouse opiera się na paradygmacie taniego składowania dużych zbiorów danych. Stąd Databricks zakłada, że skoro składowanie danych jest tanie, mogą być one przechowywane i organizowane w redundantnych kopiach (tabelach) skierowanych pod konkretne zastosowania – przy jednoczesnym założeniu, że dane są klasyfikowane w ich zaawansowaniu (koncepcja klas tabel Bronze-Silver-Gold).  

Patrząc z boku, Databricks zbliża się do koncepcji reprezentowanych przez innych konkurentów, np. do platformy Vertica z podobnym redundantnym i specjalizowanym modelem tabel. 

DeltaLake – transakcyjność Big Data 

Idea Lakehouse nie byłaby kompletna bez wspierania koncepcji transakcyjności. Oczywiście transakcyjności nie da się łatwo zaimplementować dla surowych i nieustrukturyzowanych danych, ale dla danych przetworzonych można się już o to pokusić. Do realizacji tego celu Databricks i partnerzy (Delta.io) zaproponowali nowy format zapisu tabel „zarządzanych” o nazwie „Delta”. Delta to rozszerzenie koncepcji tabel opartych na formacie Parquet, czyli kolumnowym formacie plikowym.

Delta zakłada, że obraz „tabeli” reprezentowanej przez zestaw plików w magazynie nie opiera się na prostej sumie wszystkich rekordów ze wszystkich plików danych. Obok plików z danymi Delta utrzymuje tzw. Delta-Log, czyli zestaw plików opisujący transakcje na zbiorze. Innymi słowy, przy zmianie zawartości tabeli w magazynie pojawiają się nowe wersje starych plików ze zmienionymi danymi, a informacja o zakończonej transakcji (o tym, że nowy plik jest ważniejszy niż stary) jest zapisywana w Delta-Logu. Ponieważ w tym samym momencie w zbiorach plików występują pliki z danymi z różnych okresów, w Delta-Logu przechowywane jest ich wersjonowanie. Dzięki tej prostej koncepcji tabele Delta mają cechy ACID, a przy tym… możliwa jest podróż w czasie, tzn. można poprosić o obraz tabeli z pewnego momentu w przeszłości. Oczywiście w dowolnym momencie możemy wyczyścić tabelę z plików / rekordów historycznych, co spowoduje zmniejszenie jej wielkości w magazynie danych. 

SQL Warehouse – SQL w służbie Big Data 

Natywnym językiem wielu rozwiązań klasy BI pozostaje SQL. Z tego powodu koncepcja Lakehouse musi uwzględniać jak najszersze wsparcie dla tego języka. Oczywiście podstawowa wersja silnika Sparka zawiera wbudowany „Spark SQL”, ale jego użyteczność była trochę ograniczona. W celu poprawienia tej sytuacji Databricks zaproponował nowy rodzaj silnika zapytań o nazwie Photon oraz nowy typ klastrów dla zapytań SQL – SQL Warehouses (albo SQL endpoints). Ze względu na to, że nowy silnik zapytań wykorzystuje mocno cache klastry SQL Warehouse trzeba opierać się na trochę mocniejszych maszynach (w Azure to Standard_E8ds_v4, czyli 8 vCore’ów i 64 GB pamięci). Zwiększony koszt pozostaje jednak pod kontrolą, ponieważ działają na nich wszystkie dotychczasowe mechanizmy autoskalowania w górę i w dół, aż do osiągnięcia limitów określonych przez administratora.  

Z moich obserwacji wynika, że zastosowanie nowego silnika i nowych klastrów znacząco przyspieszyło wykonywanie zapytań SQL na zbiorach Big Data. Oczywiście ponieważ ciągle pod spodem mamy zbiory plikowe, warto pokusić się o stworzenie właściwej organizacji danych, nie wahając się przed tworzeniem redundantnych i dedykowanych zbiorów pod najbardziej krytyczne zapytania – po to, żeby umożliwić silnikowi skorzystanie z optymalizatorów wykorzystujących partycjonowanie oraz dane indeksów i metadane dostępne w niektórych typach plików (np. Delta). 

Unity Catalog – właściwy Data Governance w Data Lake 

Nie można by nazwać rozwiązania przygotowanego przez Databricks hurtownią danych bez rozbudowanego mechanizmu umożliwiającego zarządzanie danymi. W tym celu Databricks zaimplementował nowy, lepszy mechanizm „katalogu danych”, czyli metabazy przetrzymującej informacje o zbiorach danych i ich schematach widzianych jako tabele. W tradycyjnych środowiskach Big Data (również opartych na Sparku) ten element bazował na najpopularniejszym katalogu Hive Metastore albo katalogu Impala. Databricks zaproponował swoją własną wersję katalogu danych nazwaną Unity Catalog. Unity Catalog pozwala na rozbudowaną kontrolę nad zbiorami Big Data: 

• System zarządzania oparty na instrukcjach ANSI SQL.
• Szczegółowy audyt i analizę logów dostępu do danych.
• Przypisywanie uprawnień do zbiorów danych na poziomie konta użytkownika.
• Wsparcie dla implementacji uprawnień na poziome rekordów (Row-Level Security) oraz kolumn (Column-Masking Policy).
• Scentralizowane i bezpieczne przeszukiwanie metadanych – pozwalające zrozumieć, które zbiory / tabele Big Data zawierają jakie dane.
• Wizualizacje powiązań między zbiorami – grafy przedstawiające zależności między zbiorami z uwzględnieniem uprawnień użytkownika korzystającego z tej funkcjonalności.
• Lepsza efektywność kwerend zbiorów zarejestrowanych w Unity Catalog – wynikająca z określonego przeorganizowania katalogu i przetrzymywania jego zapisów w pamięci w skompresowanej formie.

Jak widać powyżej, korzyści, które wnosi nowy metastore Databricks, są rewolucyjne. Migracja zwykłego Hive Metastore do Unity Catalog jest prosta i na pewno warto to zrobić, żeby wynieść poziom zarządzania danymi na niespotykany dotąd poziom. 

Delta Sharing – udostępnianie danych na zewnątrz 

Najnowsza wersja platfrom Databricks wprowadza jeszcze jedną użyteczną funkcjonalność – w pełni kontrolowane udostępnianie danych na zewnątrz. Proces ten jest realizowany z użyciem rozwiązania Delta Sharing, które zostało wbud

Takie rozwiązanie jest bardzo wygodne w przypadku gdy system Big Data został oparty na danych od wielu klientów (np. serwisów typu multi-tenant). Właściciel systemu Big Data ma dostęp do wszystkich udzielonych mu danych, mając jednocześnie możliwość udostępnienia określonych informacji/wyników na zewnątrz w taki sposób, aby jego indywidualni partnerzy mieli dostęp jedynie do swoich podzbiorów. 

Cloud przyszłością Big Data 

Mój artykuł jedynie pobieżnie poruszył temat kilku ważnych usług z portfolio Azure. Żeby opisać je dokładnie, potrzebny byłby cały cykl. Mam nadzieję jednak, że treść zainteresowała was na tyle, aby spróbować swoich sił z tematem projektowania i implementacji systemów Big Data z użyciem Azure. Rewolucja oparta na danych trwa nadal. Warto się stać jej częścią. Jeżeli macie jakieś wątpliwości lub pytania służymy pomocą!  

1. 1. Typy baz danych
2. 2. Czym jest SQL?
3. 3. Czym jest relacyjna baza danych?
4. 4. Jak działają relacyjne bazy danych SQL?
5. 5. Typy relacji
6. 6. Jak działają nierelacyjne bazy danych NoSQL?
7. 7. Nierelacyjne bazy danych vs relacyjne bazy danych
8. 8. Kiedy wybrać NoSQL, a kiedy SQL
9. 9. Baza NoSQL i SQL – porównanie
10. 10. Podsumowanie

Typy baz danych

Do najpopularniejszych rodzajów baz danych między innymi należą:

• bazy relacyjne (np. MySQL),
• bazy nierelacyjne (np. MongoDB, Oracle NoSQL database).

Czym w ogóle jest SQL?

SQL to nic innego jak język, jednakże jego przeznaczenie jest zgoła inne niż języków typu Java czy C#. SQL służy do konkretnych czynności, jakimi są dostęp do danych oraz ich modyfikacja. Będąc bardziej dokładnym, SQL oznacza Structured Query Language. Jest to język zapytań, który pozwala na pobranie określonych danych z bazy – w tym celu został stworzony: do uzyskania dostępu, przechowywania i edycji danych w relacyjnych bazach danych.

Czym jest relacyjna baza danych?

Relacyjną bazą danych jest rodzaj bazy, która przeważnie jest zbudowana z tabel. Pozwala to na dostęp do danych w relacji, które są częścią innych danych (tabeli) w tej samej bazie danych. Innymi słowy, przechowuje dane w wielu tabelach, które są ustrukturyzowane w kolumny i wiersze. Dzięki temu można wysyłać zapytania o dane z różnych tabel jednocześnie.

Relacyjna baza danych opiera się na modelu relacyjnym, a do zarządzania tym typem bazy używa się RDBMS (Relational Database Management System). Aby RDBMS mógł współpracować z wieloma rodzajami baz danych, do zarządzania i tworzenia zapytań używa się SQL, który jest w tym przypadku najpopularniejszym językiem.

Jak działają relacyjne bazy danych SQL?

Relacyjne bazy danych są oparte na modelu relacyjnym. W modelu relacyjnym dane są przyporządkowane do jednej lub wielu tabel (lub „relacji”) kolumn i wierszy, który przyporządkowuje dane do jednej lub wielu tabel (lub „relacji”) kolumn i wierszy. Każdy wiersz w tabeli posiada unikalny identyfikator, po którym jest kojarzony. Z kolei każda tabela bazy danych przedstawia pewien rodzaj encji (przykładem encji może być „klient”). Wiersze tabeli przedstawiają konkretną instancję tej encji (np. klient – Jan Kowalski), a kolumny, zwane też atrybutami, przedstawiają szczegóły danego obiektu (np. imię, adres). Same relacje to nic innego jak dopasowanie danych w różnych tabelach na podstawie kluczy głównych i kluczy obcych.

Typy relacji

Główne typy relacji to:

1:1

Relacja jeden do jednego pomiędzy dwoma tabelami. Zachodzi ona wtedy, gdy każdy rekord z pierwszej tabeli ma przyporządkowany dokładnie jeden rekord z drugiej tabeli i na odwrót. Aby zdefiniować relację jeden do jednego, należy w drugiej tabeli umieścić wartość klucza podstawowego z pierwszej tabeli.

1:W

Relacja jeden do wielu również zachodzi pomiędzy dwoma tabelami. Występuje wtedy, gdy pojedynczy rekord z pierwszej tabeli posiada przyporządkowany jeden lub wiele rekordów z drugiej tabeli. Jednak druga tabela ma przyporządkowany jedynie jeden rekord z pierwszej tabeli.

W:W

Relacja wiele do wielu – taka relacja też zachodzi między dwoma tabelami. Pojedynczy rekord z pierwszej tabeli ma przyporządkowany jeden lub wiele rekordów z drugiej tabeli i na odwrót. W relacji wiele do wielu często tworzy się trzecią tabelę.

Jak działają nierelacyjne bazy danych NoSQL?

Nierelacyjne bazy danych są również nazywane bazami NoSQL. Nazwa pochodzi właśnie od podejścia do przechowywania i wyszukiwania danych w inny sposób niż w relacyjnych bazach danych opartych na SQL. Warto mieć na uwadze, że niektóre bazy nierelacyjne wspierają język SQL.

Bazy NoSQL charakteryzują się tym, że są w stanie obsłużyć dużą ilość nieustrukturyzowanych danych. Rozwiązania NoSQL nie są niczym nowym, jednak dopiero od kilkunastu lat gwałtownie zyskują na popularności właśnie ze względu na możliwości obsłużenia wielu danych, np. z urządzeń mobilnych, IoT czy Big Data.

Nierelacyjne bazy danych vs relacyjne bazy danych

Struktura:

• Bazy danych SQL przechowują dane w tabelach o stałej liczbie wierszy i kolumn.
• Bazy NoSQL przechowują dane w następujący sposób:
  • Dokument (JSON)
  • Pary klucz – wartość (key – value)
  • Grafowe bazy danych

Schemat / Diagram

• Bazy SQL wymagają stałego, wcześniej zdefiniowanego schematu. Wszystkie dane muszą mieć taką samą lub podobną strukturę. Przez to często przed rozpoczęciem prac trzeba mieć zebrane wstępne wymagania odnośnie do systemu. Ponadto elastyczność bazy może być narażona, biorąc pod uwagę, że modyfikacje (migracje) struktury mogą być skomplikowane i złożone.
• Bazy NoSQL posiadają dynamiczny schemat dla danych nieustrukturyzowanych. Stała definicja schematu nie jest wymagana, przez co wprowadzenie zmian w strukturze jest łatwiejsze.

Skalowalność

• Bazy SQL skalują się wertykalnie, pionowo (tzw. scale-up). Oznacza to, że jeśli chcemy zwiększyć ilość przechowywanych danych na pojedynczym serwerze, trzeba zwiększyć pamięć RAM, wydajność procesora lub pojemność dysku SSD. Skalowanie baz relacyjnych jest raczej trudniejsze. Żeby w wieloserwerowej bazie SQL zachować integralność danych w transakcjach, potrzebny jest backend pozwalający synchronizować wszystkie operacje zapisu i transakcje w celu uniknięcia zjawiska deadlocka (czyli zakleszczenia, wzajemnej blokady akcji).

• Bazy NoSQL skalują się horyzontalnie, poziomo (scale-out). Oznacza to, że skalowanie odbywa się przez zwiększenie liczby serwerów. Operacje JOIN pozwalają na łączenie i powiązanie części danych. Ogólnie rzecz biorąc, bazy danych NoSQL nie są zaprojektowane do wydajnej obsługi operacji typu JOIN, ale dają taką możliwość. Dane mogą znajdować się na różnych serwerach w bazach NoSQL, gdzie łączenie tabel z wielu serwerów może być kłopotliwe. NoSQL umożliwia łatwe skalowanie poprzez sharding danych. Posiadanie warstwy routingu pozwala przekierować zapytanie do odpowiedniego shardu, dzięki czemu bazy danych NoSQL są wysoce skalowalne i umożliwiają szybką obsługę zapytań.

Zapytania

• Język SQL istnieje od ponad 30 lat, dlatego jest powszechnie używany, popularny i cieszy się dobrą opinią. Jest niezwykle wydajny, jeśli chodzi o zapytania, operacje i pobieranie danych z relacyjnych baz danych. Dodatkowo wyróżnia się również deklaratywnością (to znaczy, że pozwala opisać to, co ma być z jego pomocą wykonane). Zaletą SQL jest to, że całkiem łatwo można się go nauczyć. Oznacza to, że analitycy biznesowi czy inni pracownicy niezwiązani z programowaniem mogą z niego korzystać bez większych problemów.

• Jeżeli chodzi o zapytania NoSQL, może to nie być tak proste jak przy użyciu SQL w bazach relacyjnych, ponieważ zwykle wymaga dodatkowego przetwarzania danych i nie ma jednego deklaratywnego języka zapytań. Dlatego zadania z wykorzystaniem NoSQL są zwykle wykonywane przez programistów.

Podsumowując, sposób uruchamiania zapytań w bazach NoSQL w dużej mierze zależy od bazy. Na przykład w MongoDB, aby zażądać danych z bazy dokumentów JSON, należy określić dokumenty z właściwościami, do których wyniki powinny być dopasowane, i zastosować następującą funkcję: db.collection.find()

Inne popularne rozwiązania mogą obejmować tworzenie funkcjonalności wysyłania zapytań bezpośrednio w warstwie aplikacji (a nie w warstwie bazy danych) lub implementację MapReduce, platformy ułatwiającej przetwarzanie dużych zbiorów danych.

Kiedy wybrać NoSQL, a kiedy SQL

Teraz, gdy już znamy główne różnice pomiędzy SQL i NoSQL, spróbujmy odpowiedzieć na pytanie: kiedy wykorzystać relacyjne bazy danych, a kiedy nierelacyjne? Jak to często bywa w IT – decyzja zależy od wielu składowych. W tym wypadku główne kwestie do rozważenia to:

1. Rodzaj danych
2. Sposób zarządzania bazą danych
3. Ilość danych

Kiedy wybrać SQL?

Odnosząc się do pierwszej składowej, rodzaju danych – w tym wypadku bazy relacyjne sprawdzą się lepiej niż bazy NoSQL, jeżeli spójność i integralność danych jest kluczowa.

Powszechne jest przekonanie, że relacyjne bazy danych nie są dobrym wyborem do obsługi dużej ilości danych. To stwierdzenie jest nie do końca prawdziwe. Wiele baz danych typu MySQL czy PostgreSQL radzi sobie bardzo dobrze z dużą ilością danych. Bazy relacyjne posiadają stały, ustalony schemat i wymagają danych, które są ustrukturyzowane. Utrzymanie takiej struktury, spójności i wydajności może się okazać bardzo trudne, jeśli z pomocą bazy relacyjnej będziemy obsługiwać biznes związany z Big Data.

Na pierwszy rzut oka mogłoby się wydawać, że stała struktura może być ograniczająca, jednak nie ma tu reguły. Posiadanie stałej, odgórnie zdefiniowanej struktury sprawia, że bazy SQL są lepszą opcją do obsługi systemów płatniczych czy też systemów rezerwacji. Ciekawostką jest, że większość instytucji finansowych opiera się właśnie na relacyjnych bazach danych. Relacyjne bazy zapewniają transakcyjność, czyli integralność danych i ich prawidłowość. SQL może czasami ograniczać pewne funkcjonalności, ale z drugiej strony jest bardzo dojrzałą i sprawdzoną technologią.

Kiedy wybrać NoSQL?

Bazy NoSQL są w stanie przechowywać różne rodzaje danych i nie muszą być one żaden sposób ustrukturyzowane. Dlatego nierelacyjne bazy danych zapewniają większą elastyczność i są dobrym wyborem do obsługi dużej ilości danych bez wspólnej struktury.

Przeważnie im bardziej rozbudowany jest zbiór danych, tym większe prawdopodobieństwo, że baza NoSQL będzie lepszym wyborem. Bazy nierelacyjne mają dobre predyspozycje względem skalowalności i dostępności, przez co jest to idealne rozwiązanie dla aplikacji, które działają w czasie rzeczywistym (np. gry hazardowe online, komunikatory).

Jaką bazę danych zatem wybrać?

Żeby odpowiedzieć na to pytanie, należy najpierw zrozumieć domenę. Jaki efekt próbuje się osiągnąć? W obecnych czasach często wybór między SQL i NoSQL nie jest kwestią tego, której bazy użyć, tylko tego, kiedy i gdzie używać każdej z tych baz w ramach tej samej aplikacji czy systemu.

Osobiście pracuję nad aplikacją, w której użycie bazy NoSQL było – nie zagłębiając się w szczegóły – najbardziej sensowne, jednak ta sama aplikacja wymagała też raportów. Żeby uniknąć nadmiernych problemów i analiz, uznałem, że wykorzystam oba typy baz danych. Użyłem NoSQL dla aplikacji internetowej i desktopowej oraz SQL dla samych raportów. Informacje są przechowywane w bazie NoSQL, a tylko dane wymagane do raportów są przesyłane do bazy SQL.

Baza NoSQL i SQL – porównanie

Podsumowanie

Wybór odpowiedniej bazy danych nie jest łatwy, nawet dla ekspertów, a podjęcie decyzji, czy wybrać relacyjne, czy nierelacyjne bazy może zależeć od wielu czynników. Należy również wziąć pod uwagę, jak wiele opcji jest dostępnych na rynku w zakresie baz SQL i NoSQL. Na przykład, w przypadku dużej ilości nieustrukturyzowanych danych dobrym rozwiązaniem mogą być bazy CouchDB lub MongoDB. Jednak w przypadku, gdy priorytetem będzie wysoka dostępność, lepszym wyborem mogą okazać się Redis i Cassandra.

Z drugiej strony bazy danych SQL oferują wiele korzyści w zakresie transakcji na danych i ich ogólnej integralności. Co więcej, relacje w nich można łatwo zidentyfikować i zdefiniować, co ułatwia wyciąganie wniosków z krytycznych spostrzeżeń.

Idź do:

1. 1. E-commerce to nie tylko sklepy internetowe
2. 2. Wyzwania systemów bazodanowych w e-commerce
3. 3. Co wybrać: nierelacyjne bazy danych czy relacyjne bazy danych?
4. 4. Czym jest MongoDB?
5. 5. NoSQL w e-commerce, czyli co MongoDB może zaoferować branży?
6. 6. Podsumowanie

E-commerce to nie tylko sklepy internetowe

E-commerce to nic innego jak handel przeniesiony do Internetu. Przy czym mówimy tu o samej transakcji kupna-sprzedaży, gdyż płatność i dostawa mogą być realizowane w sieci, jak i poza nią. Najbardziej znanym i przez część osób utożsamianym z tym pojęciem rodzajem handlu są sklepy internetowe. Należy jednak nadmienić, że poza e-sklepami możemy jeszcze wyróżnić serwisy aukcyjne, e-kantory, bankowość elektroniczną czy platformy bukmacherskie.

Wyzwania systemów bazodanowych w e-commerce

System bazodanowy w e-commerce to narzędzie do zadań specjalnych.

Dobrze skonfigurowany system bazodanowy powinien:

• zagwarantować dostępność danych 24/7
• utrzymać szybkość odpytywania w okresie wzrostu użycia
• zapisywać ogromne ilości danych
• informować w sposób dynamiczny i ciągły o zmianach (np. dostępności danego produktu)

W tym celu firmy e-commerce powinny postawić na skalowalność bazy danych. To istotne zwłaszcza w czasie peaków w e-commerce, takich jak Black Friday, Cyber Monday i związaną z nimi zwiększoną liczbą zapytań.

Przeczytaj także: 5 najpopularniejszych narzędzi do analizy danych biznesowych

Co wybrać: nierelacyjne bazy danych czy relacyjne bazy danych?

Zastanówmy się trochę głębiej nad przechowywaniem danych dla usług e-commerce. Do wyboru mamy kilka typów baz danych, przy czym najbardziej znane są relacyjne (SQL) i nierelacyjne (NoSQL). Przyjrzyjmy się różnicom między nimi. Żeby być bardziej precyzyjnym, SQL jest to Structured Query Language, czyli język do pozyskiwania danych z bazy relacyjnej. Przyjęło się jednak tego typu bazy danych nazywać „bazami SQL”, zatem tej nazwy będę używał przy porównywaniu. Upraszcza to też zapamiętanie nazwy drugiego rodzaju baz, czyli NoSQL, które często określa się po prostu jako „nie SQL”.

Przechodząc do różnic, możemy wyróżnić 5 podstawowych, które zebrałem w tabeli poniżej:

Jak widać, bazy NoSQL idealnie wpisują się w wymagania i potrzeby rynku e-commerce w kontekście dostępności i przechowywania danych. Obecnie najpopularniejszym systemem bazodanowym tego typu jest MongoDB.

Czym jest MongoDB?

MongoDB to dokumentowa baza danych zaprojektowana z myślą o łatwości tworzenia i skalowania. Dokumenty są tworzone i przechowywane w formacie BSON, czyli Binary JSON. Zastosowanie JSON oznacza, że ​​bardzo łatwo jest przekonwertować zapytania i wyniki do formatu, który rozumie kod frontendowy, w którym napisana jest aplikacja e-commerce. Jest też on bardziej czytelny dla człowieka. To rozwiązanie NoSQL obejmuje hierarchiczność, automatyczne fragmentowanie i wbudowaną replikację dla lepszej skalowalności i wysokiej dostępności.

Mając już obraz tego, jakie są główne wyzwania w e-commerce, oraz upewniając się, że MongoDB to dobry wybór w kontekście przechowywania danych, możemy zastanowić się nad odpowiedzią na pytanie: co MongoDB może zaoferować branży e-commerce?

NoSQL w e-commerce, czyli co MongoDB może zaoferować branży?

Dynamiczne schematy

Dzięki dynamicznym schematom dokumenty w kolekcji nie muszą posiadać tych samych pól, a i dane pole może mieć różne typy w zależności od dokumentu. Zwiększa to elastyczność mapowania na encje czy obiekty. Praktyka pokazuje jednak, że struktura dokumentów wewnątrz kolekcji jest podobna. Aby to zagwarantować, MongoDB wprowadziło możliwość ustawienia reguł walidacyjnych na kolekcję.

Łatwa hierarchizacja danych

Zastosowanie formatu JSON pozwala na łatwą hierarchizację danych. Możemy to zrobić poprzez osadzenie jednego dokumentu wewnątrz drugiego lub poprzez przekazanie referencji. Użycie jednej bądź drugiej metody powinno być rozpatrywane indywidualnie dla każdej kolekcji. Zalecane jest stosowanie osadzenia, ponieważ pozwala to pozyskać dane w wyniku pojedynczego zapytania, co zwiększa wydajność systemu. Referencje warto rozważyć dla bardziej skomplikowanych reprezentacji hierarchii bądź w sytuacji, kiedy korzyści z zagnieżdżenia nie przeważają nad skutkami duplikacji danych (takimi jak np. potrzeba monitorowania zmian przy podmianie danych)

Replikacja

MongoDB używa konceptu nazwanego Replica Set, czyli zestawu node’ów zawierających te same dane. Umożliwia to replikację danych, której celem jest zwiększenie dostępności oraz zabezpieczenie się przed awariami serwerów bazodanowych. Dobrze zaprojektowana architektura pozwala również na szybszy dostęp do danych.

Kluczowe założenia i mechanizmy replikacji omówimy na podstawie poniższego schematu:

Zestaw replik składa się z jednego node’a, tzw. członka głównego (Primary), oraz członków drugorzędnych (Secondary). Istnieje też specjalny członek takiego zestawu, sędzia (Arbiter), który nie posiada kopii danych, ale służy do wybierania zastępcy w przypadku niedostępności głównego serwera.

Operacje zapisu wykonywane są wyłącznie na głównej instancji, z której później mechanizm wbudowany MongoDB kopiuje dane na pozostałe. Operacje odczytu domyślnie również przechodzą przez wiodącą instancję, ale istnieje możliwość skonfigurowania node’ów, tak aby to poboczne serwery służyły do obsługi zapytań, przy czym może to się wiązać z wystąpieniem tzw. eventual-consistency, czyli z opóźnioną aktualnością danych.

Istotny dla całej koncepcji replikacji jest mechanizm taktowania (heartbeat). Każdy z node’ów (members) co 2 sekundy odpytuje pozostałe w celu sprawdzenia ich dostępności. W przypadku gdy serwer główny jest niedostępny, następuje wybór nowego. Proces ten polega na wybraniu spośród pozostałych instancji tej, która ma ustawiony najwyższy priorytet. Dokumentacja stwierdza, że replika może posiadać do 50 node’ów, przy czym tylko 7 z nich może brać udział w wyborze (voting), i to spośród nich wybierany jest następca. Pozostałe serwery, nazwane Non-Voting members, muszą mieć właściwości votes i priority ustawione na 0. Zaleca się, aby liczba instancji z możliwością głosowania była nieparzysta, stąd też minimalna liczba  node’ów w replice to 3.

Fragmentacja

Fragmentacja polega na podzieleniu zestawu danych na mniejsze części, dzięki czemu możemy skalować horyzontalnie, praktycznie w nieskończoność. MongoDB do obsługi fragmentacji używa klastra, który składa się z następujących elementów:

• Shard, czyli zestawu replik, który zawiera część kolekcji (Chunk)
• Router, który działa trochę jak load balancer i na podstawie konfiguracji przekazuje polecenia do odpowiedniej podkolekcji, żeby zrównoważyć obciążenie
• Config server, przechowujący metadane i konfigurację klastra

Zależności pomiędzy komponentami przedstawia poniższy schemat:

Istotne w przypadku fragmentacji danych jest dobranie odpowiedniego klucza oraz strategii.

Wybierając pole dokumentu, którego chcemy użyć jako klucza, powinniśmy rozważyć:

• Kardynalność – czyli na jak wiele elementów możemy podzielić kolekcję względem klucza
• Powtarzalność – czy któraś wartość nie pojawia się zdecydowanie częściej niż pozostałe
• Jednostajność – czy nowe wartości klucza nie są wzrastające / malejące w sposób liniowy
• Częstotliwość zapytań – klucz powinien być wykorzystywany w najczęstszych zapytaniach

Jeżeli chodzi o strategie, mamy do dyspozycji dwie:

Hashed Sharding

Przy tej strategii MongoDB automatycznie generuje Hash z wartości pól kluczy. Sprawdza się ona w przypadku gdy wartości klucza zmieniają się jednostajnie. Zastosowanie hasha zwiększa równomierne rozdzielenie dokumentów pomiędzy udziałami (Shards). Minusem jest to, że w przypadku zapytań o dany zakres mało prawdopodobne jest, iż wszystkie dokumenty będą w jednym udziale. Skutkuje to odpytywaniem wszystkich części kolekcji (chunks), ponieważ router nie jest w stanie jednoznacznie określić, w którym udziale znajdują się szukane dokumenty.

Ranged Sharding

Każdy z udziałów przechowuje części kolekcji w danym zakresie wartości klucza. Strategia ta sprawdza się, kiedy zbiór wartości dla klucza jest duży, ale powtarzalność każdej z nich jest mała. Ogromną zaletą jest możliwość ukierunkowania zapytania na konkretny udział bądź  kolekcję, co znacząco wpływa na szybkość odpytywania.

Dzieleniem na części oraz ich rozmieszczaniem zajmuje się wbudowany mechanizm MongoDB, który dba o równe ich rozdystrybuowanie oraz stara się utrzymać zbliżoną wielkość każdego z nich. Decydując się na fragmentację, należy pamiętać, że MongoDB nie oferuje metody scalenia danych, a jedynie możliwość ponownej fragmentacji po innym kluczu.

Strumienie zmian

Od wersji 3.6 MongoDB pozwala nasłuchiwać zmian w wybranej kolekcji, bazie lub całym systemie, z wyjątkiem kolekcji admin, lokal i config. Odbywa się to poprzez otwarcie kursora, który pozwala iteracyjnie przechodzić po zdarzeniach związanych z danym zakresem. Ponieważ mechanizm ten używa agregacji, możemy również nasłuchiwać konkretnych zmian czy też modyfikować odebrane notyfikacje. Podstawowym wymaganiem jest użycie zestawu replik, gdyż powiadomienie następuje w momencie zapisu zmiany na większości z tych, które są odpowiedzialne za przechowywanie danych.

Strumienie zmian wykorzystują specjalną, ograniczoną kolekcję oplog, która przechowuje informację o operacjach wpływających na aktualny stan danych. Dokumenty w tej kolekcji rotują, oznacza to, że nowy dokument w przypadku osiągnięcia limitu rozmiaru kolekcji powoduje usunięcie najstarszych. Dlatego należy dobrać odpowiedni rozmiar dla tej kolekcji, zależny od częstotliwości występowania zdarzeń, tak aby możliwe było przechwycenie wybranego, zanim zostanie ono usunięte.

Podsumowanie

Wartość polskiego rynku e-commerce w 2020 r. przekroczyła 100 mld zł, jednocześnie według raportu „E-commerce w Polsce 2021”, opracowanego przez Gemius dla e-Commerce Polska, aż 77% Polaków deklaruje, że kupuje online. Wskazuje to wyraźny, utrzymujący się już od dłuższego czasu trend przenoszenia się handlu do Internetu. Według prognoz tak dynamiczny rozwój e-handlu w Polsce utrzyma się jeszcze przez kilka najbliższych lat.

Klienci mają coraz większe wymagania co do stron internetowych czy aplikacji. Do najważniejszych czynników zwiększających tzw. User Experience należą dostępność, szybkość i niezawodność. Dobrze skonfigurowany system bazodanowy taki jak MongoDB jest odporny na awarie, skalowalny i pozwala na hierarchizację i zapis sporych ilości danych, zatem w pełni odpowiada na potrzeby projektów e-commerce.  

Idź do:

1. 1. Czym jest grafowa baza danych?
2. 2. Wybór bazy danych
3. 3. Zalety Neo4j
4. 4. Co to znaczy, że Neo4j jest bazą NoSQLową?
5. 5. Wyszukiwarka połączeń autobusowych – case study
6. 6. Kłopotliwy RDBMS
7. 7. RDBMS pełne Joinów
8. 8. RDBMS pełne podzapytań
9. 9. Case study: użycie grafu Neo4j
10. 10. Podsumowanie

Czym jest grafowa baza danych?

Neo4j (https://neo4j.com/) jest jedną z najpopularniejszych, o ile nie najpopularniejszą grafową bazą danych. Dla przypomnienia i uporządkowania wiedzy: graf jest kompozycją dwóch typów elementów, jakimi są węzły i relacje. Węzeł może reprezentować określony typ lub kilka typów i posiada swoje właściwości (ang. properties). Relacje zaś poza nazwą i własnymi właściwościami posiadają – co najistotniejsze – kierunek oddziaływania. Wspomniane właściwości są kolekcjami par klucz – wartość. Służą do przechowywania istotnych informacji. Dla przykładu: jeżeli węzłem będzie osoba, to jej właściwościami mogą być: imię, nazwisko, wiek albo lista ulubionych książek.

Relacje między węzłami w Neo4j – jak i w grafowych bazach danych w ogóle – są tak samo ważnymi danymi jak węzły. Traktujemy je jak obiekty, których istnienie jest determinowane przez obecność danych węzłów. Występowanie relacji samodzielne nie ma żadnego uzasadnienia.

Relacje znane z baz danych typu RDBMS (Relational Database Management System) zazwyczaj będą nam się kojarzyć z oznaczaniem danych w jakimś wierszu z jednej tabeli jako mających swoje odzwierciedlenie w konkretnym wierszu innej tabeli. Pozwoli nam to na operacje kaskadowe podczas edycji lub usuwania danych. Podczas normalizowania modelu danych w RDBMS możemy się zetknąć z koniecznością wprowadzenia specjalnych tabel pośredniczących między dwoma tabelami służącymi do wiązania ze sobą całych grup wierszy.

Czytaj także: Poznaj korzyści Test-Driven Development na co dzień

Wybór bazy danych

Wciąż jeszcze w wielu środowiskach panować może przeświadczenie, że RDBMS są najlepsze do wszelkiego rodzaju zadań. Osoby decyzyjne w zakresie doboru baz danych mogą nieprzychylnie spoglądać na alternatywne rozwiązania do przechowywania danych, a za taką zwykło się dotąd uważać właśnie Neo4j. Jak rozsądnie dokonać wyboru bazy lub baz danych do wykorzystania w projekcie? Przede wszystkim wybór powinien być zdeterminowany przez stojące przed aplikacją zadania.

Już na etapie projektowania aplikacji, jeszcze na etapie wyboru bazy danych, warto zastanowić się nad kilkoma kwestiami:

• jakie operacje będą w przyszłości wykonywane na gromadzonych danych?
• czy zadaniem aplikacji będzie zapisywanie i odczytywanie danych bez żadnych bardziej skomplikowanych operacji?
• może najistotniejsze będą wzajemne relacje między danymi, a program powinien pomagać w ich analizie?

Wybór bazy uzależniony jest więc od tego, jaka jest podstawowa funkcja projektowanej aplikacji i charakter danych. Czy będą to dane osób zatrudnionych w konkretnej organizacji, współtworzących jej strukturę organizacyjną, a aplikacja, którą tworzysz, będzie służyć do zapewnienia sprawnego obiegu dokumentów między pracownikami? Może masz do opracowania wyszukiwarkę połączeń lotniczych? Albo aplikację, która zapewni wsparcie logistyczne dla firmy transportowej? A może dostałeś supertajne zlecenie dla rządowych służb specjalnych polegające na zaimplementowaniu systemu wspierającego zarządzanie siatką agentów i informatorów? W ostatnim przykładzie rzeczywiście fantazja nieco mnie poniosła, ale głównie dlatego, że możliwości, jakich dostarcza nam grafowa baza danych, są naprawdę ogromne.

Jednak nie zawsze przestrzega się zasady dopasowania bazy danych do celu aplikacji, a zwolennicy nowych i często bardziej odpowiednich rozwiązań muszą zmagać się ze sceptycyzmem managerów („Przecież nikt nie korzysta z tych rozwiązań”).

Zalety Neo4j

Jakie wielkie musi być zaskoczenie i zdumienie oponentów, gdy po wejściu na stronę główną projektu Neo4j ich oczom ukazują się liczne logotypy światowych marek czy instytucji rządowych albo badawczych. Od firm medycznych, przez instytuty naukowo-badawcze, po firmy finansowe, transportowe, telekomunikacyjne i wojskowe. Pełna obszerna lista oraz case studies dostępne są na stronie projektu. To smakowity kąsek dla wszystkich zajmujących się analizą i modelowaniem danych oraz architektów aplikacji.

Jak widać, popularność Neo4j i grafowych baz danych ciągle rośnie. W wielu rankingach, w tym w moim prywatnym, baza danych Neo4j jest jednym z liderów takich rozwiązań. Warto wspomnieć o tym, że twórcy Neo4j zadbali o przyjazne zorganizowanie Clusteringu i pracy w chmurze, a najczęściej stosowanym rozwiązaniem jest Neo4j pracujący na AWS – co również przemawia na jej korzyść.

Warto pamiętać, że jako narzędzie Neo4j jest mocno wspierane zarówno przez współczesne narzędzia do pisania kodu, jak i popularne frameworki, na przykład Spring Framework w projekcie „Spring Data Neo4j”. To, że grafowa baza danych jest tak intensywnie rozwijana, dobrze wróży na przyszłość.

Co to znaczy, że Neo4j jest bazą NoSQLową?

Tak jak bazy danych z grupy RDBMS korzystają z języka zapytań SQL, tak Neo4j korzysta z języka Cypher. W obu przypadkach są to języki deklaratywne. O ile składniowo Cypher jest w wielu aspektach podobny do SQL, o tyle jedną z najczęściej wskazywanych różnic jest użycie słowa kluczowego MATCH w miejsce SELECT.  Inną jest wykorzystanie – w znaczeniu dosłownym – strzałek relacji.

Cypher to język bardzo elastyczny pod względem możliwości budowania zapytań. Widać to dobrze choćby w takich przykładach jak ten, gdzie przeprowadzamy dopasowanie warunkowe. W SQL zawsze warunek umieścimy w klauzuli WHERE, zaś w Cypher dodatkowo może zostać zawarty już podczas deklaracji węzła. Możemy tworzyć interesujące i przydatne zapytania złożone z etapów przy wykorzystaniu klauzuli WITH.

Bardzo ważna, a często nawet kluczowa, jest czytelność zapytań, którą tu odnajdujemy. Godna uwagi jest również łatwość pisania zapytań dla osób, które mają zrozumienie pojęcia grafu i zetknęły się z pisownią zapytań w SQL.

Wyszukiwarka połączeń autobusowych – case study

Zaprezentowany przeze mnie niżej przykład aplikacji do rezerwacji biletów zaczerpnięty został z życia. Problem, z którym się mierzyłem, zaistniał kilka lat temu, głównie przez przywiązanie osób decyzyjnych do rozwiązań uznanych za sprawdzone i niechęci do rozeznania w gronie developerskim w poszukiwaniu nowych możliwości.

Projekt: aplikacja, która służy do rezerwacji biletów autobusowych.

Produkt końcowy: rezerwacja miejsca i zakup biletu. Z racji zbyt dużej złożoności tematu ograniczmy się jednak wyłącznie do wyszukiwarki połączeń.

Działanie aplikacji: zanim użytkownik zarezerwuje bilet, powinien najpierw wskazać przystanek, z którego zechce odjechać, oraz przystanek docelowy z listy dostępnych.

Modelowanie: w podejściu zgodnym z RDBMS do zamodelowania tego obszaru będziemy potrzebować przynajmniej trzech tabel. Pierwszą będzie rejestr przystanków, drugą – rejestr tras, na których zlokalizowane są przystanki. W trzeciej tabeli do konkretnych tras przypiszemy poszczególne przystanki.

Kłopotliwy RDBMS

Warto zwrócić uwagę na pewien typowy problem tabeli z odwzorowanymi relacjami pomiędzy poszczególnymi wierszami spajanych tabel. Występujące w niej wiersze zawierają komórki wypełnione nieczytelnymi liczbami należącymi zwykle do indeksowanych kluczy głównych tabel w relacji. Rozszyfrowywanie pochodzenia i znaczenia tych numerów może niekiedy wymagać sporego wysiłku. Tym większego, im bardziej złożona jest tabela. W naszym przykładzie taka spajająca tabela mogłaby wyglądać na przykład tak:

Takie „twory” znajdziemy w relacjach typu „Many-to-Many”. Mogą być one szczególnie uciążliwe, gdy w projekcie jest sporo tabel, zdefiniowanych kluczy obcych i relacji. Są też problematyczne, gdy istnieje cała masa danych w skryptach potrzebnych do zasilania testowych instancji baz danych w celu integracyjnej weryfikacji poprawności implementacji. Sytuacja często kluczowa w developmencie. Nierzadko trzeba się solidnie napracować, żeby przygotować nowe rekordy danych z zachowaniem relacji do tabel pośredniczących. Dane w wierszach muszą być unikalne albo dopasowane do wzorca, zgodne z innymi danymi „nienullowymi” z co najmniej dziesięciu innych tabel. Może się zdarzyć tak, że w modelu danych zaczynają – np. przez nieuwagę – pojawiać się odwołania cykliczne. Wówczas bez wykonania operacji wyłączenia wszystkich ograniczeń na bazie, nie jest możliwe ani dalsze dodawanie nowych danych, ani nawet zaimportowanie do niej prawidłowych danych.

RDBMS pełne Joinów

Przejdźmy do pierwszego kroku przy użyciu wyszukiwarki połączeń. Będzie to wyszukiwanie przez pasażera wszystkich możliwych tras przypisanych do wybranego przystanku.

Co interesującego właśnie się stało? Dane z trzech osobnych tabel na tym etapie scaliły się w zapytaniu w jedną i możemy wybrać z niej te wiersze, które zawierają szukany przystanek. Jeżeli jedną trasę określa nam N składających się na nią przystanków połączonych z nią nazwami tras, to odrzucamy wszystkie wiersze, w których przypisany przystanek jest inny niż wskazany przez nas.

Poniżej przykład tabeli wynikowej przed okrojeniem jej z wierszy o innej nazwie przystanku niż zadany:

Po odrzuceniu wierszy, w których nazwa przystanku nie odpowiada wskazanej przez nas, otrzymujemy taki oto zbiór wierszy, który następnie należy odpowiednio przyciąć poprzez odrzucenie ewentualnych powtórzeń.

RDBMS pełne podzapytań

Wyobraźmy sobie, że teraz nasz pasażer potrzebuje listy wszystkich przystanków, do których będzie mógł dojechać, wsiadając do autobusu na wskazanym przystanku. Poniżej przykładowe zapytanie będące odpowiedzią na oczekiwanie użytkownika aplikacji.

W powyższym zapytaniu mamy do czynienia z koniecznością użycia dwóch podzapytań na rzecz jednej operacji projekcji. Występuje łącznie sześć operacji łączenia tabel przy użyciu polecenia JOIN. Złożoność tego zapytania jest jego niewątpliwą wadą. Inną wadą jest brak intuicyjności w konstrukcji powstałych w języku SQL w przypadku, gdy chcemy uzyskać wycinek zbioru danych badanej rzeczywistości. Wynikiem zapytania w naszym przykładzie będzie zbiór danych zawartych w tabeli poniżej.

Zapytania z obu poprzednich listingów to dopiero wstęp do pozostałych operacji prowadzących do kupna biletu. Kolejne zapytania będą niekiedy jeszcze bardziej złożone. Szczególnie gdy utworzymy dodatkowe tabele do przechowywania informacji o cenach biletów uzależnionych od wybranego przystanku odjazdu oraz przystanku docelowego, rodzaju trasy, kursu, pory nocnej albo np. okresowych zniżek na danych odcinkach przejazdu.

Case study: użycie grafu Neo4j

Spójrzmy na analizowany model danych przez pryzmat obiektów grafu. Co to oznacza, że coś da się opisać przy pomocy grafu? Jak pisałem na początku: graf to zbiór węzłów i ich wzajemnych skierowanych relacji. W kontekście analizowanej wyszukiwarki połączeń autobusowych nasze przykładowe węzły i relacje możemy z wykorzystaniem Neo4j przedstawić w taki sposób:

Przystanki są węzłami, a droga, która prowadzi od jednego do drugiego przystanku, w sposób naturalny określa istniejącą między nimi relację. Droga pomiędzy przystankami spowoduje wystąpienie odpowiednich tras przejazdu, więc potraktujemy trasę jako właściwość relacji przez nią wyznaczoną.

Przykładowy rezultat powyższego zapytania:

Zapytanie z listingu 3 już na pierwszy rzut oka jest o wiele bardziej intuicyjne, niż miało to miejsce w przypadku SQL. Na pewno jest też mniej skomplikowane. W powyższym zapytaniu staramy się wybrać wszystkie relacje typu LEADS TO  do innych przystanków, a wychodzące z takiego, którego nazwa odpowiada przystankowi wskazanemu w zapytaniu. Po czym zwracamy ich trasy przy użyciu słowa kluczowego RETURN.

Przejdźmy do kroku drugiego, który powinien wykonać użytkownik, by uzyskać listę możliwych przystanków, przez które będzie przejeżdżał autobus. W Neo4j uzyskamy ją, wykonując na przykład takie zapytanie jak na listingu 4.

Powyższe zapytanie możemy odczytać następująco: „Skoro między wskazanym przystankiem a kolejnymi istnieje relacja łączącej je drogi, to zwróć mi wszystkie kolejne aż do ostatniego”

Poniżej przykładowy rezultat w postaci grafu oraz w postaci tabeli nazw:

Jak widzimy w powyższych przykładach, zapytania w Cypher są dużo krótsze niż ich odpowiedniki w SQL i zaprezentowane w odpowiednich listingach SQL. Jednocześnie pozwalają uzyskać identyczne efekty. Dodatkową zaletą jest to, że w Neo4j poza widokiem tabelarycznym dostępny jest również widok węzłów i ich relacji.

Podsumowanie

Jeżeli wycinek rzeczywistości, nad którym pracujemy, stanowi zbiór obiektów i ich wzajemnych relacji – bardzo prawdopodobne, że odnajdziemy tam strukturę grafową i użycie grafowej bazy danych będzie miało sens. W niniejszym tekście chciałem zaprezentować przede wszystkim intuicyjność i łatwość w konstruowaniu zapytań w Neo4j. Podałem przykład aplikacji, w której mierzyłem się z problemem niedopasowania narzędzia do potrzeb projektu. Gdybym wówczas posiadał obecne doświadczenie i wiedzę na temat grafowych baz danych, starałbym się przekonać decyzyjne osoby w projekcie do zastosowania Neo4j. Uchroniłoby to klienta przed wieloma niepotrzebnymi problemami i wydatkami.