Artykuł w serii
W tym artykule
Niedopasowanie relacyjno-obiektowe
Powszechną i dobrą praktyką z perspektywy relacyjnej bazy danych jest normalizacja, czyli unikanie duplikacji. Taka analogia do zasady DRY (don’t repeat yourself) w kodzie. Problem polega na tym, że utrzymujemy dwa modele danych – aplikacyjny i bazodanowy. W warstwie aplikacji zarządzamy encjami, które mają wszystkie informacje w jednym miejscu, a w bazie informacje o encji są rozproszone pomiędzy tabelami właśnie ze względu na normalizację.
Oczywiście, mamy rzeszę wyrafinowanych rozwiązań pośredniczących, czyli Object Relational Mapping (ORM), jednak koniec końców i tak utrzymujemy dodatkową warstwę, czyli dodatkowy problem. Im więcej kodu, im więcej abstrakcji – tym trudniej utrzymywać kod.
Problem ten ma nawet swoją nazwę – Object-relational impedance mismatch, która czerpie analogię z dopasowania energetycznego. Chodzi o to, aby zapewnić warunki do maksymalnej wymiany mocy ze źródła do obciążenia. Wymogiem jest zgodność impedancji (oporu w prądzie zmiennym). Jeśli się nie zgadza, to trzeba kompensować moc bierną. Z naszej programistycznej perspektywy owo kompensowanie to właśnie warstwa pośrednicząca i wszystkie zabiegi z tym związane, jak generowanie kodu i migracje.
A gdyby tak pisać do bazy całe zserializowane obiekty i pozbyć się tych ORM-ów? Okazuje się, że ta idea działa wyjątkowo skutecznie i znajduje swoje odbicie w bazach dokumentowych, klucz–wartość i rodzinie kolumn. Tyle że wtedy nie normalizujemy danych. Ma to jednak sens pod pewnymi warunkami, o czym możesz przeczytać w dalszej części serii.
Dużo danych
W czasach internetu sformułowanie „dużo danych” zmieniło swoje znaczenie. Najwięksi gracze na rynku stanęli przed wyzwaniem, jak skalować swoje systemy. Bazy SQL nie były projektowane pod skalowanie horyzontalne. Było wiele prób sprawienia, aby baza relacyjna działała jak pełnoprawne rozproszone rozwiązanie, jednak starania te nie przyniosły oczekiwanych rezultatów. Teraz mamy już wsparcie dla skalowania horyzontalnego w bazach relacyjnych za pomocą partycji, które mają na celu rozbicie dużej tabeli na mniejsze nawet na wiele maszyn. Podobnie z replikacją, w okolicach 2010 roku bazy SQL nie posiadały tej zdolności.
Konsekwencją było stworzenie nowych rozwiązań i tak: Google i Amazon niezależnie od siebie stworzyły odpowiednio Bigtable oraz DynamoDB. Te bazy, są zdolne przechowywać i zarządzać petabajtami danych.
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 “Dlaczego powstały bazy NoSQL? [SQL vs NoSQL 3/6]”
Comments are closed.