Cechy baz NoSQL

3.1. Słabe właściwości ACID

Przez długi czas spójność danych była świętą krową dla architektów i programistów. Wszystkie relacyjne bazy danych zapewniały pewien poziom izolacji, albo poprzez blokady aktualizacji i blokowanie odczytów, albo przez dzienniki cofania. Wraz z pojawieniem się ogromnej ilości informacji i systemów rozproszonych stało się jasne, że nie da się zapewnić dla nich z jednej strony transakcyjnego zestawu operacji, az drugiej uzyskać wysoką dostępność i szybki czas reakcji.

Co więcej, nawet aktualizacja jednego rekordu nie gwarantuje, że jakikolwiek inny użytkownik od razu zobaczy zmiany w systemie, ponieważ zmiana może nastąpić np. w węźle nadrzędnym, a replika jest kopiowana asynchronicznie do węzła podrzędnego, z którym inny użytkownik Pracuje. W takim przypadku zobaczy wynik po pewnym czasie. Nazywa się to konsekwencją ostateczną i do tego zmierzają teraz wszystkie największe firmy internetowe na świecie, w tym Facebook i Amazon. Ci drudzy z dumą deklarują, że maksymalny interwał, w którym użytkownik widzi niespójne dane, to nie więcej niż sekunda. Przykład takiej sytuacji pokazano na rysunku:

Logicznym pytaniem, które pojawia się w takiej sytuacji, jest to, co zrobić z systemami, które klasycznie stawiają wysokie wymagania co do atomowości-spójności operacji, a jednocześnie potrzebują szybkich rozproszonych klastrów - finansowych, sklepów internetowych itp.? Praktyka pokazuje, że wymagania te nie mają już znaczenia: oto, co powiedział jeden z projektantów systemu bankowości finansowej: „Gdybyśmy naprawdę czekali na zakończenie każdej transakcji w globalnej sieci bankomatów (bankomatów), transakcje trwałyby tak długo, że klienci uciekłby wściekły. Co się stanie, jeśli Ty i Twój partner wypłacicie pieniądze w tym samym czasie i przekroczycie limit? „Oboje dostaniecie pieniądze, a my naprawimy to później”.

Innym przykładem jest pokazana na obrazku rezerwacja hotelu. Sklepy internetowe, których polityka danych zakłada ewentualną spójność, są zobowiązane do zapewnienia środków na wypadek takich sytuacji (automatyczne rozwiązywanie konfliktów, cofanie operacji, aktualizacja o inne dane). W praktyce hotele zawsze starają się zachować „pulę” wolnych pokoi na wypadek sytuacji awaryjnej, a to może być rozwiązaniem kontrowersyjnej sytuacji.

W rzeczywistości słabe właściwości ACID nie oznaczają, że w ogóle ich nie ma. W większości przypadków aplikacja współpracująca z relacyjną bazą danych wykorzystuje transakcję do zmiany powiązanych logicznie obiektów (zamówienie - pozycje zamówienia), co jest konieczne, ponieważ są to różne tabele. Przy poprawnym zaprojektowaniu modelu danych w bazie NoSQL (agregat to zamówienie wraz z listą pozycji zamówienia) można osiągnąć taki sam poziom izolacji przy zmianie pojedynczego rekordu jak w relacyjnej bazie danych.

3.2. Systemy rozproszone, brak współdzielonych zasobów (brak udostępniania)

Ponownie, nie dotyczy to grafów baz danych, których struktura z definicji nie rozkłada się dobrze na odległe węzły.

Jest to być może główny motyw przewodni rozwoju baz danych NoSQL. Wraz z lawinowym wzrostem informacji na świecie i koniecznością ich przetworzenia w rozsądnym czasie pojawił się problem skalowalności pionowej – wzrost szybkości procesora zatrzymał się na 3,5 GHz, rośnie też prędkość odczytu z dysku na poziomie wolne tempo, a cena potężnego serwera jest zawsze wyższa niż łączna cena kilku prostych serwerów. W tej sytuacji konwencjonalne relacyjne bazy danych, nawet zgrupowane na macierzach dyskowych, nie są w stanie rozwiązać problemu szybkości, skalowalności i przepustowości.

Jedynym wyjściem z sytuacji jest skalowanie poziome, kiedy kilka niezależnych serwerów jest połączonych szybką siecią i każdy z nich posiada/przetwarza tylko część danych i/lub tylko część żądań odczytu/aktualizacji. W tej architekturze, aby zwiększyć pojemność pamięci masowej (pojemność, czas odpowiedzi, przepustowość) wystarczy dodać nowy serwer do klastra – i tyle. Sharding, replikacja, odporność na uszkodzenia (wynik zostanie uzyskany nawet jeśli jeden lub więcej serwerów przestanie odpowiadać), redystrybucja danych w przypadku dodania węzła jest obsługiwana przez samą bazę danych NoSQL.

Pokrótce przedstawię główne właściwości rozproszonych baz danych NoSQL:

Replikacja - kopiowanie danych do innych węzłów podczas aktualizacji. Pozwala zarówno osiągnąć większą skalowalność, jak i zwiększyć dostępność i bezpieczeństwo danych. Zwyczajowo dzieli się na dwa typy:

Pierwszy typ zakłada dobrą skalowalność odczytu (może się zdarzyć z dowolnego węzła), ale nieskalowalny zapis (tylko do węzła głównego). Istnieją również subtelności związane z zapewnieniem stałej dostępności (w przypadku awarii głównej, ręcznie lub automatycznie jeden z pozostałych węzłów jest przypisywany na swoje miejsce). Drugi typ replikacji zakłada, że ​​wszystkie węzły są równe i mogą obsługiwać zarówno żądania odczytu, jak i zapisu.

Sharding to podział danych według węzłów:

Sharding był często używany jako „podpora” relacyjnych baz danych w celu zwiększenia szybkości i przepustowości: aplikacja użytkownika dzieliła dane na kilka niezależnych baz danych, a gdy użytkownik zażądał odpowiednich danych, uzyskiwał dostęp do określonej bazy danych. W bazach danych NoSQL sharding, podobnie jak replikacja, jest wykonywany automatycznie przez samą bazę danych, a aplikacja użytkownika jest oddzielona od tych złożonych mechanizmów.

3.3. Bazy danych NoSQL są w większości open source i tworzone w XXI wieku

To właśnie z drugiej strony Sadalaj i Fowler nie sklasyfikowali obiektowych baz danych jako NoSQL (chociaż http://nosql-database.org/ umieszcza je na ogólnej liście), ponieważ powstały jeszcze w latach 90. i nigdy nie zyskały zbytniej popularności . .

Ruch NoSQL zyskuje na popularności w gigantycznym tempie. Nie oznacza to jednak, że relacyjne bazy danych stają się szczątkowe lub archaiczne. Najprawdopodobniej będą używane i wykorzystywane tak jak wcześniej aktywnie, ale coraz więcej baz NoSQL będzie z nimi działać w symbiozie. Wkraczamy w erę wytrwałości poliglotów, erę, w której różne magazyny danych są wykorzystywane do różnych potrzeb. Obecnie nie ma monopolu na relacyjne bazy danych jako niekwestionowane źródło danych. Coraz częściej architekci wybierają przechowywanie w oparciu o charakter samych danych i sposób, w jaki chcemy nimi manipulować, jakie ilości informacji są oczekiwane. I tak wszystko staje się ciekawsze.

Poniżej postaramy się zrozumieć działanie rozproszonej bazy danych na przykładzie NoSQL Cassandra DBMS...