011 ASPEKTY BAZ NOSQL Prof. dr hab. Marek Wisła
Transakcje Większość baz nierelacyjnych zaprojektowanych z myślą o skalowalności nie wspiera transakcji spełniających warunki ACID. Brak gwarancji ACID oznacza, że w trakcie działania bazy mogą pojawić się pewne anomalie: Brak gwarancji atomowości: z kilku operacji wysłanych do bazy danych może zostać wykonana tylko część. Brak gwarancji spójności: identyczne zapytania do bazy danych mogą otrzymywać w tym samym czasie rożne odpowiedzi. Brak gwarancji izolacji: dwie transakcje na bazie danych mogą w jednym czasie modyfikować te same dane. Np. w systemie rezerwacyjnym mogłaby zajść sytuacja, że dwie osoby zarezerwują ten sam pokój. Brak gwarancji trwałości: przy operacji zapisu nawet komunikat o sukcesie może nie gwarantować, że dane będą trwale zapisane.
Brak gwarancji ACID Brak gwarancji ACID może wydawać się poważnym problemem faktycznie w wielu zastosowaniach baza danych nie wspierająca takich transakcji jest wykluczona. Z drugiej jednak strony inne korzyści mogą być ważniejsze i występowanie wymienionych wyżej anomalii będzie akceptowalne. Duży sklep internetowy może pozwolić sobie, aby dwie osoby kupiły ostatnią sztukę produktu oznaczać to będzie konieczność przeproszenia jednego z klientów. W tym samym czasie jednak tysiące innych może używać aplikacji znacznie szybciej. Indeks wyszukiwarki internetowej może utracić część danych. Jeśli wyniki wyszukiwarki podawane są w oparciu o analizę statyczną zebranych informacji, brak pewnej części danych nie wpłynie znacząco na te wyniki.
Kompromisy Jedną z idei przyświecających powstaniu baz nierelacyjnych było umożliwienie twórcom aplikacji wyboru między jedną cechą bazy a drugą (np. szybkością operacji a trwałością danych). W praktyce decydując się na użycie bazy nierelacyjnej należy upewnić się, jakie gwarancje z grupy ACID zapewniają operacje wykonywane na tej bazie. W wielu przypadkach użytkownikom pozostawia się kontrolę nad tymi gwarancjami muszą oni dokonywać kompromisów. Np. zapis danych w bazie MongoDB z domyślnymi ustawieniami nie daje gwarancji trwałości, można jednak dokonać zapisu z opcją wymuszającą trwały zapis. Wówczas jednak operacja będzie trwać dłużej użytkownik bazy decyduje, która cecha jest ważniejsza.
BASE BASE jest skrótem wprowadzonym przez Erica Brewera. BA - basically available: baza danych i informacje w niej zawarte są zasadniczo dostępne, choć mogą być momenty, że część operacji na bazie nie może być wykonana, S - soft state: stan danych może zmieniać się bez dodatkowych operacji użytkownika (wynika to z tego, że sam system zmienia stan danych w celu ich uspójnienia), E - eventually consistent: dane w bazie nie muszą być spójne (system może zapisać najpierw zmiany tylko na części serwerów), jednak istnieją mechanizmy uspójniania tych danych i bez dodatkowych operacji użytkownika z czasem nastąpi uspójnienie.
BASE vs ACID Bazy rozproszone spełniające warunki BASE implementują cechy AP z twierdzenia CAP: dostępność systemu przy braku komunikacji między niektórymi węzłami kosztem braku spójności w danych. BASE jest często przeciwstawiany systemom implementującym ACID: tutaj spójność danych jest ważniejsza od dostępności w sytuacji braku komunikacji między węzłami.
BASE a użytkownik Należy zwrócić uwagę, że w systemach BASE opisywane cechy nie są ścisłymi gwarancjami: system jest zasadniczo dostępny do wykonywania operacji użytkownika (ale nadal część operacji może być odrzucana), spójność danych między węzłami ma zostać ostatecznie osiągnięta (ale bez określenia dokładnie kiedy). W praktyce oznacza to, że wybierając bazę nierelacyjną należy dokładnie zapoznać się z dokumentacją dotyczącą transakcji. Często to użytkownik musi ustalić kompromis pomiędzy sprzecznymi cechami.
API zamiast SQL Bazy nierelacyjne zamiast ustandaryzowanego języka SQL używają własnych interfejsów do komunikacji. Interfejs taki, nazywany API (application programming interface), jest zazwyczaj rożny dla każdej bazy. W praktyce oznacza to, że tworząc oprogramowanie w oparciu o bazę nierelacyjną będzie ono bardzo ściśle powiązane z wybraną technologią przechowywania danych. Zmiana bazy danych na inną wymaga wówczas znacznie większego nakładu pracy programistycznej.
Tworzenie aplikacji Tworzenie aplikacji z użyciem baz nierelacyjnych wymaga od projektantów i programistów poznania możliwości i sposobu komunikacji z wybraną bazą danych. Nawet jeśli bazy nierelacyjne są do siebie podobne (jak bazy szerokokolumnowe klony BigTable), to każda z baz jest tworzona przy nieco innych założeniach, w rożnych implementacjach nacisk kładzie się na inną cechę systemu.
Większa wiedza Nierelacyjne bazy wymagają od użytkowników głębszego poznania swojej technologii niż bazy relacyjne. Nie dotyczy to tylko komunikacji z bazą, również konieczna jest głębsza wiedza dotycząca administrowania serwerami. W przypadku baz relacyjnych organizacje tworzące oprogramowanie zwykle rozdzielają role programistów i administratorów baz danych. W bazach nierelacyjnych (zwłaszcza tych utworzonych do działania w klastrze) taki podział jest o wiele trudniejszy: programiści muszą mieć wiedzę, w jaki sposób wysyłane do bazy zapytania będą wykonywane, a administratorzy bazy muszą dokładnie znać sposób działania aplikacji klienckich.
Modelowanie Istotną cechą nierelacyjnych baz danych jest inny sposób modelowania danych w porównaniu z bazami relacyjnymi. W przypadku baz relacyjnych istotna jest normalizacja danych. Podstawową różnicą w modelowaniu danych w bazach nierelacyjnych jest brak ścisłego schematu. Baza danych pozostaje pusta do momentu, gdy aplikacja zapisze w niej dane. Nie ma potrzeby określania jak te dane będą wyglądały. (+) Dane w bazie nierelacyjnej mogą być zapisane z o wiele większą elastycznością niż w bazie relacyjnej. (-) Wymagany jest dodatkowy nakład pracy po stronie kodu aplikacji, aby upewnić się, że dane są prawidłowo zapisywane oraz odczytane dane są prawidłowo interpretowane.
Przykład testy on-line Aplikacja do tworzenia testow on-line. Test ma składać się z pewnej liczby rożnego rodzaju pytań: otwartych, jednokrotnego wyboru, wielokrotnego wyboru.` Schemat bazy relacyjnej dla takiej aplikacji jest dość skomplikowany ze względu na różnorodność danych potrzebnych do zapisania pytań i odpowiedzi. Dwie możliwości rozwiązania tego problemu: Utworzenie jednej tabeli przechowującej rożne rodzaje pytań. Wówczas konieczne jest programistyczne przetwarzanie zapisywanych w takiej tabeli danych (np. proste pytanie otwarte będzie miało tylko treść pytania, natomiast pytania wyboru również listę możliwych odpowiedzi). Traci się również korzyści z możliwości odpytywania bazy danych o szczegóły odpowiedzi (np. zapytanie o to, ile osób wybierało jedną z opcji pytania wielokrotnego wyboru). Tworzenie wielu tabel innych do rożnych typów pytań. Daje to większą swobodę tworzenia nowych typów pytań w przyszłości, jak również tworzenia dowolnych raportów o odpowiedziach. Wadą jest jednak to, że schemat bazy i jej używanie jest o wiele bardziej złożone.
Przykład testy on-line Utworzenie takiej aplikacji z bazą nierelacyjną, która nie wymaga określania schematu danych jest o wiele prostsze. Poniżej przykładowe dane testu w formacie JSON (obsługiwanego np. w MongoDB): { nazwa: 'Test końcowy', pytania: [ ] } { typ: pytanie_otwarte, treść: Podaj imię i nazwisko }, { typ: pytanie_jednokrotnego_wyboru, treść: Wybierz płeć, opcje: [ kobieta, mężczyzna ] }
Denormalizacja Drugą istotną cechą baz nierelacyjnych jest denormalizacja. Nie ma tu możliwości łączenia zapisując jednostkę danych trzeba zadbać, aby była to spójna całość. Przykład: aplikacja obsługująca dziekanat ma dwa przypadki użycia: pobranie listy przedmiotów studenta, pobranie listy studentów dla przedmiotu.
Schemat bazy relacyjnej W przypadku bazy relacyjnej można skorzystać ze schematu bazy pokazanego wyżej. Odpowiednie zapytanie do tabeli Egzaminy pozwoli obsłużyć obydwa przypadku użycia.
Zapytania w bazie relacyjnej Pobranie listy przedmiotów studenta: SELECT * FROM Egzaminy e LEFT JOIN Przedmioty p ON e.id_przedmiotu = p.id WHERE e.id_studenta =? Pobranie listy studentów dla przedmiotu: SELECT * FROM Egzaminy e LEFT JOIN Studenci s ON e.id_studenta = s.id WHERE e.id_przedmiotu =?
Model bazy nierelacyjnej W przypadku użycia bazy szerokokolumnowej nie można dokonać łączenia. Aby móc zrealizować oba przypadki użycia, informacje o przypisaniu studenta do przedmiotu muszą być zduplikowane. Poniższa tabela prezentuje pseudoschemat takiej bazy danych.
Pobieranie danych W momencie przypisania studenta do przedmiotu informacja ta musi być dodana do dwóch tabel, podobnie w momencie zaliczenia przedmiotu. Dzięki tej denormalizacji pobranie pełnej informacji o przedmiocie lub studencie wymaga wykonania tylko jednej operacji (get z identyfikatorem przedmiotu lub studenta). W przypadku bazy relacyjnej jeden ze wspomnianych przypadków użycia mógłby być zrealizowany np. w późniejszej wersji aplikacji bez konieczności zmian w bazie danych. Baza szerokokolumnowa nie daje takiej elastyczności gdyby jeden z przypadków użycia nie został przewidziany, dodanie go w późniejszym czasie wymaga zmian w bazie danych.
Konstrukcja kluczy Założmy, że aplikacja obsługująca dziekanat ma wspierać kolejny przypadek użycia: wyszukiwanie przez studenta wszystkich jego przedmiotów w wybranym semestrze. Każdy przedmiot ma zapisaną informację o semestrze, jednak aby znaleźć wszystkie przedmioty z wybranego semestru dla jednego studenta trzeba przeszukać całą tabelę. Aby uniknąć takiej kosztownej operacji rozbudowuje się identyfikator przedmiotu o informację o semestrze.
Klucz Identyfikator przedmiotu ma postać: <rok><kod semestru><kod przedmiotu>, gdzie: rok to 4 cyfry, kod semestru to litera L lub Z (odpowiednio semestr letni i zimowy), kod przedmiotu to 3 litery (chociaż w przypadku ostatniego członu złożonego klucza nie jest konieczne ustalanie długości). Dzięki temu, że klucze (zarówno identyfikatory wierszy, jak i identyfikatory kolumn w wierszu) przechowywane są w sposób uporządkowany można pobrać tylko wybrany zakres danych. Mając odpowiednio skonstruowany klucz przedmiotu można znaleźć tylko przedmioty studenta z danego semestru lub roku.
Przykłady z bazy HBase w języku Java: /* używana w tym przykładzie funkcja getbytes() zwraca tablicę bajtow reprezentującą dany napis */ Get get = new Get( s124567.getbytes()); get.addfamily( przedmioty.getbytes()); /* pobranie wszyskich przedmiotów z jednego semestru: 2013 L ColumnRangeFilter to obiekt odpowiedzialny za wybranie tylko zakresu kolumn - pierwszy argument wskazuje wartość minimalną, - drugi oznacza czy wartość minimalna ma być włączona do wyników - dwa następne argumenty oznaczają wartość maksymalną i włączenie jej do wynikow */ get.setfilter(new ColumnRangeFilter( 2013L.getBytes(),true, 2013Z.getBytes(), false)); /* pobranie wszystkich przedmiotow w jednego roku akademickiego 2012/2013 */ get.setfilter(new ColumnRangeFilter( 2012Z.getBytes(), true, 2013L.getBytes(), true));
Raporty ad-hoc Niewielka część baz nierelacyjnych zapewnia porównywalną elastyczność wyszukiwania danych jak bazy relacyjne. W bazach relacyjnych istnieje wiele narzędzi pozwalających połączyć się z bazą i wywołać dowolne zapytanie SQL. Taka możliwość jest bardzo przydatna podczas tworzenia raportów ad-hoc. W przypadku baz nierelacyjnych (zwłaszcza szerokokolumnowych i typu klucz-wartość) takiej elastyczności brakuje. Organizacja danych w bazie wynika z potrzeb określonej aplikacji i zapytań jakie ta aplikacja wywołuje. Dlatego utworzenie raportu, którego nie przewidziano na poziomie projektowania aplikacji często polega na napisaniu osobnego mini-programu.
Map-reduce Większość nierelacyjnych baz danych pozwala na skalowalność poprzez dodawanie nowych serwerów. W konsekwencji: dane są rozproszone na wielu maszynach, nie ma możliwości łączenia danych i tworzenia relacji między nimi. utrudnione obliczanie agregacji przetwarzania, które obejmuje cały zbiór danych. Rozwiązaniem tego problemu jest model map-reduce. Map-reduce jest modelem rozproszonego przetwarzania danych opracowanym przez firmę Google, składającego się z dwóch faz: mapowanie: każdy serwer przetwarza zgromadzone lokalnie dane i zwraca wynik w postaci mapy, czyli wielu powiązanych par kluczwartość; redukowanie: łączenie wielu cząstkowych wyników pobranych w poprzednim kroku w ostateczny wynik.
Diagram map-reduce.
Map-reduce Fazy mapowania i redukowania przeprowadzane są równolegle na wielu maszynach. W fazie mapowania tworzone są pary klucz-wartość (kx,vx). Dla jednego klucza kx może być generowanych wiele par. W fazie łączenia, dla każdego klucza kx tworzone są listy znalezionych wartości (kx, [v1, v2, v3, ]). Wartości vx są posortowane. W fazie redukowania z tablicy [v1, v2, v3, ] obliczana jest ostateczna wartość dla każdego klucza kx (np. sumowanie, średnia itp.). Map-reduce jest wspierany przez większość nowoczesnych nierelacyjnych baz danych. Istnieją implementacje mechanizmu wykonujące tego typu przetwarzanie nawet na pojedynczej maszynie o wielu rdzeniach lub procesorach.
Przykład map-reduce Zliczania wystąpień słów w pliku tekstowym. 1. Dzielimy plik na wiersze i przekazujemy je do funkcji map na maszynie (być może każdy wiersz do osobnej maszyny). 2. Dla każdego słowa z otrzymanego wiersza maszyna generuje (niekoniecznie unikalne) pary <słowo, 1>. 3. Na etapie sortowania powstają unikalne listy <słowo,1,1,1 1>. Ilość jedynek odpowiada ilości słów w wierszu. 4. W fazie reduce zliczana jest ilość jedynek i tworzona jest para <słowo, n> obrazująca ilość wystąpienia słowa w pliku tekstowym.
Cel impulsem powstania bazy NoSQL Wiele powstających nierelacyjnych baz danych ma podobną historię: początkowo były to projekty mające usprawnić pojedynczą aplikację, w której baza relacyjna nie sprawdzała się najlepiej. W następnych krokach twórcy udostępniali publicznie: albo założenia i architekturę bazy (jak w przypadku BigTable Google'a czy Dynamo Amazona), albo kod źródłowy systemu na otwartej licencji. Upublicznione projekty rozwijały w stronę coraz ogólniejszych zastosowań w miarę jak dodawane były nowe możliwości i usprawnienia. Zawsze jednak bazy nierelacyjne wyróżniają się jedną cechą: każda została stworzona w określonym celu.
Wymagania determinują wybór bazy NoSQL Tworząc aplikację używającą bazy relacyjnej wybór konkretnego produktu jest sprawą drugorzędną, oferują one podobne funkcje i spełniają ustalone standardy. Często można stosować jedną bazę relacyjną w fazie tworzenia aplikacji i inną w czasie testów i wdrożenia. W przypadku baz nierelacyjnych wybór konkretnego produktu musi być podyktowany wymaganiami. Nie ma tutaj dowolności zmiany bazy, nawet gdy chodzi o zmianę na podobny rodzaj bazy nierelacyjnej.
Systemy hybrydowe Decyzja o zastosowaniu w aplikacji bazy nierelacyjnej wynikać będzie z napotkania limitu możliwości technologii relacyjnych lub potrzeby wydajnego przetwarzania określonych struktur danych (np. grafów, dokumentów). Najczęściej baza relacyjna nie może być całkowicie zastąpiona bazą nierelacyjną, ta ostatnia jest jedynie technologią uzupełniającą. W praktycznych zastosowaniach baza nierelacyjna jest używana jednocześnie z bazą relacyjną - takie rozwiązania nazywamy systemami hybrydowymi.
Przykład systemu hybrydowego Aplikacja przetwarzająca tzw. big data będzie wykorzystywała pewien typ bazy nierelacyjnej do przechowywania ogromnej ilości danych na wielu standardowych, niedrogich serwerach. Pojedynczy wpis w takim zbiorze danych może zostać utracony (gdy w grę wchodzi analiza statystyczna utrata małej części danych nie wpłynie na globalne wyniki). Jednak wyniki przetwarzania danych mogą już trafiać do bazy relacyjnej. Ilość zagregowanych danych jest o wiele mniejsza a same informacje cenniejsze (zarówno pod względem wykorzystania biznesowego jak i kosztów uzyskania).
Zalety systemów hybrydowych Dodatkowym argumentem za stosowaniem baz nierelacyjnych jako uzupełniania tradycyjnej bazy relacyjnej jest niedojrzałość niedawno powstałych projektów i technologii. Większość nowoczesnych baz nierelacyjnych rozwinęła się stosunkowo niedawno, za początek rozwoju przyjmuje się rok 2008. Nie są to więc technologie tak dojrzałe i sprawdzone jak w przypadku baz relacyjnych, a to ma duże znaczenie w komercyjnych zastosowaniach. Ponadto bazy nierelacyjne (np. typu open-source) często wymagają dostosowania do specyficznych potrzeb użytkownika, co dodatkowo podnosi koszt implementacji nowego rozwiązania.