Jaką bazę danych wybrać? Jakie są typy baz danych? – GADy

Jaką bazę danych wybrać? Jakie są typy baz danych?

Wybór technologii używanych do tworzenia baz danych jest bez wątpienia bardzo istotną kwestią, rzutuje on na efektywność oraz konkurencyjność współczesnych przedsiębiorstw.

Mniejsze firmy ze względu na brak środków finansowych, brak znajomości tematu, czy też charakter działalności, często nie posiadają bazy danych w innej formie niż „tabelki w Excelu”. Jednak wraz z rozwojem przedsiębiorstwa firma, aby nie zostać w tyle za swoją konkurencją, często decyduje się na zatrudnienie specjalistów którzy zajmą się wprowadzeniem bardziej zaawansowanych systemów do przechowywania oraz przetwarzania danych. Wówczas bardzo istotną kwestią, która już zawsze będzie rzutowała na działanie firmy, jest dobór technologii bazodanowej. Technologia ta powinna być dostosowana do charakteru prowadzonej działalności, ponieważ dobór modelu bazy ma znaczący wpływ na architekturę serwera, objętość bazy, łatwość dostępu do informacji oraz oczekiwane kwalifikacje zatrudnianych w przyszłości specjalistów.

Skoro każda większa firma na swojej drodze rozwoju musiała przejść przez proces decyzyjny, który ostatecznie doprowadził do wyboru konkretnego rozwiązania bazodanowego, to jakie opcje właściwie rozpatrywano? Co oferuje nam współczesny rynek?

Dzisiejsza oferta technologiczna jest naprawdę spora. Współcześnie bazy danych możemy podzielić na: relacyjne , obiektowe , relacyjno-obiektowe , strumieniowe , temporalne oraz nierelacyjne . Jednak kilka z tych podtypów jest używanych wyjątkowo często w porównaniu do innych, mowa tutaj o bazach relacyjnych, relacyjno-obiektowych oraz nierelacyjnych.

Jeżeli wyboru technologii bazodanowej dokonywalibyśmy jeszcze w XX wieku, wybór byłby bardzo prosty ,– baza relacyjna obsługiwana przez język SQL, opracowany przez IBM w 1978 roku, a kilka lat później zatwierdzony przez ANSI oraz ISO. System ten zdeklasował swoich poprzedników: system hierarchiczny oraz sieciowy.

Technologia bazodanowa wówczas dopiero się rozwijała, z czasem do gry dołączył mocny konkurent, a mianowicie bazy oparte na modelu relacyjno-obiektowym, które stały się kolejnym krokiem ewolucji baz relacyjnych. Ich powstanie zawdzięczamy firmom, które przeznaczały spore sumy na rozwój systemu relacyjnego. Szybko okazało się, że najlepszym krokiem jest podążanie w kierunku baz obiektowych, ale całkowite przejście z systemu relacyjnego na obiektowy było zbyt kosztowne, więc opracowano rozwiązanie: bazy relacyjno-obiektowe, zdecydowanie lepiej dostosowane do obsługi aplikacji oraz procedur definiowanych w różnych językach programowania.

Jednak, mniej więcej w erze największego rozkwitu dotcomów (przełom XX i XXI wieku), w odpowiedzi na wymagania gigantów internetowych postanowiono odkurzyć oraz ulepszyć technologię baz nierelacyjnych (NoSQL-owych), odłożoną na bok podczas dominacji baz relacyjnych i relacyjno-obiektowych. Większe zainteresowanie programistów bazami NoSQL zawdzięczamy głównie firmie Google, która podczas budowy przeglądarki doszła do nieprzekraczalnej bariery, zbyt długiego czasu oczekiwania na odpowiedź serwera (słaba, pionowa skalowalność). W obliczu tego wyzwania Google postanowiło oprzeć swoją przeglądarkę na nierelacyjnej bazie danych, która zapewniała dużo szybsze wyniki oraz równoległe przetwarzanie dużych ilości danych. Po opublikowaniu przez Google opisu używanych przez nich technologii, nastąpił szybki rozwój baz nierelacyjnych.

Inni giganci postanowili rozwijać modele nierelacyjne w kierunku, który pozwoliłby na optymalne składowanie oraz przetwarzanie danych. Ponieważ owe firmy prowadziły działalności różnego typu, rozwój modelu nierelacyjnego doprowadził do wyodrębnienia czterech głównych podtypów: Klucz-Wartość , Dokument , Rodzina kolumn oraz Graf . Każdy z tych podtypów stał się specjalistą w swojej dziedzinie.

W celu wybrania konkretnego rozwiązania bazodanowego postarajmy się wcielić w jedną z firm, która w obliczu ogromu przetwarzanych i magazynowanych danych postanawia zatrudnić zewnętrznych specjalistów, zajmujących się projektowaniem oraz administracją baz danych.

Powstają zatem następujące pytania. O co powinniśmy zapytać? Na co zwrócić uwagę? Jakie powinniśmy mieć oczekiwania?

Na początku zastanówmy się czy nasza baza powinna być SQL-owa, czy może NoSQL-owa. W tym miejscu wynajęci przez nas eksperci powinni wziąć pod uwagę, jakie ilości danych przetwarza nasza firma, kto ma do nich dostęp, jak często dane są modyfikowane oraz jaki mamy budżet.

Zacznijmy może od ostatniej kwestii, jeżeli firma nie może sobie pozwolić na duże wydatki, postawi raczej na rozwiązanie SQL-owe, które ze względu na swoją prostotę będzie wymagało mniejszych nakładów pracy potrzebnych do jego wprowadzenia w firmie oraz do administrowania, ze względu na większą ilość specjalistów w tej dziedzinie.

Jeżeli nasz budżet jest naprawdę niewielki to z rozwiązań SQL-owych wybierzemy raczej bazę relacyjną, która na początku naszej działalności gospodarczej musi nam wystarczyć.

Natomiast gdy nasze przedsiębiorstwo już się rozwinie, będziemy mogli w miarę niskim kosztem przejść na bazę relacyjno-obiektową, pozwalającą nam na większą swobodę przy tworzeniu nowych tabeli/pól, a także da nam możliwość składowania procedur w innych językach, takich jak: Java, Python, Perl, Ruby, C, C++.

Jednak co w przypadku, gdy nasza firma byłaby skłonna zainwestować trochę większą kwotę? Przecież bazy relacyjne, relacyjno-obiektowe nie nadają się do używania przez większą liczbę użytkowników (mowa tutaj o sytuacji, w której użytkownikami bazy są klienci lub osoby z poza firmy). Co w przypadku, gdy nasza firma prowadziłaby serwis społecznościowy lub udostępniałaby inną aplikacją internetową w której, użytkowników próbujących uzyskać w tym samym czasie odpowiedź od serwera jest bardzo dużo?

Wówczas powinniśmy zastanowić się nad wyborem jednego z systemów nierelacyjnych. Serwis społecznościowy „Nasza klasa” na początku lat 2000 postawił na rozwiązanie klucz-wartość, ale dobrym wyborem byłby też model bazy nierelacyjnej typu dokument, który pod względem struktury jest idealny do przechowywania danych użytkowników. W końcu, w bazie relacyjnej musielibyśmy utworzyć pola typu: praca, związek, uczelnia itp., niezależnie od tego czy użytkownik poda owe informacje, w tabeli i tak musi widnieć pole z wartością przypisaną do tego pytania, niezależnie czy odpowiedź to tekst czy NULL (brak). W przypadku bazy typu „dokument” nie jesteśmy zobligowani do przechowywania wartości NULL, po prostu w konkretnym dokumencie nie mamy wówczas ani klucza, ani wartości przypisanej do danego pytania.

Jeżeli nasza firma zajmowałaby się analityką dużych zbiorów danych, powinniśmy postawić na bazy nierelacyjne typu rodzina kolumn. Bazy tego typu świetnie nadają się do szybkiego uzyskiwania wartości danej kolumny. Nie jesteśmy w nich skazani na przeglądanie danych wiersz po wierszu, a później na wybór jedynie informacji z konkretnych kolumn, bowiem w bazach rodzina kolumn od razu uzyskujemy pożądany wynik. Niestety, nic nie pozostaje bez konsekwencji, kosztem takiego rozwiązania pozostaje długi czas zapisu danych, który wymaga wielu operacji na dysku.

Wymieniać zastosowania poszczególnych systemów bazodanowych można by bez końca, ale zastanówmy się czy jest możliwe podanie algorytmu który pozwoli nam na wybór konkretnej technologii?

Niestety wybór technologii bazodanowej nie jest tak oczywisty i zero-jedynkowy. W dzisiejszych czasach firmy często decydują się na posiadanie kilku baz danych:

Social media – baza typu graf (informacje o siatce znajomych) w połączeniu z bazą relacyjno-obiektową lub bazą typu dokument. Placówki badawcze – baza nierelacyjna typu rodzina kolumn (na potrzeby analityki ogromnych zbiorów danych) + Baza typu dokument (szybki zapis informacji). Banki – bazy relacyjno-obiektowe + bazy typu dokument (do obsługiwania wniosków (w ramach filozofii paperless) oraz na potrzeby aplikacji).

Powyższy tekst jest tylko wstępem do bardzo złożonego tematu, a decyzję o wprowadzeniu konkretnego rozwiązania bazodanowego podejmuje często sztab ekspertów z wieloletnim doświadczeniem. Tym niemniej, mam nadzieję, że udało mi się chociaż trochę zaciekawić część czytelników tematem doboru technologii bazodanowej.

Zainteresowanych poszczególnymi typami baz danych, ich zastosowaniami, technikaliami i historią, zapraszam do zapoznania się z cyklem artykułów „Cazy danych, jak je zrozumieć?” . Gdzie każdy artykuł będzie skupiał się na poszczególnym typie technologii bazodanowej.

Adam Kraj

Grafika tytułowa: luis gomes z Pexels

Źródła

Jaką bazę danych wybrać?

Podczas fazy planowania projektu programistycznego w pewnym momencie stajemy przed wyborem bazy danych, z której korzystać będzie nasza aplikacja. Znaleźć można wiele darmowych rozwiązań takich jak MySQL, PostgreSQL, MS SQL Server, SQLite czy też zdobywające coraz większą popularność bazy danych typu NoSQL. Która z nich jest najlepsza i dlaczego?

Jak w przypadku większości technologicznych wyborów nie da się tutaj jednoznacznie wskazać, które rozwiązanie jest tym lepszym. Postaram się przybliżyć Wam najpopularniejsze rozwiązania bazodanowe wskazując ich mocne i słabe strony, aby ułatwić Wam wybór właściwej bazy do projektu.

Chciałbym skupić się tutaj przede wszystkim na silnikach MySQL, SQLite i PostgreSQL oraz bazach NoSQL, gdyż z nimi miałem najwięcej wspólnego. Na przykładzie tych baz najłatwiej również pokazać różnice pomiędzy poszczególnymi rozwiązaniami.

MySQL

Jest to zdecydowanie najpopularniejszy silnik bazodanowy rozwijany jako open source. Rozwojem MySQL zajmuje się obecnie firma Oracle. Na czym polega fenomen tego silnika oraz skąd wzięła się jego popularność?

Przez wiele lat najpopularniejszym językiem wykorzystywanym przy tworzeniu aplikacji webowych był PHP, dla którego domyślną bazą danych jest właśnie MySQL. Czynnikiem, który również miał wpływ na szybki rozwój oraz uwielbienie różnych społeczności programistyczych, był również bezproblemowy proces instalacji i łatwość korzystania z omawianego rozwiązania.

Prawdopodobnie największymi zaletami MySQL są jednak skalowalność i szybkość. Z rozwiązania tego korzystają giganty technologicze jak na przykład YouTube, Spotify, Facebook, Twitter czy NASA. Co prawda nie jest to technologia występująca natywnie w chmurze, jednak na korzystanie z tej bazy jako rozwiązania chmurowego pozwala usługa DBaaS (Database-as-a-service) Cloud SQL oferowana przez Google.

Consistency

Bazy danych działające na silniku MySQL zapewniają Immediate Consistency. Na czym to polega? Gdy korzystamy z replik bazy danych silnik bazodanowy musi obsłużyć żądanie zapisu danych tak, aby nowe dane dotarły do każdej repliki. Może się zdarzyć, że w trakcie aktualizowania danych w bazie wysłane zostanie kolejne żądanie, tym razem dostępu do danych.

W takiej sytuacji silnik bazodanowy może najpierw poczekać, aż wszystkie repliki będą aktualne, a dopiero później udostępnić dane zapewniając ich aktualność. Taka strategia nosi nazwę Immediate/Strong Consistency.

Inną stosowaną strategią jest Eventual Consistency. W tym przypadku baza odpowie na żądanie dostarczenia danych od razu zmniejszając opóźnienie do minimum, ryzkując, że dane mogą być nieaktualne.

Wybierając bazę danych warto zwrócić uwagę również na dodatkowe narzędzia powiązane z danym silnikiem. Dzięki ogromnej społeczności fanów tego rozwiązania, MySQL posiada mnóstwo narzędzi stworzonych przez różne grupy programistycznych wolontariuszy. Część z nich trzeba pobrać oddzielnie, jednak znajdziemy też kilka wbudowanych narzędzi, na przykład pozwalających na korzystanie z interfejsów graficznych. MySQL posiada również funkcje zwiększające bezpieczeństwo naszych baz danych.

Cechą MySQL, którą wielu uważa za wadę, jest brak implementacji pełnego standardu SQL. Silnik rozwijany przez firmę Oracle nie radzi sobie najlepiej z operacji wykonywanymi równolegle. Mimo sporej liczby typów danych i funkcji bazy, w przypadku niektórych projektów mogą być one niewystarczające. W takich sytuacjach do gry wchodzi PostgreSQL.

PostgreSQL

Omawiany silnik bazodanowy jest dużo bardziej zaawansowanym rozwiązaniem niż opisany wcześniej MySQL. Co za tym idzie, mniejsza jest również jego popularność, jednak ze względu na ogromne możliwości, technologia ta znajduje również ogromną rzeszę fanów, którzy napędzają jej rozwój tworząc dodatkowe narzędzia i biblioteki. Jest to rozwiązanie typu open source. Twórcy bazy zdecydowali się na implementacje pełnego standardu ANSI/ISO SQL.

Ogromną zaletą PostgreSQL w porównaniu z innymi rozwiązaniami jest jej “rozszerzalność”. Pozwala ona na tworzenie własnych typów danych czy też dodatkowych funkcji, do pisania których można wykorzystywać składnie innych języków niż SQL.

Porównując omawianą bazę danych do innych cechą szczególnie rzucającą się w oczy jest liczba zdefiniowanych typów danych, jakie możemy przechowywać w bazie. Oprócz podstawowych typów danych, jakie znajdziemy w każdym innym rozwiązaniu bazodanowym w bazach PostgreSQL przechowywać możemy tablice, dokumenty JSON lub XML czy nawet figury geometryczne jak na przykład odcinek lub okrąg. Jeżeli dodamy do tego już wcześniej wspomnianą możliwość tworzenia własnych typów, możliwości stają się niemal nieograniczone.

PostgreSQL świetnie radzi sobie z operacjami równoległymi. W przypadku wielu aplikacji właśnie ta właściwość omawianej bazy jest najbardziej doceniana. Omawiany system posiada również wiele mechanizmów bezpieczeństwa danych.

Inną ważną funkcją Postgres’a, o której chciałbym wspomnieć jest wyszukiwanie tekstu (Full Text Search). W każdym rozwiązaniu bazodanowym znajdziemy funkcję typu LIKE, która pozwala na wyszukiwanie wzorców tekstowych, jednak omawiana baza postawiła na poprawienie tego mechanizmu. Indeksowanie tekstu oraz implementacja funkcji lingwistycznych pozwalają na szybsze i dokładniejsze wyszukiwanie tekstu, szczególnie dobrze sprawdzające się w przypadku języka angielskiego.

Oczywiście nie jest to rozwiązanie idealne dla każdej aplikacji. Mnogość dostępnych funkcji w przypadku mniejszych aplikacji może niepotrzebnie skomplikować, a nawet spowonlić wiele procesów, szczególnie tych wymagających szybkiego odczytu danych.

Coraz częściej znaleźć można programistyczne ogłoszenia o pracę, w których wymagana jest znajomość PostgreSQL, co jest kolejnym powodem na zainteresowania się tym rozwiązaniem :)

SQLite

SQLite jest jednym z prostszych rozwiązań bazodanowych. Jest to system oparty na plikach – każda tworzona baza zapisywana jest w katalogu aplikacji jako plik z rozszerzeniem .db, w którym przechowywane są dane. Zapewnia to aplikacjom szybkość korzystania z bazy (zależną od szybkości odczytu/zapisu na dysku) oraz łatwość przenoszenia bazy.

SQLite posiada podstawowe typy danych, które w wielu przypadkach będą wystarczające. Jest to więc idealna baza danych do wykorzystywania na początku tworzenia aplikacji jak i przy testowaniu. Biblioteka pozwalająca na korzystanie z SQLite wbudowana w Pythona pozwala na tworzenie bazy danych w pamięci RAM, co znacząco zwiększa szybkość operacji i uprzyjemnia proces testowania ;)

Idealnie sprawdza się również w przypadku aplikacji niewymagających obsługi wielu użytkowników, jak na przykład prostych aplikacji mobilnych czy desktopowych.

Bazy danych NoSQL

Nazwa NoSQL odnosi się do grupy nierelacyjnych baz danych, na którą składa się kilka rodzajów baz:

Key-value – najprostszy typ bazy NoSQL, sposób przechowywania danych przypomina programistyczny słownik/mapę. Jedną z tego typu baz jest Redis

– najprostszy typ bazy NoSQL, sposób przechowywania danych przypomina programistyczny słownik/mapę. Jedną z tego typu baz jest Redis Document – typ bazy danych pozwalających na przechowywanie dokumentów takich jak na przykład JSON czy XML. Bazę tego typu oferuje między innymi MongoDB

– typ bazy danych pozwalających na przechowywanie dokumentów takich jak na przykład JSON czy XML. Bazę tego typu oferuje między innymi MongoDB Graph – baza oparta na grafach, która skupia się na połączeniach między obiektami. Bazy tego typu wykorzystywane są często w aplikacjach społecznościowych, gdyż idealnie sprawdzają się do przechowywania polubień, subskrypcji czy znajomości między użytkownikami. Przykład bazy tego typu to Neo4j

– baza oparta na grafach, która skupia się na połączeniach między obiektami. Bazy tego typu wykorzystywane są często w aplikacjach społecznościowych, gdyż idealnie sprawdzają się do przechowywania polubień, subskrypcji czy znajomości między użytkownikami. Przykład bazy tego typu to Neo4j Wide-column – w przypadku tej bazy danych nazwy i typy kolumn mogą różnić się dla różnych wierszy. Bazy tego typu dobrze sprawdzają się w aplikacjach opartych na dużej liczbie skomplikowanych kwerend, a nie ogromnej ilości danych. Przykładem takiej bazy jest Apache Cassandra

Bazy danych NoSQL są idealnym wyborem do aplikacji korzystających z ogromnych ilości nieustrukturyzowanych, lub częściowo ustrukturyzowanych danych, które ulegają gwałtownym zmianom. W przypadku takich danych korzystanie z relacyjnych baz sprawiałoby problem w momencie, w którym chcielibyśmy zmienić typ jakiejś kolumny. Nierelacyjne bazy danych zyskują na popularności również dzięki bardzo dobremu skalowaniu.

Wśród baz nierelacyjnych znajdziemy zarówno produkty zapewniające strong consistency (np. MongoDB) jak i eventual consistency (np. Cassandra).

Podsumowanie

Najbardziej uniwersalnym rozwiązaniem jest MySQL oraz inne podobne do niej bazy. Jej szybkość, skalowalność i zgromadzona wokół niej społeczność sprawiają, że baza ta znajdzie zastosowanie w większości aplikacji.

W momencie gdy funkcje oferowane przez wyżej wymienioną bazę stają się niewystarczające, jest to dobry moment na sięgnięcie po PostgreSQL.

Wykorzystywanie tej bazy w małych aplikcjach, gdzie nie wykorzystujemy zaawansowanych funkcji jak na przykład złożonych typów danych czy funkcji, może spowodować niepotrzebne problemy i spowolnić działanie aplikacji.

SQLite jest rozwiązaniem, które zdecydowanie polecam do testowania aplikacji.

Wybierając bazę danych zachęcam również do zastanowienia się nad rozwiązaniem typu NoSQL, gdyż bazy te ostanimi czasy zyskują ogromną popularność.

Źródła:

Jeżeli podobał Ci się ten post, dołącz do newslettera aby otrzymywać powiadomienia o nowych postach!

co wybrać? Poznaj możliwości baz danych!

NoSQL vs SQL, czyli kiedy i jaki typ bazy danych wybrać

Piotr Rzeźnik | Bazy danych | 16.02.2022

Jednym z nieodłącznych elementów i zarazem wyzwań każdego projektu informatycznego jest kwestia przechowywania i przetwarzania dużych ilości danych. Na rynku dostępnych jest wiele rodzajów baz danych, a wybranie właściwej nie zawsze jest łatwe – głównym wyzwaniem jest tutaj wierne i logiczne odwzorowanie rzeczywistych procesów biznesowych danej domeny. Zatem kiedy i jaką bazę danych wybrać? Jakie bazy danych są dostępne? I w końcu – jakie możliwości dają nierelacyjne bazy danych NoSQL?

Typy baz danych

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

bazy relacyjne (np. MySQL),

bazy nierelacyjne (np. MongoDB, Oracle NoSQL database).

NoSQL vs SQL Poznaj możliwości, jakie daje MongoDB w ecommerce! Przeczytaj artykuł

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ę:

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:

Rodzaj danych Sposób zarządzania bazą danych 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ń.