Artykuł w serii
Definicja SQL i NoSQL
Dla porządku przypomnijmy, czym jest SQL. To deklaratywny język zapytań w relacyjnych bazach danych. W rozwiązaniach relacyjnych (SQL) dane są rozmieszczone w wierszach, a następnie łączone w tabelach. Następnie dane pomiędzy tabelami łączymy ze sobą poprzez identyfikator (klucz obcy).
Tak, to główna różnica. Bazy NoSQL nie są relacyjne.
W skład kompanii NoSQL, czyli alternatyw dla relacyjnych rozwiązań, wchodzą bazy: klucz–wartość, dokumentowe, rodzina kolumn oraz grafowe. To jeden z podziałów – ze względu na model danych, o którym więcej w tym artykule.
Etykieta NoSQL nie jest przyklejona do żadnej technologii czy narzędzia. Termin ten został ukuty na raty. Najpierw na potrzeby clickbaitowego hashtaga reklamującego meetup w 2009 roku, a w następnych latach reinterpretowany na Not Only SQL. Trzeba przyznać, że nieco dziwna jest definicja, która mówi o tym, czym ta baza nie jest.
Martin Fowler (jeśli jeszcze nie znasz tej osobistości, to dłużej nie zwlekaj) mówi, że trudno o jednoznaczną definicję NoSQL, łatwiej natomiast o wyłuskanie wspólnej cechy, a jest nią zdolność do rozproszenia na wiele maszyn (cluster-friendly).
Mity SQL vs NoSQL
Czytając pierwsze lepsze porównania SQL i NoSQL, z łatwością trafisz na zdezaktualizowane informacje. Oba nurty bowiem nieustannie ewoluują i w kilku obszarach się do siebie zbliżyły, adaptując dobrodziejstwa od siebie nawzajem. Część różnic, które były znamienne dekadę temu, albo już zatraciły swoją specyfikę, albo się zatarły.
NoSQL = bazy dokumentowe
Część porównań pod sloganem SQL vs NoSQL utożsamia je z MySQL vs MongoDB. To chyba najpowszechniejsze nieporozumienie. Jest to błędne podejście przynajmniej z dwóch powodów. Po pierwsze, NoSQL to bazy dokumentowe, klucz–wartość, rodziny kolumn i grafowe, a MongoDB jest przedstawicielem jednego z nich – baz dokumentowych.
Bazy SQL mają sztywny schemat, a bazy dokumentowe są schemaless
To była prawda, ale już nie jest. Z biegiem lat wprowadzono w bazach relacyjnych typ kolumny JSONb, który nie wymusza stałej struktury, bowiem można wstawić dowolny zestaw klucz–wartość. Co więcej, określenie schemaless jest mylące. Schemat danych jest schematem wymuszonym – jeśli nie na etapie pisania, to na etapie czytania z bazy; szczegółowo opiszę to w dalszej części artykułu.
Bazy SQL nie skalują się horyzontalnie i są przeznaczone do małych ilości danych
To nieprawda. PostgreSQL, jeden z najpopularniejszych relacyjnych silników bazodanowych, wspiera horyzontalne skalowanie poprzez shardy – jednakowo możesz umieścić różne tabele na różnych maszynach lub podzielić jedną tabelę na wiele maszyn. PostgreSQL podaje górny limit 32 TB, co zaspokoi potrzeby większości operacyjnych baz danych.
Nie wspomnę już o rozwiązaniach OLAP (online analytical processing), jak Redshift, które skalują się horyzontalnie i z łatwością przyjmują petabajty danych (petabajt to 1000 terabajtów).
Podsumowanie
Słowa i terminy zmieniają swoje znaczenie z biegiem czasu. Nie inaczej jest w technologii. NoSQL dziś to coś innego niż NoSQL w 2009 roku. Mam nadzieję, że zaktualizowałem Twój stan wiedzy, jednak i fragmenty z tego artykułu będą nieaktualne za dekadę.
Udostępnij ten wpis
Dobrnąłeś do końca. Jeśli ten artykuł był dla Ciebie wartościowy i chcesz otrzymywać informacje o kolejnych, to zapraszam Cię do zapisania się do listy mailingowej. Gwarantuję zero spamu.
Radek.
Inne artykuły
One thought on “Definicja i mity SQL vs NoSQL. [SQL vs NoSQL 2/6]”
Comments are closed.