Czy korzystanie z baz danych NoSQL jest niepraktyczne w przypadku dużych zbiorów danych, w których należy wyszukiwać według zawartości?

51

Od tygodnia uczę się o bazach danych NoSQL.

Naprawdę rozumiem zalety baz danych NoSQL i wiele przypadków ich użycia.

Ale często ludzie piszą swoje artykuły, jakby NoSQL mógł zastąpić Relacyjne bazy danych. I jest taki punkt, że nie mogę się obejść:

Bazy danych NoSQL to (często) magazyny kluczy i wartości.

Oczywiście możliwe jest przechowywanie wszystkiego w magazynie klucz-wartość (przez kodowanie danych w JSON, XML, cokolwiek), ale widzę problem, że musisz uzyskać pewną ilość danych, która pasuje do określonego kryterium, w wielu przypadków użycia. W bazie danych NoSQL masz tylko jedno kryterium, którego możesz skutecznie szukać - klucz. Relacyjne bazy danych są zoptymalizowane pod kątem skutecznego wyszukiwania dowolnej wartości w wierszu danych.

Tak więc bazy danych NoSQL nie są tak naprawdę wyborem na utrwalanie danych, które należy przeszukiwać według ich zawartości. A może coś źle zrozumiałem?

Przykład:

Musisz przechowywać dane użytkownika dla sklepu internetowego.

W relacyjnej bazie danych przechowujesz każdego użytkownika jako wiersz w userstabeli z identyfikatorem, nazwą, jego krajem itp.

W bazie danych NoSQL zapisujesz każdego użytkownika z jego identyfikatorem jako kluczem i wszystkimi jego danymi (zakodowanymi w JSON itp.) Jako wartością.

Jeśli więc chcesz uzyskać wszystkich użytkowników z określonego kraju (z jakiegoś powodu specjaliści od marketingu muszą coś o nich wiedzieć), łatwo jest to zrobić w Relacyjnej bazie danych, ale niezbyt skuteczna w bazie danych NoSQL, ponieważ musisz pobierz każdego użytkownika, przeanalizuj wszystkie dane i przefiltruj.

Nie twierdzę, że to niemożliwe , ale robi się o wiele trudniejsze i myślę, że nie jest tak skuteczne, jeśli chcesz przeszukiwać dane wpisów NoSQL.

Możesz utworzyć klucz dla każdego kraju, w którym przechowywane są klucze każdego użytkownika mieszkającego w tym kraju, i uzyskać użytkowników określonego kraju, uzyskując wszystkie klucze, które są zdeponowane w kluczu dla tego kraju. Ale myślę, że ta technika sprawia, że ​​złożony zestaw danych jest jeszcze bardziej złożony - trudniej go wdrożyć i nie jest tak skuteczny, jak zapytania do bazy danych SQL. Więc myślę, że nie jest to sposób, w jaki byś użył w produkcji. Albo to jest?

Nie jestem do końca pewien, czy coś źle zrozumiałem lub przeoczyłem niektóre koncepcje lub najlepsze praktyki dotyczące takich przypadków użycia. Może mógłbyś poprawić moje oświadczenia i odpowiedzieć na moje pytania.

Leo Lindhorst
źródło
16
To brzmi bardziej jak rant niż pytanie. Wydaje się, że dobrze rozumiesz zalety i wady przechowywania danych o kluczowej wartości w porównaniu z relacyjnymi. Więc jakie jest dokładnie pytanie?
JacquesB
16
To wcale nie jest rant :) Bazy danych NoSQL są niesamowite, ale myślę, że relacyjne bazy danych nie są tak złe, jak twierdzą niektórzy ludzie. Chcę tylko dowiedzieć się, jeśli moja teza, że ​​bazy danych NoSQL nie są najlepszym wyborem, jeśli chodzi o wyszukiwanie w „bazach danych” ... lub jeśli nie zrozumiałem poprawnie tematu.
Leo Lindhorst,
2
programmers.stackexchange.com/q/54373/17853
Lekkość ściga się z Moniką
5
Ale MongoDB jest Webscale ! [ostrzeżenie: zawiera język NSFW]
Jerry Coffin
5
@DevWurm: Ogólnie nie powinieneś łączyć sklepów z kluczowymi wartościami z NoSQL. Na przykład Google BigTable jest uważany za bazę danych NoSQL, ale nadal możesz wyszukiwać i tworzyć indeksy na wielu polach. Magazyn kluczy i wartości jest odpowiedni, gdy wiesz, że musisz szukać tylko w jednym polu (kluczu).
JacquesB

Odpowiedzi:

40

Chociaż zgadzam się z twoją przesłanką, że NoSQL nie jest panaceum na wszystkie nieszczęścia związane z bazami danych, myślę, że źle rozumiesz jedną kluczową kwestię.

W bazie danych NoSQL masz tylko jedno kryterium, którego możesz skutecznie szukać - klucz.

To oczywiście nie jest prawda.

Na przykład MongoDB obsługuje indeksy. (od https://docs.mongodb.org/v3.0/core/indexes-introduction/ )

Indeksy wspierają wydajne wykonywanie zapytań w MongoDB. Bez indeksów MongoDB musi wykonać skanowanie kolekcji, tzn. Zeskanować każdy dokument w kolekcji, aby wybrać te dokumenty, które pasują do zapytania. Jeśli istnieje odpowiedni indeks dla zapytania, MongoDB może użyć tego indeksu, aby ograniczyć liczbę dokumentów, które musi sprawdzić.

Indeksy to specjalne struktury danych [1], które przechowują niewielką część zestawu danych kolekcji w łatwej do przeglądania formie. Indeks przechowuje wartość określonego pola lub zestawu pól, uporządkowaną według wartości pola. Kolejność wpisów indeksu obsługuje wydajne dopasowania równości i operacje zapytań oparte na zakresie. Ponadto MongoDB może zwracać posortowane wyniki przy użyciu kolejności w indeksie.

Podobnie jak couchbase (z http://docs.couchbase.com/admin/admin/Views/views-intro.html )

Widoki kanapy umożliwiają indeksowanie i wyszukiwanie danych.

Widok tworzy indeks danych zgodnie ze zdefiniowanym formatem i strukturą. Widok składa się z określonych pól i informacji pobranych z obiektów w Couchbase.

W rzeczywistości wszystko, co nazywa się bazą danych NoSQL, a nie magazynem wartości i kluczy, powinno w rzeczywistości obsługiwać pewien rodzaj schematów indeksowania.

W rzeczywistości to właśnie elastyczność tych schematów indeksów sprawia, że ​​NoSQL świeci. Moim zdaniem język używany do definiowania indeksów NoSQL jest często bardziej wyrazisty lub naturalny niż SQL, a ponieważ zwykle znajdują się poza tabelą, nie trzeba zmieniać schematów tabeli, aby je obsługiwać. (Nie wspominając, że nie można robić podobnych rzeczy w SQL, ale dla mnie wydaje się, że jest tam o wiele więcej skoków).

Michael Anderson
źródło
13
„... ponieważ zwykle mieszkają poza stołem, nie musisz zmieniać schematów tabel, aby je obsługiwać”. To ta sama sytuacja między indeksem nieklastrowanym w bazie danych SQL a indeksem bazy danych noSQL, prawda?
Jirka Hanika
Całkiem solidna odpowiedź. Dodam, że NoSQL jest w pewnym stopniu oparty na pomyśle, że jeśli chcesz iść szybciej, powinieneś składać żądania w 90% ++ za pomocą klucza podstawowego bez sprzężenia, a jeśli chcesz zrobić cokolwiek innego, jesteś w świat skanów tabel i indeksów wtórnych, które zawsze mają ograniczenia wydajności i skali. Gdy przeszukujesz indeks lub utworzyłeś grupę, po prostu nie jesteś w obszarze, w którym można osiągnąć prędkość (z wyjątkiem małych zestawów danych o kilku milionach wierszy). Jeśli kodujesz w stylu, w którym alternatywne wyszukiwania są rzadkie, uzyskasz bardzo solidny system operacyjny.
Brian Bulkowski
40

Ogólnie rzecz biorąc, jeśli Twój przepływ pracy jest idealnie dopasowany do kwerend relacyjnych baz danych, znajdziesz relacyjne bazy danych jako najbardziej wydajne podejście. To rodzaj tautologii, ale to prawda.

Twierdzenie, że wielu zwolenników NoSQL zrobiłoby to, że wiele przepływów pracy zostało faktycznie zamaskowanych do postaci relacyjnej i byłyby bardziej skuteczne przed takim masowaniem. Ważność tego roszczenia jest trudna do ustalenia. Oczywiście są zadania, które są bardzo dobrze opisane przez zapytania SQL. Mogę powiedzieć z mojego doświadczenia, że moje szczególne zadania programowania relacyjnego mogły zostać wykonane przy użyciu NoSQL z prawie takim samym poziomem wydajności, jeśli nie większym. Jest to jednak bardzo subiektywne stwierdzenie oparte na wąskim doświadczeniu.

Mam wrażenie, że duża część sprzedaży podejścia NoSQL wynika z założenia dużych baz danych. Im większa baza danych, tym bardziej musisz dbać o przepływ pracy, aby obsługiwać większe zbiory danych. Wydaje się, że NoSQL lepiej wspiera wysiłki związane z pielęgnacją. Zatem im większa baza danych, tym ważniejsze mogą być funkcje NoSQL.

Aby skorzystać z tego przykładu, w zapytaniach SQL według kraju jest tak samo powolny jak skanowanie wszystkich użytkowników NoSQL, chyba że SQL wyraźnie nakazał indeksować userstabelę według kraju. NoSQL może zrobić to samo, jeśli utworzysz uporządkowaną kolekcję klucz-wartość, która jest indeksem (tak jak SQL robi to pod maską) i utrzymasz go.

Różnica? Silniki SQL miały wbudowaną koncepcję indeksowania tabeli. Oznacza to, że musisz wykonać mniej pracy (wystarczyło dodać indeks do tabeli). Oznacza to jednak również, że masz mniejszą kontrolę. W większości przypadków utrata kontroli jest możliwa do zaakceptowania w zamian za silnik SQL wykonujący pracę za Ciebie. Jednak w przypadku masowych zestawów danych może być potrzebny inny model spójności niż typowy model SQL ACID. Możesz użyć modelu BASE, który obsługuje ostateczną spójność. Może to być bardzo trudne w SQL, ponieważ silnik SQL wykonuje pracę za Ciebie, więc musi to być zrobione zgodnie z regułami silnika SQL. W NoSQL warstwy te są zazwyczaj widoczne, co pozwala na hakowanie.

Cort Ammon
źródło
2
W swoim przykładzie twierdzisz, że „ zapytania SQL według kraju są tak wolne, jak skanowanie wszystkich użytkowników NoSQL ”. Czy masz na to dowody? NoSQL opisany w pytaniu jest parą klucz-wartość, więc musiałbyś zeskanować wartość, aby uzyskać lokalizację kraju, a następnie dokonać porównania. SQL już wie, gdzie są te dane, więc może wybrać je bezpośrednio z dysku (pomijając niepotrzebne), a następnie sprawdzić wartość. Jeśli kraj jest kluczem obcym, jest to szybkie porównanie liczb całkowitych. Czy to nie zawsze będzie szybsze, ponieważ wyciągasz mniej z dysku, a kontrola jest szybsza.
Trisped 12.01.16
1
@Trisped Trudno jest przedstawić dowody, ponieważ NoSQL to podejście, a nie produkt (to samo dotyczy SQL). Warto jednak zauważyć, że BigTable, implementacja NoSQL, ma pojęcie kolumn, podobnie jak tabele SQL. Jest to koncepcja kolumn, która pozwala pomijać dane, wiedząc, gdzie szukać, którą można zastosować do każdej implementacji.
Cort Ammon
16

NoSQL jest dość niejasnym terminem, ponieważ zasadniczo obejmuje wszystkie systemy baz danych, które nie są relacyjne.

To, co opisujesz, to magazyn klucz-wartość , który jest rodzajem bazy danych, w której kropla danych jest przechowywana pod kluczem, i można go szybko wyszukać, jeśli znasz klucz. Te bazy danych są niesamowicie szybkie, jeśli znasz dokładny klucz, ale jak sam mówisz, jeśli musisz przeszukać lub przefiltrować wiele właściwości danych, będzie to powolne i kłopotliwe.

Nikt przy zdrowych zmysłach nie twierdziłby, że sklepy o kluczowej wartości mogą ogólnie zastąpić relacyjne bazy danych. Mogą jednak występować szczególne przypadki użycia, w których sklep z kluczową wartością jest dobrym rozwiązaniem. Magazyny klucz-wartość są często używane do buforowania, ponieważ zwykle buforujesz elementy według identyfikatora, ale nie musisz wykonywać zapytań ad hoc w pamięci podręcznej. Na przykład strona sama używa Stackoverflow Redis (DB klucz-wartość) obszernie , ale tylko do buforowania wyjścia. Podstawowe dane kanoniczne są nadal utrwalane w relacyjnej bazie danych.

Odpowiedź jest więc dość oczywista: użyj magazynu klucz-wartość, jeśli potrzebujesz tylko przechowywać i wyszukiwać za pomocą jednego klucza. W przeciwnym razie użyj innego rodzaju bazy danych. A jeśli masz wątpliwości, skorzystaj z relacyjnej bazy danych, ponieważ jest to najbardziej wszechstronny rodzaj bazy danych, podczas gdy bazy danych NoSQL są często zoptymalizowane pod kątem konkretnych przypadków użycia.

JacquesB
źródło
2
„NoSQL jest dość niejasnym terminem, ponieważ zasadniczo obejmuje wszystkie systemy baz danych, które nie są relacyjne”. - To nieprawda. Obejmuje wszystkie systemy baz danych, które nie są bazami danych SQL. Istnieją relacyjne bazy danych, które nie używają SQL, takie jak Rel i Tutorial D (bazy danych, które są zaprojektowane tak, aby ściślej podążać za modelem relacyjnym bez „zmiękczania” SQL. Istnieją hiperrelacyjne bazy danych. Naprawdę, NoSQL oznacza „Nie tylko SQL”, co oznacza „nie zakładaj automatycznie SQL, wybierz odpowiedni model bazy danych, który pasuje do struktury twojej daty… który może być SQL”.
Jörg W Mittag
@ JörgWMittag Według twojej definicji, jeśli wybiorę MySQL, ponieważ jest to najlepsza baza danych, która pasuje do moich danych, jest to prawidłowe rozwiązanie NoSQL.
1
@ JörgWMittag: Nie ma oficjalnej definicji terminu NoSQL, ale zazwyczaj odnosi się do nierelacyjnych systemów baz danych. Backronym „nie tylko Sql” jest tak naprawdę najnowszym retconem, aby przeciwdziałać nieuniknionemu luzowi hype. Ale w powszechnym użyciu NoSQL służy do opisywania systemów takich jak MongoDb, Bigtable itp., Nie mówiąc o samouczku D (który nie jest nawet bazą danych).
JacquesB
2
@ JörgWMittag NoSQL pierwotnie oznaczało „non SQL” lub „non relational”. „Nie tylko SQL” to NOSQL, ponieważ jest akronimem zamiast kombinacji słowa „Nie” i akronimem „SQL”. Stało się popularne jako sprzeczne z ogólną praktyką umieszczania wszystkiego w bazie danych (jak stwierdzono w artykule na Wikipedii). Jak skomentowałeś, pole jest teraz nieco bardziej złożone.
Trisped
Całkowicie się zgadzam. Wydaje się, że głównymi wzorcami NoSQL są składnia dokumentów klucz-wartość (np. Redis) (np. Mongo) i wykres (np. Neo4J). Chciałbym, żeby ludzie porzucili NoSQL i użyli jednego z tych terminów.
paj28
10

Twoje twierdzenia dotyczące relacyjnych baz danych są prawdziwe, aż do momentu, gdy masz tyle danych, że nie możesz już zmieścić ich kopii na jednym serwerze. Potem zaczynasz napotykać różnego rodzaju interesujące problemy. Jak dzielisz swoje tabele, aby większość zapytań mogła być uruchamiana na jednym serwerze? Ile kopii danych wykonujesz? Jak radzisz sobie z niespójnościami między tymi kopiami? Jak przechowywać dane użytkownika w centrum danych, które jest stosunkowo blisko niego geograficznie?

Cele te często są ze sobą sprzeczne. Wielu użytkowników Twittera śledzi ludzi z całego świata. Czy baza danych Twittera powinna być zoptymalizowana geograficznie pod kątem czytania tweetów lub pisania tweetów?

Okazuje się, że mając do czynienia z tego rodzaju skalą, zaczynasz wymyślać rozwiązania, dodawać redundancję i nakładać ograniczenia, które bardzo przypominają bazę danych NoSQL. Jeśli możesz zmieścić wszystkie swoje dane w jednym pudełku, otrzymujesz tylko ograniczenia i nie potrzebujesz korzyści.

Karl Bielefeldt
źródło
Odczytywanie 10 TB do RAM zajmuje trochę czasu @Daniel ... Kilka godzin byłoby całkiem dobrym rezultatem. Sprawiłoby, że powrót do zdrowia po katastrofie byłby katastrofalny.
Ben
1
Powiedziałbym, że Big Data to z pewnością jeden obszar, w którym bazy danych NoSQL wchodzą w grę, ale jest tylko jeden. Istnieje również wiele innych powodów, dla których baza danych NoSQL może lepiej pasować do problemu. Jeśli masz wykresy danych, warto skorzystać z bazy danych grafów, jeśli masz dane XML, warto skorzystać z bazy danych XML. Nie tylko Big Data, ale także model danych jest ważnym kryterium przy wyborze odpowiedniej bazy danych (i oczywiście wiele razy bazy danych SQL są właściwym wyborem, w zależności od problemu)
dirkk
5
To jest źle. Od wielu lat podejście oparte na programowaniu jest standardem w dużych bazach danych, a niektóre bazy danych obsługują klastry z transparentnym udostępnianiem danych (Oracle RAC). Jak myślisz, jak działają wszystkie banki? A przy odpowiedniej konfiguracji RZADKO przywracasz kopie zapasowe - to pozostało jako prawdziwy scenariusz „spalenia 2 centrów danych”. I tak, pracowałem kiedyś nad bazą danych o pojemności 30 TB - nie mieliśmy problemów.
TomTom,
Tak, relacyjne bazy danych wykonują przezroczyste dzielenie i dzielenie danych, ale jest to bardzo nieszczelna abstrakcja, jeśli zależy Ci na optymalizacji wydajności.
Karl Bielefeldt,
5

Bazy danych NoSQL mają bardzo mało wspólnego z „ No SQL”.

Chodzi o przyznanie, że nie można mieć bazy danych na dużą skalę, która jest zawsze spójna i obsługuje złożone transakcje oraz ma trwałość.

W normalnej relacyjnej bazie danych wszystkie indeksy są automatycznie aktualizowane w ramach transakcji, więc można ich używać w dowolnym zapytaniu.

W bazie danych NoSQL programista jest odpowiedzialny za utrzymanie dużej liczby indeksów i zakłada się, że indeksy zawsze będą nieaktualne.

Na przykład:

  • Indeks osób według numeru podatku może zawierać osoby, które nigdy nie ukończą procesu rejestracji w celu uzyskania podatku.
  • Dlatego kod korzystający z indeksu musi być w stanie poradzić sobie z niepełną rejestracją podatku
  • Inną opcją jest posiadanie czasów, kiedy osoba zarejestrowana do celów podatkowych nie znajduje się w indeksie. (Twój projekt musi więc poradzić sobie z brakiem spójnych danych i zdecydować, w jaki sposób dane nie będą spójne).

Jako prawdziwy przykład, Amazon raczej pokaże mi nieaktualny opis książki, niż opóźni wyświetlanie strony internetowej, czekając na 106 komputerów, aby potwierdzić, że została usunięta właściwa blokada.

W związku z tym.....

Jeśli pojedyncza normalna relacyjna baza danych może przechowywać wszystkie dane i przetwarzać każdą transakcję wystarczająco szybko, aby blokowanie nie powstrzymało systemu przed wykonaniem użytecznej pracy, relacyjna baza danych jest najlepszą opcją.

Ale gdy tylko zaczniesz myśleć o korzystaniu z więcej niż jednej relacyjnej bazy danych lub dzieleniu transakcji, aby uniknąć błędów blokowania, zaczynasz szukać sposobu na radzenie sobie z problemami, które napotykasz podczas korzystania z baz danych „NoSQL”.

Ponieważ bazy danych „NoSQL” nie ukrywają tych problemów, mogą stać się najlepszą opcją podczas skalowania systemu. Pamiętaj jednak, że Stackoverflow nadal używa relacyjnej bazy danych do przechowywania wszystkich swoich danych, przy ograniczonym użyciu NoSQL w warstwie buforowania - więc musisz być BARDZO duży, zanim będziesz zmuszony używać NoSQL do przechowywania danych.

Ian
źródło
Ten ostatni smakołyk jest bardzo interesujący - czy masz link do strony z meta SO, aby zainteresowani czytelnicy mogli przejrzeć (nie) użycie SO przez NoSQL? Dzięki!
kcrisman
@kcrisman, patrz highscalability.com/stack-overflow-architecture for exmaple
Ian
2

Relacyjne bazy danych są zoptymalizowane pod kątem skutecznego wyszukiwania dowolnej wartości w bazie danych.

Nie należy mylić możliwości wyszukiwania „dowolnej” wartości z rzędu z „każdą” wartością z rzędu. Najbardziej skuteczny sposób na to wymaga jednego lub więcej indeksów. Możesz mieć indeksy obejmujące wszystkie pola, ale wtedy przeszkadzasz, że możesz wprowadzić zmiany wymagające zmiany indeksu (wstawianie, aktualizacje, usuwanie). Ty (lub Twój DBA) musisz zrozumieć dane, sposób użycia, wąskie gardła itp.

JeffO
źródło
Dobrym przykładem byłoby oszczędzanie czatów. Może zaistnieć potrzeba powiązania ich z niektórymi innymi danymi i przeprowadzania różnego rodzaju analiz, ale podczas samej sesji czatu użytkownicy docenią coś szybszego, co nie ma całego obciążenia RDBMS, takiego jak transakcja lub ograniczenie.
JeffO
-1

Istnieje już wiele odpowiedzi, ale chciałem tylko dodać moje streszczenie.

Najwyraźniej koncepcja NoSQL obejmuje szereg różnych podejść do organizowania danych na dysku, w pamięci i ujawniania ich za pomocą języka zapytań (niektóre są nawet podobne do SQL!). Moim zdaniem siła wynika z różnorodności systemów, dzięki czemu możesz wybrać najlepsze narzędzie do pracy. Ale nadal mam nadzieję, że możesz zaspokoić tuzin różnych potrzeb za pomocą kilku różnych rozwiązań, nie chciałbyś zarządzać tuzinem różnych systemów.

Relacyjne bazy danych mogą zaprowadzić Cię bardzo daleko i są sprawdzoną technologią, ale podobnie jak baza danych możesz wybrać język programowania w oparciu o potrzeby każdego projektu (ale biorąc również pod uwagę doświadczenie zespołu).

NikoNyrh
źródło
-2

Używam couchdb od dwóch lat. Jest najczęściej używany do zarządzania treścią i konfiguracji.

Relacje hierarchiczne są znacznie łatwiejsze do zarządzania, gdy można je wizualizować. W przypadku danych głównie do odczytu łatwiej jest edytować JSON niż w wielu przypadkach napisać instrukcję UPDATE. W rzeczywistości programista nie wymaga edycji JSON. A SQL daje ci wiersze i kolumny, które następnie musisz zamapować na jakąś strukturę obiektową.

Dostajesz także wzrost wydajności, ponieważ nie dołączasz do 10-20 tabel przy złożonych zapytaniach. Widoki Couchdb są bardzo szybkie, ponieważ javascript, na którym są oparte, nie są wykonywane w czasie zapytania.

Większość programistów rozumie Javascript, a większość programistów czasami ma problemy z SQL.

W Couchdb widok może być traktowany jako streszczenie dokumentu JSON. To, jak strukturyzowane są dane widoku, zależy od Ciebie (nie ogranicza Cię oryginalna hierarchia).

Nie użyłbym Couchdb do danych wysoce transakcyjnych, ale w przypadku danych półstatycznych ze strukturą typu częściowego wybuchu praca jest O DUŻO łatwiejsza niż z SQL.

Należy jednak pamiętać, że nie ma wyraźnej „normalizacji”, którą można zastosować (chociaż unikanie powielania danych jest godnym celem), i istnieje zasadniczo „optymistyczna” strategia aktualizacji podobna do optymistycznego blokowania.

Jeff Lowery
źródło