Bazy danych nosql – czym są? Nierelacyjna baza danych – jak ją wykorzystać?

Wraz z migracją z klasycznych silosów w kierunku mikro-usług, nowoczesny, zwinny styl programowania zmienił także paletę stosowanych narzędzi. Klasyczna formuła, u której podstaw znajduje się silnik bazy danych coraz częściej zastępowana jest architekturą rozproszoną zasilaną rozwiązaniami nierelacyjnymi nazywanymi NoSQL.

Nierelacyjne bazy danych NoSQL, czym są i jak je wykorzystać?

Akronim pochodzi od słów „non SQL” choć często mówi się „not only SQL”. Warto zauważyć tę różnicę, ponieważ w istocie już dzisiaj wiemy, że ten typ bazy danych nie tyle eliminuje klasyczny, relacyjny model, co doskonale go uzupełnia. Wszystko w zależności od konkretnych celów do zrealizowania. Bardzo istotnym katalizatorem rozwoju modelu NoSQL jest gwałtownie rosnąca popularność rozwiązań z obszaru Big Data. Wykorzystanie analiz wielkich zbiorów danych stało się tak popularne, użyteczne – a często po prostu konieczne – dla prowadzenia właściwie każdego rodzaju biznesu, że niektórzy zdobywają się na odważne stwierdzenie, iż dane są „nową ropą naftową”.

Łatwiejsze powiązanie danych z wielu źródeł

Nierelacyjne bazy danych doskonale wpisują się w trend Big Data, ponieważ – w przeciwieństwie do klasycznych silników – pozwalają na szybką analizę danych niestrukturyzowanych i badanie korelacji pomiędzy nimi. W tradycyjnej bazie schemat i relacje są w narzucone z góry a za pomocą odpowiednich zapytań SQL możemy uzyskać strukturalne odpowiedzi mieszczące się we wcześniej opisanych ramach. Przykładowo w banku możemy znaleźć dane o kliencie np. w systemie kredytowym i CRM jeśli tabelę z obu powiążemy np. za pomocą pola PESEL. Dzięki relacji między tabelami będzie można otrzymać informacje, ile osób z danej ulicy – czy danego miasta – posiada kredyt większy niż 100 tys. zł. Będzie to możliwe, ponieważ tabelę zawierającą nazwę ulicy w systemie CRM z tabelą z systemu kredytowego łączy właśnie – nawet jeśli nie bezpośrednio – informacja o numerze ewidencyjnym PESEL.

Natomiast nie będzie możliwe odnalezienie zależności pomiędzy np. sprzedażą poszczególnych kategorii produktów w supermarkecie a opadem atmosferycznym. Nie będzie to możliwe przede wszystkim dlatego, że prawdopodobnie takie dane nie są gromadzone. Najnowsze trendy pokazują, że warto gromadzić przeróżne dane, często nieustrukturyzowane, które być może początkowo wydają się nieistotne, ale w ostatecznym rozrachunku dostarczają niesamowicie wartościowych informacji biznesowych. Jeśli zatem zdecydujemy się gromadzić dane o pogodzie, prawdopodobnie nie będzie dla nich miejsca w istniejących bazach danych i systemach, ponieważ ich struktury tego nie przewidują. Wtedy właśnie przychodzi z pomocą między innymi silnik bazy danych NoSQL, gdzie możemy przekazać praktycznie dowolne dane do późniejszych analiz bez uprzedniego przygotowywania schematu i co oczywiście ważne, efektywnie z tych danych korzystać do wykonywania różnych analiz i choćby odnajdywania potencjalnych korelacji. Nie będzie zatem konieczne tworzenie dodatkowych tabeli i kolejnych kodów aplikacji do ich dedykowanej obsługi.

Interakcja z bazą NoSQL

Najczęściej odbywa się za pomocą API, a same dane przekazywane są za pomocą obiektów różnego typu za pomocą JSON, BSON, XML lub w inny, aczkolwiek zbliżony sposób. Generalną zasadą jest to, że dane przekazywane są wraz z kompletnym ich schematem:

“imię”:”Michał”, “wiek”:”12″, “miasto”:”Wrocław”

Nie ma jednak żadnych przeciwwskazań, aby następny obiekt zawierał zupełnie inne dane:

“imię”:”Adam”, “wzrost”:”134″, “miasto”:”Kraków”

Oba obiekty zostaną zachowane w bazie NoSQL tak samo i będzie można je równoprawnie przeszukiwać. Dzięki temu osiąga się znacznie większą skalowalność. Jednak brak klasycznych zapytań opartych na kolumnach i indeksach spowoduje, że analizy BI, które na nich bazują będą trudniejsze i znacznie wolniejsze niż w przypadku bazy relacyjnej.

W bazie danych NoSQL obiekty to jedna z metod ich klasyfikacji. Typy baz danych nierelacyjnych – można wyróżnić ich co najmniej 5: Column – Accumulo, Cassandra, Druid, HBase, Vertica, SAP HANA; Document – Apache CouchDB, ArangoDB, Clusterpoint, Couchbase, DocumentDB, HyperDex, IBM Domino, MarkLogic, MongoDB, OrientDB, Qizx, RethinkDB; Key-value – Aerospike, ArangoDB, Couchbase, Dynamo, FairCom c-treeACE, FoundationDB, HyperDex, InfinityDB, MemcacheDB, MUMPS, Oracle NoSQL Database, OrientDB, Redis, Riak, Berkeley DB; Graph – AllegroGraph, ArangoDB, InfiniteGraph, Apache Giraph, MarkLogic, Neo4J, OrientDB, Virtuoso, Stardog oraz Multi-model – Alchemy Database, ArangoDB, CortexDB, Couchbase, FoundationDB, InfinityDB, MarkLogic, OrientDB.

Jak widać, na przykładach takich, jak choćby SAP HANA, MongoDB, Oracle NoSQL DB czy IBM Domino są to rozwiązania całkiem dobrze znane, a przynajmniej rozpoznawane na rynku. Podejście to jak widać nie jest zatem obce nawet dla twórców najbardziej znanych i wyrafinowanych klasycznych rozwiązań RDBMS. Dlaczego?

Dostosowane do obsługi wielkich zbiorów danych

To wciąż wyzwanie nawet dla najnowszych, niezwykle wydajnych serwerów. Ogrom posiadanych danych – oraz rosnące zakusy do ich gromadzenia w jeszcze większych ilościach – to wyzwanie nie tylko dla sprzętu, ale też dla przetwarzających je aplikacji. W wielu wypadkach klasyczne podejście relacyjne jest po prostu niewystarczające. Zastosowanie NoSQL i uwolnienie się od tradycyjnych struktur danych pozwala na zbudowanie silników rozproszonych. Często – tak, jak wspomniana wcześniej SAP HANA – pracujących w pamięciach typu Flash zamiast na znacznie tańszych dyskach. Tym samym wzrasta dostępność takich rozwiązań, ponieważ o wiele łatwiej wybudować redundancję. Jeśli jeszcze do tego dodać technologię kontenerów – jak np. Docker w połączeniu z Mesosem – to może okazać się, że przygotowanie platformy bazodanowej dla programisty będzie ograniczało się do jednej, może dwóch linijek kodu. Natomiast wydajność, dostępność i skalowalność będą poniekąd w pakiecie.

Architektura baz danych NoSQL to synonim wydajności i dostępności. Generalnie w świecie baz danych mówimy o teorii CAP (Constistency, Availability, Partition Tollerance), która głosi, że systemy bazodanowe są w stanie spełnić jednocześnie tylko dwa z tych postulatów. Consistency, czyli spójność, mówi o tym, że wszystkie węzły systemu będą miały dokładnie te same, aktualne dane. Availability to dostępność, gwarantująca stałą możliwość dostępu do zapisu i odczytu danych, kiedy węzły systemu są dostępne. Partition Tollerance zaś to postulat mówiący o tym, że całość systemu działa, nawet jeśli nie ma komunikacji między niektórymi węzłami. Choć w oczywisty sposób dąży się do osiągnięcia wszystkich trzech elementów CAP, co w pewnym sensie powiodło się np. w Azure Storage, silniki NoSQL charakteryzują się kompromisem spójności na rzecz wydajności i dostępności.

Zastosowanie bazy danych NoSQL

Determinuje go m.in. wyżej opisana sytuacja. Jak można spodziewać się, że – jeśli mniej dbamy o spójność – będzie można zbudować na tego typu bazie system transakcyjny, np. taki, jaki przechowuje informację o transakcjach bankowych. Przy bardzo restrykcyjnych regulacjach prawnych spójność danych jest krytyczna, a tę są w stanie zapewnić jedynie systemy relacyjne. Wyobraźmy sobie sytuację, kiedy płacimy za zakupy kartą kredytową. W trakcie realizacji płatności system Visa, MasterCard czy inny zaczyna transakcję, weryfikuje dostępne środki, ale w trakcie autoryzacji następuje przerwa w łączności i nie można zaktualizować salda rachunku. W takiej sytuacji musimy bardzo precyzyjnie wiedzieć, jak dokończyć lub wycofać transakcję. W przeciwnym wypadku dochodzi do sytuacji, kiedy np. te same środki są pobierane dwa razy z naszego konta. Oczywiście to duże uproszczenie, ale idea pozostaje bez zmian.

Można sobie jednak wyobrazić – szczególnie dzisiaj w świecie IoT (Internet of Things) – sytuację, kiedy spójność nie musi być zapewniona jako wartość krytyczna. Możemy sobie wyobrazić scenariusz realizacji Predictive Maintenance, czyli np. przewidywania zużycia się konkretnych części w samochodzie, statku czy samolocie. Szereg czujników IoT wysyła ogromne ilości danych, których analiza ma pomóc odpowiedzieć na pytanie, kiedy najoptymalniej wymienić daną część, tak by wykorzystać ją maksymalnie unikając jednak przestoju wynikającego z niespodziewanej awarii. Jeśli jeden węzeł bazy danych będzie gromadził dane z ciężarówek z północy kraju nie będą miały pełnej spójności z danymi z południa. Podobnie, jeśli niektóre próbki nie będą zawierały danych kompletnych, co również może się zdarzyć. Szybkość i dostępność jaką gwarantują silniki NoSQL pozwolą na wykonanie analiz i optymalizacje wymiany poszczególnych części mimo potencjalnych niespójności. Warto też zauważyć, że w takim scenariuszu właściwie wyłącznie dodajemy nowe dane bez potrzeby modyfikacji istniejących, co z pewnością byłoby łatwiejsze w silniku RDBMS.

Skalowalność to również ważna cecha baz NoSQL osiągana dzięki kompromisowi spójności. Nie mając obowiązku zagwarantowania synchronizacji danych pomiędzy węzłami, możemy swobodnie dodawać ich więcej w przypadku wzrostu zapotrzebowania na zasoby. Systemy klasyczne, relacyjne skalujemy pionowo, czyli w przypadku zwiększenia zapotrzebowania na pamięć i moc obliczeniową, zwiększamy ją w pojedynczym węźle.

Od czego zacząć przygodę z NoSQL

Można zastanawiać się też wcześniej czy w ogóle zacząć? Coraz częściej odpowiedź na tak postawione pytanie jest twierdząca. Nawet jeśli nie jestem – i nie zamierzam zostać programistą, choć kto wie – znajomość podstaw NoSQL może być przydatna na co dzień. A wszystko dlatego, że dzisiejsze formaty przekazywania danych, takie jak XML czy JSON stały się tak popularne, że czasami ich znajomość może się przydać nawet przy obsłudze telefonu komórkowego, nie mówiąc już o systemie biznesowym. Od aplikacji Workflow, która pozwala automatyzować procesy w iOS po deklaracje podatkową którą na koniec kwietnia wysyłaliśmy w systemie e-Deklaracje, dane przechowywane są w obiektach XML lub podobnych.  Nie jeden raz zdarzy się, że będziemy taki plik edytowali choćby Notatnikiem, aby w najszybszy możliwy sposób wprowadzić kilka zmian. Jeżeli nauczymy się biegle posługiwać takimi formatami danych, zaznajomienie się z konkretnym silnikiem bazy danych będzie już tylko formalnością.

Jednym z bardziej przyjaznych środowisk do własnoręcznego dotknięcia technologii NoSQL wydaje się być coraz bardziej powszechne MongoDB. To wieloplatformowa baza danych posiadająca możliwość pracy na jednej maszynie czy systemie operacyjnym. Dlatego poza kliknięciem przycisku „downloads” na stronie producenta, kilka razy „next” i na końcu „finisz”, jedyne co będziemy musieli wykonać to obserwować pasek postępu. Następnie wystarczy uruchomić silnik bazy danych poleceniem „mongod”, w następnym kroku powłokę za pomocą polecenia „mongo”. Dalej posługujemy się poleceniami, które dość dobrze są opisane w wielu podręcznikach a nawet bezpłatnych kursach na Udemy czy YouTube. Dla przykładu kilka z nich przytoczyłem poniżej:

Show dbs – jak wygląda intuicyjnie tak rzeczywiście działa – polecenie pokazuje wszystkie bazy. Wynikiem tej operacji będzie wyświetlenie listy baz danych i ich pojemności.

Use <nazwa> – przełącza nas w kontekst bazy danych i od tego momentu to właśnie w niej będziemy wykonywać polecenia.

Show collections – pokazuje jakie w danej bazie danych istnieją kolekcje, czyli innymi słowy schematy danych, które wcześniej zostały do bazy przesłane.

Operacje na danych również nie należą do trudnych:

db.<nazwa>.insert({imię: “Michał”, age:25, budget:120000}) – polecenie doda obiekt o imieniu Michał, 25 lat i z budżetem 120 000 zł w bazie danych o podanej nazwie.

db.nazwa.find () – wyszuka dane, a wywołana bez parametrów zwróci wszystkie.

Na koniec ciekawa operacja działająca dla pozostałych poleceń… .pretty().

Dodanie tej metody na końcu polecenia spowoduje, że wynik wyświetlany w powłoce wygląda znacznie przyjaźniej niż tradycyjnie. Ponieważ artykuł ten nie ma być podręcznikiem obsługi MongoDB zachęcam do zainstalowania sobie środowiska i wraz z „czarodziejami danych” wypróbowania kilku poleceń na przykładowej bazie, aby przekonać się jakie to może być proste.

Podsumowując, bazy nierelacyjne NoSQL zyskują coraz większą popularność. Czy tak zostanie? Czy to skutek uboczny ery Big Data? Trudno wyrokować! Natomiast jedno jest pewne. Warto już dzisiaj pozyskać choć trochę wiedzy i doświadczenia w tym zakresie, ponieważ przejść obojętnie obok tego zagadnienia już się nie da.

Column: Accumulo, Cassandra, Druid, HBase, Vertica, SAP HANA

Document: Apache CouchDB, ArangoDB, Clusterpoint, Couchbase, DocumentDB, HyperDex, IBM Domino, MarkLogic, MongoDB, OrientDB, Qizx, RethinkDB

Key-value: Aerospike, ArangoDB, Couchbase, Dynamo, FairCom c-treeACE, FoundationDB, HyperDex, InfinityDB, MemcacheDB, MUMPS, Oracle NoSQL Database, OrientDB, Redis, Riak, Berkeley DB

Graph: AllegroGraph, ArangoDB, InfiniteGraph, Apache Giraph, MarkLogic, Neo4J, OrientDB, Virtuoso, Stardog

Multi-model: Alchemy Database, ArangoDB, CortexDB, Couchbase, FoundationDB, InfinityDB, MarkLogic, OrientDB