Bazy SQL vs NoSQL

Ostatnio dużo pracuję z bazą nosqlową MongoDb i to sprawiło, że postanowiłem napisać artykuł o różnicach między bazami SQL oraz NoSQL. Artykuł jest bardzo aktualny, nie tylko ze względu na rosnącą popularność tych baz, ale także choćby w kontekście naszej Mapy umiejętności programisty Java [Droga do kariery]. Zobaczmy więc, czym charakteryzują się bazy SQL i NoSQL.

SQL vs NoSQL

Przyjrzyjmy się najważniejszym cechom obu rodzajów baz:
SQL NoSQL
1. Określane są jako RDBMS, czyli relacyjne bazy danych Określane są jako nierelacyjne bazy danych
2. Schema definiowana na sztywno przed użyciem
   (struktura statyczna)
Brak predefiniowanej schemy
(struktura jest dynamiczna)
3. Struktura tabelaryczna Różnorodność struktur - mogą być oparte na
dokumentach, bazach grafów, parach klucz-wartość,
rekordach z kolumnami (tzw. szerokokolumnowe)
4. Dedykowane do przechowywania
   uporządkowanych danych
Dedykowane do przechowywania ciągle
zmieniających się, nieuporządkowanych danych
5. Są skalowane wertykalnie
   (poprzez zwiększanie zasobów danego serwera)
Są skalowane horyzontalnie (poprzez dodawanie
kolejnych serwerów)

1. Relacyjność

W przypadku tradycyjnych baz danych jednym z najważniejszych czynników jest określanie relacji pomiędzy rekordami znajdującymi się w różnych tabelach. Z góry decydujemy, że rekordy z jednej tabeli będą wchodziły na przykład w relację jeden do jednego, czy jeden do wiele z rekordami innej tabeli. W przypadku baz nierelacyjnych nie projektujemy takich zagadnień. Mamy tutaj dużą elastyczność w przygotowywaniu obiektów w trakcie "życia" systemu. Możemy je łączyć dynamicznie, w dowolny sposób.

2. Schema

Relacyjne bazy danych posiadają tak zwaną schemę, czyli ściśle określoną strukturę przygotowywaną jeszcze przed zasileniem bazy danymi. W trakcie działania systemu możemy aktualizować tę strukturę, lecz bywa to problematyczne. Na przykład dodanie pola do tabeli modyfikuje każdy wiersz, mimo że potrzebujemy go tylko dla nowo dodawanych rekordów (ze względu na pojawienie się specyficznych wymagań biznesowych). W przypadku baz nosqlowych dodajemy pole tylko do tych obiektów, które tego potrzebują, a inne obiekty nie muszą nic o tym wiedzieć.

3. Struktura

Struktura bazy sqlowej oparta jest o tabele i klucze. Tabele mają rekordy, które mogą uczestniczyć w relacjach (było o tym wyżej). W przypadku baz nosql struktura jest bardzo różnorodna i zależy od tego, jakiej bazy używamy. Generalnie struktury oparte są na:
  • Dokumentach (Document Database) - bardzo często stosowane podejście. Tak działa na przykład MongoDB. Dokumenty są trochę analogią rekordów i mogą być układane w kolekcje (coś podobnego do tabel). Dokumenty są przechowywane najczęściej w formacie JSON (ale też XML czy BSON), dzięki czemu w łatwy sposób mogą przechowywać pola z wartościami. Dokumenty znajdujące się w jednej kolekcji nie muszą zawierać tych samych pól, a nowe pola możemy dodawać do dowolnego dokumentu w razie potrzeby. To naprawdę duża wygoda.
    Widok rekordu z tabeli bazy SQL
    Eclipse - Nowy projekt
    Widok dokumentu z kolekcji bazy NoSQL (format JSON)
    Eclipse - Nowy projekt
    Przykładowe bazy NoSQL: MongoDB, CouchDB, Terrastore
  • Grafach (Graph Database) - dane są przechowywane w postaci grafów. Poszczególne elementy nazywane są węzłami (nodami), a połączenia krawędziami (edge'ami). W nodach przechowujemy podmioty, a krawędzie opisują operacje, jakie są przez nich (na nich) wykonywane. Poniżej wynik przykładowego zapytania z bazy filmowej. Widzimy trójkę aktorów i filmy w jakich grali:
    Eclipse - Nowy projekt
    Przykładowe bazy NoSQL: Neo4j, FlockDB
  • Parach klucz-wartość (Key-Value Database) - Bazują na prostym mechaniźmie przechowywania klucza i wartości dla tego klucza. Wartości mogą być proste - takie jak zwykłe liczby czy słowa, ale i bardziej skomplikowane - w postaci złożonych obiektów. Nic nie stoi na przeszkodzie, aby obiekty miały te same atrybuty dla każdego klucza, jednak dosyć często stosowanym podejściem jest tworzenie różnych atrybutów dla różnych kluczy.
    Eclipse - Nowy projekt
    Pobranie wartości odbywa się poprzez odwołanie się do klucza.

    Taka baza może być użyta jako baza dodatkowa na przykład w celu przechowywania danych konfiguracyjnych dla naszych usług. Z powodzeniem sprawdza się też jako cache dla najczęściej używanych danych. Czasem w tego typu bazach przechowujemy dane w sposób hierarchiczny (tak jak na powyższym obrazku - w jednym wierszu mamy Movie, a potem w kolejnych wierszach powiązane dane - Movie : Director, Movie : Scenarist).

    Klucz powinien być unikalny i również może być prosty lub złożony. Wartości w kolejnych wierszach mogą być przechowywane w postaci kolekcji różnych atrybutów (tak jak na obrazku - dla reżysera filmu mamy atrybuty: title, genre, year, a dla reżysera firstname, lastname).
    Przykładowe bazy NoSQL: Amazon DynamoDB, Redis, Oracle NoSQL Database, InfinityDB
  • Kolumnach (Wide Column Stores) - W tym przypadku dane przechowujemy w rekordach z dowolnie określanymi kolumnami dla każdego z nich. Każdy wiersz ma więc swoją przestrzeń do przechowywania kolumn, które możemy dynamicznie aktualizować. Na swój sposób struktura przypomina trochę Key-Value, niemniej tutaj mówimy o faktycznym udziale kolumn, a nie o atrybutach obiektu.

    Pojawia się tutaj pojęcie Keyspace, co jest odpowiednikiem bazy danych w systemach RDBMS. Kolejnym pojęciem jest Column Family, co w pewien sposób przypomina tabelę bazodanową. Na poniższym obrazku widzimy pojedyńczy wiersz z jedną rodziną kolumn, a na drugim kilka rodzin kolumn, które dodatkowo możemy pogrupować w super rodziny:
    Eclipse - Nowy projekt
    Zobaczmy zatem, jak mogłyby wyglądać rodziny kolumn i super kolumn dla danych filmowych:
    Eclipse - Nowy projekt
    Kolorem pomarańczowym oznaczyliśmy rodziny kolumn. Każda z nich ma nadrzędna super kolumnę i w ten sposób tworzą się super rodziny kolumn (movie, director, scenarist). W bazie typu RDBMS utworzylibyśmy trzy tabele i dane przechowywalibyśmy w wierszach. W przypadku Wide Column Stores dane przechowujemy de facto w kolumnach. Kolumny mogą się różnić między wierszami.
    Przykładowe bazy NoSQL: Apache Cassandra, Apache HBase, Google Bigtable

4. Przeznaczenie

Bazy NoSQL od kilku lat mocno zyskują na popularności. Wynika to z rozwoju systemów przetwarzających ogromne ilości nieustrukturyzowanych danych. Firmy takie jak Facebook, Google, czy Twitter pracują z danymi obsługiwanymi często w czasie rzeczywistym, o niekoniecznie skomplikowanej strukturze powiązań, ale za to niezwykle wymagającymi wydajnościowo.

Obsługa postów, tweetów, danych lokalizacyjnych, czy też wyszukiwań informacji na niespotykanym do tej pory poziomie wymaga przede wszystkim baz, które są szybkie i elastyczne, a takimi są właśnie bazy nosqlowe. Szczególnie ważne jest to, że dodawanie kolejnych pól nie wymaga przebudowy istniejących struktur, ani też nie dotyka zapisanych wcześniej danych. W ten sposób można bardzo szybko rozwijać systemy zgodne z wymaganiami nieustannie galopującego rynku nowych technologii.

Czy to zatem zmierzch tradycyjnych baz danych? Wydaje się, że nie. W dalszym ciągu istnieje spory popyt na budowę systemów, które trzymają się sztywno wytyczonych ram projektowych, przez co są bardziej odporne na błędy rozwojowe. Tworzenie relacji bazodanowych wciąż ma sens, gdy istnieje silna potrzeba budowy stabilnych struktur i gdzie w ciągu 1 sekundy nie dochodzi do przetwarzania ogromnych ilości danych. Jak ogromnych? Wystarczy wspomnieć o liczbie wyszukiwań, jakie są wykonywane za pomocą Google'a. Jest ich 40 tysięcy każdej sekundy...

5. Skalowanie

W przypadku relacyjnych baz danych skalowanie odbywa się w sposób wertykalny. Polega ono zwykle na dokładaniu kolejnych zasobów do serwera bazodanowego, przez co jego moc obliczeniowa, jak i miejsce na dane rosną. W przypadku baz nosqlowych mówimy o skalowaniu horyzontalnym, które działa tak, że gdy tylko potrzebujemy kolejnych zasobów, zwiększamy liczbę maszyn obsługujących dany proces. W takim podejściu pomaga organizowanie systemów w ramach architektury mikroserwisowej. Więcej mikroserwisów jest w stanie przetwarzać więcej danych w krótkiej jednostce czasu.

Autor: Jarek Klimas
Data: 09 lutego 2020
Labele:Backend, Poziom średniozaawansowany, Java Linki:
https://www.mongodb.com/scale/nosql-vs-relational-databases
https://database.guide/what-is-a-column-store-database
https://neo4j.com/developer/example-data/
Masz swoje przemyślenia na temat artykułu? Podziel się nimi!
Masz pytanie odnośnie zagadnienia omawianego w artykule?
Coś, co napisaliśmy, nie zaspokoiło Twojego głodu wiedzy?
Daj nam znać co myślisz i skomentuj artykuł na facebooku!

Stale się rozwijamy, a więc bądź na bieżąco!
Na ten adres będziemy przesyłać informacje o ważniejszych aktualizacjach, a także o nowych materiałach pojawiających się na stronie.
Polub nas na Facebooku:
Nasi partnerzy: stackshare
Javappa to również profesjonalne usługi programistyczne oparte o technologie JAVA. Jeśli chesz nawiązać z nami kontakt w celu uzyskania doradztwa bądź stworzenia aplikacji webowej powinieneś poznać nasze doświadczenia.
Kliknij O nas .


Pozycjonowanie stron: Grupa TENSE