Przewodnik po NoSQL dla programistów

Jeśli śledzisz trendy w rozwoju backendu i Big Data, prawdopodobnie zauważyłeś już szum wokół baz danych NoSQL w ostatnich latach. Niektórych inspiruje takie podejście do bazy danych, inni uważają, że kryje się w nim jakiś trik: zawarte w nich modele danych nie są takie same, jak w zwykłych relacyjnych bazach danych, interfejsy programowania aplikacji są nietypowe, a aplikacje są często niezrozumiałe. W tym artykule opowiem dlaczego w ogóle powstały te bazy danych NoSQL, jakie problemy rozwiązują i dlaczego nagle potrzebnych jest tak wiele różnych baz danych. Jeśli dopiero zaczynasz przygodę z NoSQL, szczególnie może Cię zainteresować ostatnia część artykułu, która zawiera listę typów baz danych NoSQL, które moim zdaniem warto najpierw poznać, aby uzyskać dokładne zrozumienie tej dziedziny.

Dlaczego nagle potrzebujemy nowej bazy danych?

Być może zdziwi Cię pytanie: co jest nie tak z relacyjnymi bazami danych? Rzecz w tym, że przez wiele lat działały naprawdę dobrze, ale teraz pojawił się problem, z którym nie mogą sobie już poradzić. Według niektórych przewidywań w 2018 roku ludzkość będzie generować 50 000 gigabajtów danych na sekundę. To kolosalna ilość danych! Jego przechowywanie i obsługa stanowi poważne wyzwanie inżynieryjne. Co gorsza, wolumen ten stale rośnie. Jak się okazuje, relacyjne bazy danych słabo radzą sobie z pracą z naprawdę dużymi wolumenami danych. Są zaprojektowane do działania na jednej maszynie, a jeśli chcesz obsłużyć więcej żądań, jedyną opcją jest zakup komputera z większą ilością pamięci RAM i mocniejszym procesorem. Niestety liczba zapytań, jakie może obsłużyć jedna maszyna, jest ograniczona, a do pracy rozproszonej na wielu maszynach potrzebna jest inna technologia baz danych. Oczywiście niektórzy czytelnicy zachichotają w tym miejscu i powiedzą, że istnieją dwie powszechnie stosowane metody korzystania z wielu maszyn w przypadku relacyjnej bazy danych: replikacja i sharding. To prawda, ale te metody nie wystarczą, aby sprostać naszym zadaniom. Replikacja odczytu to technika, w której każda aktualizacja bazy danych jest propagowana na inne maszyny, które mogą obsługiwać tylko żądania odczytu. W tym przypadku wszystkie zmiany są wykonywane przez jeden serwer, zwany węzłem głównym, podczas gdy inne serwery, zwane replikami odczytu, przechowują jedynie kopie danych. Użytkownik może czytać z dowolnej maszyny, ale zmieniać dane tylko poprzez węzeł główny. Jest to wygodna i bardzo popularna metoda, ale pozwala jedynie przetworzyć większą liczbę żądań odczytu i w żaden sposób nie rozwiązuje problemu przetwarzania wymaganych wolumenów danych. Sharding to kolejne popularne podejście, które wykorzystuje wiele instancji relacyjnej bazy danych. Każdy z nich obsługuje operacje zapisu i odczytu części danych. Jeśli baza danych przechowuje informacje o klientach, na przykład przy użyciu fragmentowania, jedna maszyna może obsłużyć wszystkie żądania klientów, których nazwy zaczynają się na literę A, inna maszyna może przechowywać wszystkie dane klientów, których nazwy zaczynają się na literę B i tak dalej. Chociaż sharding pozwala na zarejestrowanie większej ilości danych, zarządzanie taką bazą danych to prawdziwy koszmar: trzeba wyrównać dane na różnych maszynach i skalować klaster w obu kierunkach, zgodnie z potrzebami. Choć w teorii wygląda to prosto, prawidłowe wykonanie tego zadania jest dość trudne.

Czy można ulepszyć relacyjne bazy danych?

Myślę, że przekonałeś się już, że relacyjne bazy danych nie są najlepiej dostosowane do ilości danych generowanych we współczesnym świecie. Chociaż nadal możesz się zastanawiać, dlaczego nikt jeszcze nie stworzył „lepszej” relacyjnej bazy danych, która mogłaby wydajnie działać na wielu komputerach. Może się wydawać, że ta technologia po prostu nie została jeszcze rozwinięta, a rozproszone relacyjne bazy danych pojawią się już wkrótce. Niestety, tak się nie stanie. Jest to matematycznie niemożliwe i nic na to nie można poradzić. Aby zrozumieć, dlaczego tak jest, należy przyjrzeć się tak zwanemu twierdzeniu CAP (inaczej twierdzeniu Brewera). Zostało to udowodnione w 1999 roku i stwierdza, że ​​rozproszona baza danych działająca na wielu komputerach może mieć następujące trzy właściwości: Spójność - każda operacja odczytu zwraca wyniki ostatniej odpowiadającej jej operacji zapisu. Jeżeli system jest spójny to po zapisaniu nowych danych nie da się odczytać starych, już nadpisanych danych. Dostępność ( Dostępność ) – system rozproszony może obsłużyć przychodzące żądanie w dowolnym momencie i zwrócić bezbłędną odpowiedź. Tolerancja partycji - baza danych w dalszym ciągu odpowiada na żądania odczytu i zapisu, nawet jeśli niektóre jej serwery chwilowo nie mogą się ze sobą komunikować. Ta tymczasowa awaria nazywana jest awarią łączności sieciowej i może być spowodowana różnymi czynnikami, począwszy od problemów z siecią fizyczną spowodowaną wolnym serwerem, a skończywszy na fizycznym uszkodzeniu sprzętu sieciowego. Wszystkie te właściwości są z pewnością przydatne i naprawdę chcielibyśmy, aby baza danych łączyła je wszystkie. Żaden rozsądny programista nie chciałby zrezygnować, powiedzmy, z dostępności, nie otrzymując nic w zamian. Niestety, twierdzenie CAP stwierdza również, że wszystkie trzy właściwości nie mogą zachodzić jednocześnie. Uświadomienie sobie tego może nie być łatwe, ale jest możliwe. Po pierwsze, jeśli potrzebujemy rozproszonej bazy danych, musi ona być „odporna na rozłączenie”. To nawet nie jest omawiane. Rozłączenia zdarzają się cały czas i mimo to nasza baza danych musi działać. Teraz zrozumiemy, dlaczego nie możemy osiągnąć jednocześnie spójności i dostępności. Wyobraź sobie, że mamy prostą bazę danych działającą na dwóch komputerach: A i B. Każdy użytkownik może pisać na dowolnym komputerze, po czym dane są kopiowane na drugi. Teraz wyobraź sobie, że te maszyny chwilowo nie mogą się ze sobą komunikować, a maszyna B nie jest w stanie wysyłać ani odbierać danych z maszyny A. Jeśli w tym czasie maszyna B otrzyma żądanie odczytu od klienta, ma dwie możliwości:

1. Odzyskaj swoje dane lokalne, nawet jeśli nie są najnowsze. W tym przypadku preferowana jest dostępność (aby zwrócić przynajmniej część danych, nawet nieaktualnych).
2. Błąd zwrotu. W tym przypadku preferowana jest konsekwencja: klient nie otrzyma nieaktualnych danych, ale nie otrzyma żadnych danych.

Relacyjne bazy danych starają się jednocześnie ucieleśniać właściwości „spójności” i „dostępności”, dlatego nie mogą działać w środowisku rozproszonym. Próba zaimplementowania wszystkich możliwości relacyjnej bazy danych w systemie rozproszonym będzie albo nierealistyczna, albo po prostu niewykonalna . Z drugiej strony bazy danych NoSQL kładą nacisk na skalowalność i wydajność. Zwykle brakuje im takich „podstawowych” możliwości jak połączenia i transakcje, a model danych okazuje się zupełnie inny, być może nawet w jakiś sposób ograniczający. Wszystko to sprawia, że ​​możliwe jest przechowywanie większych wolumenów danych i przetwarzanie większej liczby zapytań niż kiedykolwiek wcześniej.

W jaki sposób bazy danych NoSQL równoważą spójność i dostępność?

Może Ci się wydawać, że jeśli wybierzesz bazę danych NoSQL, zawsze otrzymasz albo jakieś nieaktualne dane, albo w przypadku jakiejkolwiek awarii pojawi się błąd. W praktyce dostępność i spójność nie są bynajmniej jedynymi dostępnymi opcjami. Dostępnych jest wiele opcji do wyboru. Relacyjne bazy danych nie mają tych opcji, ale NoSQL pozwala w podobny sposób kontrolować wykonywanie zapytań. Tak czy inaczej pozwalają ustawić dwa parametry podczas wykonywania operacji zapisu lub odczytu w bazie danych NoSQL: W - ile maszyn w klastrze musi potwierdzić zapis danych podczas wykonywania operacji zapisu . Im większa liczba maszyn, na których zapiszesz swoje dane, tym łatwiej będzie odczytać najnowsze dane przy kolejnej operacji odczytu, ale także tym dłużej to zajmie. R – z ilu maszyn chcesz odczytać dane . W systemie rozproszonym dystrybucja danych do wszystkich komputerów w klastrze może zająć trochę czasu, więc niektóre serwery będą miały najnowsze dane, a inne będą opóźnione. Im większa liczba maszyn, z których odczytywane są dane, tym większa szansa na odczytanie bieżących danych. Spójrzmy na praktyczny przykład. Jeśli w klastrze masz pięć komputerów i zdecydujesz się zapisać dane tylko na jednym, a następnie odczytać dane z jednego losowo wybranego komputera, istnieje 80% szans, że odczytasz nieaktualne dane. Z drugiej strony będzie to wymagało minimalnego wykorzystania zasobów. Jeśli więc starsze dane Ci odpowiadają, nie jest to taka zła opcja. W tym przypadku parametry W i R są równe 1. Z drugiej strony, jeśli zapiszesz dane na wszystkich pięciu maszynach w bazie danych NoSQL, możesz odczytać dane z dowolnej maszyny i mieć pewność, że za każdym razem otrzymasz aktualne dane. Wykonanie tej samej operacji na większej liczbie maszyn zajmie więcej czasu, jeśli jednak zależy Ci na aktualnych danych, możesz wybrać tę opcję. W tym przypadku W = R = 5. Jaka jest minimalna liczba odczytów i zapisów wymagana do zapewnienia spójności bazy danych? Oto prosty wzór: R + W ≥ N + 1 , gdzie N to liczba maszyn w klastrze. Oznacza to, że przy pięciu serwerach możesz wybrać albo R = 2 i W = 4, albo R = 3 i W = 3, albo R = 4 i W = 2. W tym przypadku nie ma znaczenia, do których komputerów dane zostanie zapisany, odczyt będzie zawsze wykonywany z co najmniej jednej maszyny z aktualnymi danymi. Inne bazy danych, takie jak DynamoDB, mają inne ograniczenia i pozwalają tylko na spójne zapisy. Każda część danych jest przechowywana na trzech serwerach, a kiedy jakiekolwiek dane są zapisywane, są zapisywane na dwóch z trzech maszyn. Ale podczas odczytu danych możesz wybrać jedną z dwóch opcji:

1. Odczyt ściśle spójny, podczas którego dane są odczytywane z dwóch z trzech maszyn i zawsze zwracane są ostatnie zapisane dane.
2. Ostateczny spójny odczyt, podczas którego losowo wybierana jest jedna maszyna, z której mają zostać odczytane dane. Może to jednak tymczasowo spowodować zwrócenie nieaktualnych danych.

Dlaczego istnieje tak wiele baz danych NoSQL?

Jeśli śledzisz najnowsze wiadomości z zakresu tworzenia oprogramowania, prawdopodobnie słyszałeś o wielu różnych bazach danych NoSQL, takich jak MongoDB, DynamoDB, Cassandra, Redis i wielu innych. Być może zastanawiasz się: po co nam tak wiele różnych baz danych NoSQL? Powód jest prosty: różne bazy danych NoSQL są przeznaczone do rozwiązywania różnych problemów. Dlatego liczba konkurencyjnych baz danych jest tak duża. Bazy danych NoSQL dzielą się na cztery główne kategorie:

Bazy danych zorientowane na dokumenty

Te bazy danych umożliwiają przechowywanie złożonych, zagnieżdżonych dokumentów, podczas gdy większość relacyjnych baz danych obsługuje tylko wiersze jednowymiarowe. Funkcja ta może być przydatna w wielu przypadkach, np. gdy konieczne jest przechowywanie w systemie informacji o użytkowniku posiadającym kilka adresów. Używając bazy danych zorientowanej na dokumenty, w tym przypadku można po prostu przechowywać złożony obiekt zawierający tablicę adresów, podczas gdy w relacyjnej bazie danych musiałbyś utworzyć dwie tabele: jedną z informacjami o użytkowniku i jedną z adresami. Bazy danych zorientowane na dokumenty wypełniają lukę pomiędzy modelem obiektowym a modelem danych. Niektóre relacyjne bazy danych, takie jak PostgreSQL, obsługują teraz także przechowywanie zorientowane na dokumenty, ale większości relacyjnych baz danych nadal brakuje tej możliwości.

Bazy danych kluczy/wartości

Bazy danych klucz/wartość zazwyczaj implementują najprostszy model NoSQL. Zasadniczo zapewniają rozproszoną tabelę skrótów , umożliwiającą zapisanie danych do danego klucza i odczytanie ich za jego pomocą. Bazy danych klucz/wartość są wysoce skalowalne i mają znacznie mniejsze opóźnienia niż inne bazy danych.

Graficzne bazy danych

Wiele obszarów tematycznych, na przykład sieci społecznościowe lub informacje o filmach i aktorach, można przedstawić w formie wykresów. Chociaż wykres można przedstawić za pomocą relacyjnej bazy danych, jest to trudne i niewygodne. Jeśli potrzebne są dane grafowe, lepiej skorzystać ze specjalistycznej bazy grafowej, która potrafi przechowywać informacje o grafie w rozproszonym klastrze i umożliwia sprawną implementację algorytmów na grafach.

Kolumnowe bazy danych

Główną różnicą między bazami kolumnowymi i innymi typami baz danych jest sposób przechowywania danych na dysku. Relacyjne bazy danych tworzą plik dla każdej tabeli i przechowują wartości dla wszystkich wierszy sekwencyjnie. Kolumnowe bazy danych tworzą plik dla każdej kolumny w tabelach. Struktura ta pozwala na agregację danych i wydajniejsze uruchamianie niektórych zapytań, ale należy upewnić się, że dane mieszczą się w ograniczeniach takich baz danych.

Jaką bazę danych wybrać?

Wybór bazy danych jest zwykle frustrującym problemem, a przy tak dużej liczbie dostępnych opcji może wydawać się zadaniem przytłaczającym. Dobra wiadomość jest taka, że ​​nie trzeba wybierać tylko jednego. Zamiast tworzyć pojedynczą, monolityczną aplikację, która implementuje wszystkie możliwości i ma dostęp do wszystkich danych systemu, można zastosować inny nowoczesny wzorzec zwany mikroserwisami : podzielić aplikację na zestaw niezależnych usług. Każda usługa rozwiązuje swój własny wąski problem i korzysta tylko z własnej bazy danych, która jest najbardziej odpowiednia do rozwiązania tego problemu.

Jak masz się tego wszystkiego nauczyć?

Przy tak dużej liczbie baz danych poznanie ich wszystkich może wydawać się zadaniem niemożliwym. Dobra wiadomość: nie musisz tego robić. Istnieje tylko kilka podstawowych typów baz danych NoSQL i jeśli zrozumiesz, jak działają, pozostałe będą znacznie łatwiejsze do zrozumienia. Ponadto niektóre bazy danych NoSQL są używane znacznie częściej niż inne, dlatego najlepiej skupić swoje wysiłki na najpopularniejszych rozwiązaniach. Oto lista najczęściej używanych baz danych NoSQL, którym moim zdaniem powinieneś się przyjrzeć:

1. MongoDB . Prawdopodobnie najpopularniejsza baza danych NoSQL na rynku. Jeśli firma nie używa relacyjnej bazy danych jako podstawowego magazynu danych, prawdopodobnie korzysta z MongoDB. Jest to elastyczne miejsce do przechowywania dokumentów z dobrym zestawem narzędzi. Na początku swojej kariery MongoDB cieszyło się złą reputacją ze względu na utratę danych w niektórych przypadkach , ale od tego czasu jego stabilność i niezawodność znacznie się poprawiły. Jeśli chcesz dowiedzieć się więcej,zajrzyj na ten kurs MongoDB .


2. DynamoDB . Jeśli korzystasz z Amazon Web Services (AWS), lepiej dowiedz się więcej o DynamoDB. Jest to niezwykle niezawodna, skalowalna baza danych o niskim opóźnieniu, z bogatym zestawem funkcji i integracją z wieloma innymi usługami AWS. Najlepsze jest to, że nie musisz go wdrażać samodzielnie. Wystarczy kilka kliknięć, aby skonfigurować skalowalny klaster DynamoDB, który może obsłużyć tysiące zapytań. Jeśli Cię to interesuje, możesz zapoznać się z tym kursem .


3. Neo4j . Najpopularniejsza baza danych grafów. Jest to skalowalne i stabilne rozwiązanie odpowiednie dla tych, którzy chcą korzystać z grafowego modelu danych. Jeśli chcesz dowiedzieć się więcej, zacznij od tego kursu .


4. Redisa . Podczas gdy inne opisane tutaj bazy danych służą do przechowywania podstawowych danych aplikacji, Redis służy przede wszystkim do implementowania pamięci podręcznych i przechowywania danych pomocniczych. W wielu przypadkach jedna z wyżej wymienionych baz danych jest używana w połączeniu z Redis. Aby dowiedzieć się więcej, sprawdź ten kurs.

W 2018 roku z NoSQL

Bazy danych NoSQL to rozległa i szybko rozwijająca się dziedzina. Umożliwiają przechowywanie i przetwarzanie niewyobrażalnych wcześniej ilości danych, ale wiąże się to z kosztami. Te bazy danych nie mają wielu funkcji znanych z relacyjnych baz danych, a skonfigurowanie ich do korzystania z nich może być trudne. Kiedy jednak już je opanujesz, możesz tworzyć skalowalne, rozproszone bazy danych, które będą w stanie obsłużyć zadziwiającą liczbę żądań odczytu i zapisu, co może być niezwykle ważne w przypadku generowania coraz większych wolumenów danych. Oryginał: https://simpleprogrammer.com/guide-nosql-software-developers/