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?

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.

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).

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.

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.

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.

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.

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.

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).

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.