Kiedy należy używać bazy danych NoSQL zamiast relacyjnej bazy danych? Czy można używać obu w tej samej witrynie?


141

Jakie są zalety korzystania z baz danych NoSQL? Ostatnio dużo o nich czytałem, ale nadal nie jestem pewien, dlaczego chciałbym je wdrożyć iw jakich okolicznościach chciałbym z nich skorzystać.

Odpowiedzi:


84

Relacyjne bazy danych wymuszają ACID . Będziesz więc mieć bazujące na schemacie magazyny danych zorientowanych na transakcje. Jest sprawdzony i odpowiedni do 99% rzeczywistych zastosowań. Z relacyjnymi bazami danych możesz zrobić praktycznie wszystko.

Istnieją jednak ograniczenia dotyczące szybkości i skalowania, jeśli chodzi o ogromne magazyny danych o wysokiej dostępności. Na przykład Google i Amazon mają terabajty danych przechowywanych w dużych centrach danych. Zapytania i wstawianie nie są wydajne w tych scenariuszach ze względu na blokujący / schematyczny / transakcyjny charakter RDBM. To jest powód, dla którego wdrożyli własne bazy danych (a właściwie magazyny wartości klucza) w celu uzyskania ogromnego wzrostu wydajności i skalowalności.

Bazy danych NoSQL istnieją od dawna - po prostu termin jest nowy. Niektóre przykłady to wykresy, obiekty, kolumny, XML i bazy danych dokumentów.

Drugie pytanie: czy można używać obu w tej samej witrynie?

Dlaczego nie? Obie służą różnym celom, prawda?


1
Nie sądzę, aby ACID był wyłączny dla relacyjnych baz danych. Możesz mieć gwarancje trwałości, transakcje, spójność widoku w nierelacyjnych bazach danych.
Thilo

@RamshVel czy mógłbyś podać przykład bazy danych typu magazynu klucz-wartość? Dzięki.
Rachael

1
@Rachael, kilka przykładów to redis, leveldb i riak .. jest ich mnóstwo, możesz to
wygooglować

76

Rozwiązania NoSQL mają zwykle na celu rozwiązanie problemu, do którego relacyjne bazy danych albo nie są dobrze przystosowane, albo są zbyt drogie w użyciu (jak Oracle), albo wymagają wdrożenia czegoś, co i tak łamie relacyjny charakter bazy danych.

Zalety są zwykle specyficzne dla twojego zastosowania, ale jeśli nie masz jakiegoś problemu z modelowaniem danych w RDBMS, nie widzę powodu, dla którego wybrałbyś NoSQL.

Sam używam MongoDB i Riak do konkretnych problemów, w których RDBMS nie jest dobrym rozwiązaniem, do wszystkich innych rzeczy używam MySQL (lub SQLite do testowania).

Jeśli potrzebujesz bazy danych NoSQL, którą zwykle o niej wiesz, możliwe przyczyny to:

  • klient chce 99,999% dostępności w witrynie o dużym ruchu.
  • Twoje dane nie mają sensu w SQL, zdarza się, że wykonujesz wiele zapytań JOIN w celu uzyskania dostępu do jakiejś informacji.
  • łamiesz model relacyjny, masz obiekty CLOB przechowujące zdenormalizowane dane i generujesz indeksy zewnętrzne do wyszukiwania tych danych.

Jeśli nie potrzebujesz rozwiązania NoSQL, pamiętaj, że te rozwiązania nie były pomyślane jako zamienniki dla RDBMS, ale raczej jako alternatywy, w których pierwsze zawodzi, a co ważniejsze, że są stosunkowo nowe jako takie, nadal mają wiele błędów i brakujące funkcje.

Aha, a jeśli chodzi o drugie pytanie, użycie dowolnej technologii w połączeniu z inną jest całkowicie w porządku, więc z mojego doświadczenia wynika, że ​​MongoDB i MySQL działają dobrze razem, o ile nie są na tej samej maszynie


3
Dziękuję za odpowiedź. Twoje przykłady, kiedy używać NoSQL, są w najlepszym razie niejasne. Miałem nadzieję na bardziej konkretny przypadek użycia, aby móc zdecydować, czy którekolwiek z moich danych będą lepiej przechowywane w bazie danych NoSQL.
smfoote

Staram się nie odpowiadać dwa razy na to samo pytanie, spójrz na moją poprzednią odpowiedź na bardzo podobne pytanie stackoverflow.com/questions/3621415/…
Asaf

Zgadzam się ze świetną odpowiedzią Asafa, naprawdę jest tylko kilka scenariuszy, w których powinieneś potrzebować NoSQL zamiast RDBMS. Widzę NoSQL bardziej jako bazę danych kopii zapasowych lub „bazę danych dodatku” niż główną bazę danych. Nie widziałem jeszcze dobrego systemu, w którym podstawową bazą danych byłby NoSQL.
Jo Smo

38

Martin Fowler ma doskonały film, który dobrze wyjaśnia bazy danych NoSQL. Link prowadzi bezpośrednio do powodów, dla których ich używa, ale cały film zawiera dobre informacje.

  1. Masz duże ilości danych - zwłaszcza jeśli nie możesz zmieścić ich wszystkich na jednym fizycznym serwerze, ponieważ NoSQL został zaprojektowany tak, aby dobrze skalować.

  2. Niezgodność impedancji obiektowo-relacyjnej - obiekty domeny nie pasują dobrze do schematu relacyjnej bazy danych. NoSQL umożliwia utrwalanie danych w postaci dokumentów (lub wykresów), które mogą być znacznie bardziej zbliżone do modelu danych.


16

NoSQL to system bazodanowy, w którym dane są zorganizowane w dokumencie (MongoDB), parze klucz-wartość (MemCache, Redis), formie struktury grafu (Neo4J).

Być może tutaj są możliwe pytania i odpowiedzi na pytanie „Kiedy iść na NoSQL”:

  1. Wymagać elastycznego schematu lub radzić sobie z danymi przypominającymi drzewo?
    Ogólnie rzecz biorąc, w programowaniu zwinnym zaczynamy projektowanie systemu bez znajomości wszystkich wymagań z góry, podczas gdy później w trakcie rozwoju system bazy danych może wymagać częstych zmian projektowych, prezentując MVP (Minimal Viable product). Lub masz do czynienia ze schematem danych, który ma charakter dynamiczny. np. logi systemowe, bardzo dokładnym przykładem są logi AWS Cloudwatch.

  2. Zbiór danych jest rozległy / duży?
    Tak Nie Bazy danych SQL są lepszym kandydatem do zastosowań, w których baza danych musi zarządzać milionami, a nawet miliardami rekordów bez uszczerbku dla wydajności.


  3. Kompromis między skalowaniem a spójnością W przeciwieństwie do RDMS, baza danych NoSQL może tu i ówdzie tracić niewielkie dane (uwaga: prawdopodobieństwo wynosi .x%), ale jest łatwa do skalowania pod względem wydajności. Przykład: Może to być przydatne do przechowywania osób, które są online w aplikacji do obsługi wiadomości błyskawicznych, tokenów w bazie danych, rejestrowania statystyk ruchu w witrynie.

  4. Wykonywanie operacji geolokalizacyjnych: Bogata obsługa skrótów MongoDB do wykonywania operacji GeoQuerying i geolokalizacji. Bardzo podobała mi się ta funkcja MongoDB.

Krótko mówiąc, MongoDB doskonale nadaje się do aplikacji, w których można przechowywać dynamiczne dane strukturalne na dużą skalę.


4
„Baza danych NoSQL może tu i ówdzie utracić małe dane” WTF !? Kto przy zdrowych zmysłach chciałby to zaryzykować? To musi być fałszywe.
Jay Q.

1
@JayQ. Tak, może być fałszywa. Dlatego powiedziałem * może. Dlaczego więc nie możemy używać bazy danych NpSQL do operacji transakcyjnych?
Hrishikesh,

7

Brakuje pewnych istotnych informacji, aby odpowiedzieć na pytanie: jakie przypadki użycia musi być w stanie objąć baza danych? Czy złożone analizy muszą być wykonywane na podstawie istniejących danych ( OLAP ), czy aplikacja musi być w stanie przetworzyć wiele transakcji ( OLTP )? Jaka jest struktura danych? To jeszcze nie koniec tury pytań.

Moim zdaniem błędem jest podejmowanie decyzji technologicznych na podstawie śmiałych modnych słów, nie wiedząc dokładnie, co się za nimi kryje. NoSQL jest często chwalony za skalowalność. Ale musisz też wiedzieć, że skalowanie poziome (przez kilka węzłów) również ma swoją cenę i nie jest darmowe. Następnie musisz zająć się takimi kwestiami, jak spójność końcowa i zdefiniować, jak rozwiązać konflikty danych, jeśli nie można ich rozwiązać na poziomie bazy danych. Jednak dotyczy to wszystkich rozproszonych systemów baz danych.

Radość deweloperów ze słowa "mniej schematu" w NoSQL jest na początku również bardzo duża. To modne hasło szybko się odczarowuje po analizie technicznej, ponieważ poprawnie nie wymaga schematu podczas pisania, ale wchodzi w grę podczas czytania. Dlatego powinien być poprawnie „schematem przy odczycie”. Możliwość zapisania danych według własnego uznania może być kusząca. Ale jak sobie poradzić z sytuacją, gdy istnieją już dane, ale nowa wersja aplikacji oczekuje innego schematu?

Model dokumentu (jak na przykład MongoDB) nie jest odpowiedni dla modeli danych, w których istnieje wiele relacji między danymi. Połączenia muszą być wykonywane na poziomie aplikacji, co jest dodatkowym wysiłkiem i dlaczego powinienem programować rzeczy, które powinna robić baza danych.

Jeśli argumentujesz, że Google i Amazon opracowały własne bazy danych, ponieważ konwencjonalne systemy RDBMS nie są już w stanie obsłużyć zalewu danych, możesz tylko powiedzieć: nie jesteś Google i Amazon. Firmy te są liderem, około 0,01% scenariuszy, w których tradycyjne bazy danych nie są już odpowiednie, ale dla reszty świata są.

Co nie jest bez znaczenia: SQL istnieje od ponad 40 lat i miliony godzin poświęcono na rozwój dużych systemów, takich jak Oracle lub Microsoft SQL. Należy to osiągnąć za pomocą niektórych nowych baz danych. Czasami łatwiej jest znaleźć administratora SQL niż kogoś do MongoDB. Co prowadzi nas do kwestii utrzymania i zarządzania. Temat, który nie jest dokładnie seksowny, ale jest częścią decyzji technologicznej.


1
Wydaje się poprawne, ale nie sądzę że jej również prawo do porównamy ile czasu spędził gdyby tak było każdy byłby montaż przy użyciu języka w ogóle ich stosowania wolałbym powiedzieć, że zawsze sprowadza się do aplikacji i usecase
Gopherine

3

Natknąłem się na to pytanie, szukając przekonujących podstaw do odejścia od projektu RDBMS.

Jest świetny post Juliana Browna, który rzuca światło na ograniczenia systemów rozproszonych. Pojęcie to nazywa się twierdzeniem Brewera CAP, które w skrócie brzmi:

Trzy wymagania systemów rozproszonych to: spójność, dostępność i tolerancja partycji (w skrócie CAP). Ale możesz mieć tylko dwa z nich naraz.

I tak podsumowałem to dla siebie:

Lepiej idź na NoSQL, jeśli konsekwencja jest tym, co poświęcasz.


0

Zaprojektowałem i wdrożyłem rozwiązania z bazami danych NoSQL, a oto moja lista punktów kontrolnych do podjęcia decyzji o przejściu na SQL lub NoSQL zorientowany na dokumenty .

NIE WOLNO

SQL nie jest przestarzały i w niektórych przypadkach pozostaje lepszym narzędziem. Trudno jest uzasadnić użycie NoSQL zorientowanego na dokumenty, kiedy

  • Potrzebujesz OLAP / OLTP
  • To mały projekt / prosta struktura bazy danych
  • Potrzebujesz zapytań ad hoc
  • Nie można uniknąć natychmiastowej spójności
  • Niejasne wymagania
  • Brak doświadczonych programistów

TAK

Jeśli nie masz tych warunków lub możesz je złagodzić, oto 2 powody, dla których możesz skorzystać z NoSQL:

  • Trzeba działać na dużą skalę
  • Wygoda rozwoju (lepsza integracja ze stosem technologicznym, brak potrzeby w ORM itp.)

Więcej informacji

W moich postach na blogu bardziej szczegółowo wyjaśniam przyczyny:

Uwaga: powyższe dotyczy tylko NoSQL zorientowanego na dokumenty. Istnieją inne typy NoSQL, które wymagają innych rozważań.


0

Obsługa dużej liczby operacji odczytu i zapisu

Jeśli potrzebujesz szybkiego skalowania, szukaj baz danych NoSQL. Kiedy generalnie potrzebujesz szybkiego skalowania?

W przypadku dużej liczby operacji odczytu i zapisu w witrynie oraz w przypadku dużej ilości danych, bazy danych NoSQL najlepiej sprawdzają się w tych scenariuszach. Ponieważ mają możliwość dodawania węzłów w locie, mogą obsłużyć więcej równoczesnego ruchu i duże ilości danych przy minimalnym opóźnieniu.

Elastyczność dzięki modelowaniu danych

Druga wskazówka dotyczy początkowych faz rozwoju, kiedy nie masz pewności co do modelu danych, projektu bazy danych, rzeczy mają się zmieniać w szybkim tempie. Bazy danych NoSQL oferują nam większą elastyczność.

Ostateczna spójność zamiast silnej spójności

Lepiej jest wybierać bazy danych NoSQL, gdy możemy zrezygnować z silnej spójności i gdy nie wymagamy transakcji.

Dobrym tego przykładem jest serwis społecznościowy, taki jak Twitter. Gdy wybuchnie tweet celebryty i wszyscy go lubią i ponownie tweetują go z całego świata. Czy to ma znaczenie, czy liczba polubień trochę wzrośnie czy spadnie na krótką chwilę?

Celebrytki na pewno nie przejmowałoby się, gdyby zamiast rzeczywistych 5 milionów 500 polubień system pokazuje, że liczba polubień wynosi 5 milionów 250 przez krótką chwilę.

Gdy duża aplikacja jest wdrażana na setkach serwerów rozsianych po całym świecie, rozproszone geograficznie węzły potrzebują trochę czasu, aby osiągnąć globalny konsensus.

Dopóki nie osiągną konsensusu, wartość podmiotu jest niespójna. Wartość jednostki ostatecznie ustabilizuje się po krótkiej chwili. Tym jest Ostateczna Spójność.

Chociaż niespójność nie oznacza, że ​​nastąpiła utrata danych. Oznacza to po prostu, że przesłanie danych po całym świecie za pomocą kabli internetowych pod oceanem zajmuje trochę czasu, aby osiągnąć globalny konsensus i stać się spójnymi.

Cały czas doświadczamy tego zachowania. Szczególnie na YouTube. Często można zobaczyć film z 10 wyświetleniami i 15 polubieniami. Jak to w ogóle jest możliwe?

To nie jest. Rzeczywiste wyświetlenia to już więcej niż polubienia. Po prostu liczba wyświetleń jest niespójna, a jej aktualizacja zajmuje trochę czasu.

Przeprowadzanie analizy danych

Bazy danych NoSQL najlepiej nadają się również do przypadków użycia analizy danych, w których mamy do czynienia z napływem ogromnych ilości danych.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.