NoSQL

Wstęp

Od jakiegoś czasu, dużą uwagę poświęcam rozwiązaniom NoSQL. Nie jest to łatwy temat, ponieważ wymaga od programisty kompletnego przestawienia się z myślenia relacyjnego na agregacyjne. Do tego dochodzi mnóstwo „kruczków”, typów do wyboru i wreszcie dostawców rozwiązań. Pojawia się w głowie wiele pytań, tj. Jakim cudem moja baza danych może nie posiadać schematów? Tym i innym zagadnieniom przyjrzę się w dzisiejszym wpisie.

Co to jest NoSQL? (nie NOSQL!)

Przede wszystkim jest to odpowiedź na coraz szybszy rozrost baz danych. W pewnym momencie zauważono, że bardzo dobrym pomysłem jest przechowywanie bardzo dużej ilości danych, głównie w celach marketingowych. Bazując na konkretnych informacjach, różne firmy rozpoczęły swoje kampanie, wychodząc naprzeciw potrzeb użytkowników ich aplikacji.

Wszystko wyglądało pięknie do momentu, gdy ilość danych przechowywanych na serwerach wykorzystujących bazy relacyjne, zaczęła znacznie wychodzić ponad dotychczasowe limity (Big Data). Pojawiły się problemy z wydajnością zapytań – żeby odczytać niektóre dane, trzeba było czekać parę minut, a niekiedy dużo więcej. Trzeba było znaleźć inne rozwiązanie.

Głównym celem było rozłożenie dużej ilości danych pomiędzy wiele serwerów, czyli tzw. horizontal scaling oraz odpytywanie konkretnych serwerów w celu uzyskania konkretnych danych. Takie rozwiązanie mogłoby pozwolić na znaczne zwiększenie wydajności.

Sam termin NoSQL – w kontekście współczesnego znaczenia – powstał w 2009 roku – na twitterze została zorganizowana dyskusja na temat nazwy dla opisywanego rozwiązania. Oficjalnie, nazwa ta nie ma żadnego znaczenia. Wiele osób związanych ze światem programowania używała definicji Not Only SQL jednak nie jest ono prawdziwe – gdyby tak było, mogłoby również opisywać bazy relacyjne, a tego twórcy na pewno chcieli uniknąć. Poprzez taką definicję powszechnie nadużywany jest skrót NOSQL (z wielkim „O”), który również jest błędny.

Ponadto nazywanie czegoś NoSQL w znaczeniu „nie tylko SQL” nie jest poprawne, ponieważ wtedy także Oracle i Postgres pasowałyby do tej definicji, udowodnilibyśmy, że białe równa się czarne, i wszyscy zostalibyśmy przejechani na przejściu dla pieszych. – NoSQL. Kompendium wiedzy, Pramod J. Sadalage, Martin Fowler

Główną siłą NoSQL jest przede wszystkim skalowalność, brak modelu relacyjnego – co nie zawsze jest dobre oraz brak schematów dla danych.

Skalowalność

Istnieją dwie główne skalowalności:

  • pionowa (eng. vertical scaling)
  • pozioma (eng. horizontal scaling)

Pionowa

Polegająca na coraz droższym rozbudowywaniu jednego serwera w celu zwiększenia jego wydajności, co i tak w pewnym momencie najprawdopodobniej doprowadzi do technologicznej ściany i będziemy mieć duży problem.

Pozioma, zwana również shardingiem:

Polegająca na dywersyfikacji danych, w celu przechowywania ich na wielu serwerach. Takie rozwiązanie jest dużo tańsze niż skalowanie pionowe. Każdy z serwerów może mieć słabe parametry, ponieważ to do nas należy decyzja, jak wiele danych chcemy na nim przechowywać. W momencie pojawienia się nowych encji w naszej bazie, możemy zdecydować, że będą one przechowywane na nowym, dodatkowym serwerze.

Kolejną zaletą jest to, że w momencie, gdy serwer odpowiadający np. za produkty w naszym systemie przestanie działać, reszta serwerów będzie nadal umożliwiała korzystanie z aplikacji. I tutaj możliwe są 2 scenariusze:

  • dane dot. produktów trzymamy na kilku serwerach, przez co aplikacja może nadal wyświetlać listę niektórych produktów
  • dane dot. produktów trzymamy na jednym serwerze, przez co aplikacja nie może wyświetlać listy produktów, ale za to umożliwia operacje związane z innymi encjami, jak np. zarządzanie użytkownikami, czy koszykiem

To, który scenariusz wybierzemy zależy od nas samych, specyfiki oraz wymagań naszego systemu.

Typy NoSQL

Wyróżniamy 4 podstawowe typy. Każdy z nich jest przeznaczony do konkretnych rozwiązań, aczkolwiek mogą być używane zamiennie, jeżeli lubimy komplikować sobie życie.

Dokument (eng. Document)

  • Kolekcja jest odpowiednikiem tabeli
  • Dokument jest odpowiednikiem wiersza
  • Można aktualizować dane częściowo
  • Wiele dokumentów może być przedstawionych za pomocą jednej agregacji
  • Transakcje – brak wsparcia dla kompletnego ACID (eng. Atomicity, Consistency, Isolation, Durability)
  • Najbardziej popularne rozwiązanie
  • Przykładowi dostawcy: MongoDb, RavenDb, CouchDb

Klucz – wartość (eng. Key – value)

  • Wiadro jest odpowiednikiem tabeli
  • Klucz – wartość jest odpowiednikiem wiersza
  • Najprostsze w użyciu bazy NoSQL (z pkt. API)
  • Wiadro zawiera wiele obiektów klucz – wartość
  • Każdą wartość można uzyskać za pomocą konkretnego klucza
  • Bazy nie interesuje wartość, jej odczyt odbywa się z poziomu aplikacji
  • Wartość jest usuwana za pomocą klucza
  • Bardzo wydajne ze względu na wykorzystanie klucza głównego
  • Transakcje – brak wsparcia dla kompletnego ACID (eng. Atomicity, Consistency, Isolation, Durability)
  • Przykładowi dostawcy: BerkeleyDb, RiakDb

Rodzina kolumn (eng. Column family)

  • Rodzina kolumn jest odpowiednikiem tabeli
  • Wiersz jest odpowiednikiem wiersza
  • Dane są przechowywane w rodzinach kolumn w postaci wierszy, do których przypisany jest konkretny klucz
  • Na jedną kolumnę składa się para nazwa – wartość, w której kluczem jest nazwa
  • Pobieramy dane, które są ze sobą w jakiś sposób powiązane – jedna rodzina kolumn to samochody, druga to silniki i zazwyczaj chcemy pobrać je razem. Trzecia, niepowiązana rodzina to lista fabryk i jej pobierać w obrębie wyżej zdefiniowanej rodziny nie chcemy
  • Transakcje – brak wsparcia dla kompletnego ACID (eng. Atomicity, Consistency, Isolation, Durability)
  • Przykładowi dostawcy: Cassandra

Graf (eng. Graph)

  • Rozwiązanie używane głównie w aplikacjach social media, w których stawia się na wiele relacji pomiędzy użytkownikami, grupami itp. oraz bazujących na algorytmach do wyznaczania tras
  • Pobierając dane np. jednego użykownika, znamy jego powiązania z innymi użytkownikami oraz ich potencjalne powiązania
  • Transakcje -jako jedyny typ wspiera kompletny ACID (eng. Atomicity, Consistency, Isolation, Durability)
  • Przykładowi dostawcy: FlockDb, OrientDb

Brak schematów dla danych – wada czy zaleta?

W przeciwieństwie do relacyjnych baz danych, w przypadku NoSQL nie definiujemy żadnych schematów dla przechowywanych danych. Tyle teorii. Jak to wygląda w praktyce?

Powiedzmy, że mamy zdefiniowane 2 różne obiekty tego samego typu – Pojazd. Samochód oraz Samolot. Samolot posiada skrzydła, ogon, wyjścia awaryjne, ster. Samochód ma np. kierownicę. Nie definiując schematu, możemy obydwa obiekty przechowywać w obrębie jednego dokumentu. I będą one traktowane jako Pojazd. Bez względu na to co zawierają. O to musi się już martwić aplikacja.

Zaletą takiego rozwiązania jest na pewno niski stopień skomplikowania struktur bazodanowych, co przekłada się na zwiększenie wydajności zespołu pracującego nad rozwiązaniem w obszarze bazy danych. Czy przypadkiem nie jest tak, że większość nas programistów ma w głębokim poważaniu to, co dzieje się w bazie danych? 😉

Niestety taka zaleta generuje również wiele problemów, a podstawowym jest to, że ktoś musi nad taką bazą czuwać, żeby nie okazało się, że w dokumentach przechowujących obiekty typu Pojazd, przechowujemy po jakimś czasie np. użytkowników 🙂

Wadą takiego rozwiązania jest na pewno problem przy bazach integracyjnych – wyobraźmy sobie, że z jednej bazy korzysta kilka aplikacji. Dane nie mają schematów. Deweloperzy jednej z aplikacji dodali kilka właściwości, inni kolejne itp. nie informując innych o zmianach. Prędzej, czy później wszystko legnie w gruzach. Dlatego NoSQL w takich przypadkach nie jest zalecany. Oczywiście, istnieje możliwość, że będziemy w posiadaniu zespołu do monitorowania takich zmian, ale po co sobie komplikować życie?

Czy relacyjne bazy danych umierają?

Nie. Mają i w najbliższych latach będą się miały bardzo dobrze. Dlaczego? Nadal w wielu przypadkach jest to rozwiązanie lepsze od NoSQL, a najlepszym przykładem są integracyjne bazy danych, o których wspominałem w poprzednim akapicie. Kolejnymi argumentami przeciwko jest to, że większość obecnych programistów wychowała się na relacyjnych bazach danych, większość aplikacji biznesowych nadal na nich operuje i nadal wiele potencjalnych rozwiązań będzie na nich bazować.

Podsumowanie

  • Eleganckie operowanie na Big Data
  • Rozwiązanie zaprojektowane do równoległego przetwarzania danych
  • Brak schematów dla danych
  • W zdecydowanej większości brak wsparcia dla transakcji
  • Mniejsze koszty niż w przypadku baz relacyjnych dla Big Data
  • Niepopularne rozwiązanie dla baz integracyjnych – zwłaszcza ze względu na brak schematów dla danych

Zostaw komentarz

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Log Out / Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Log Out / Zmień )

Facebook photo

Komentujesz korzystając z konta Facebook. Log Out / Zmień )

Google+ photo

Komentujesz korzystając z konta Google+. Log Out / Zmień )

Connecting to %s