Czy jest coś przełomowego w NoSQL? [Zamknięte]

46

Jestem bardzo solidnym facetem z relacyjnymi bazami danych i rozumiem aż do trzeciej normalnej postaci, doceniam algebraiczne podstawy teorii SQL i mogę prawdopodobnie powiązać złamane serce (lub nie).

Nie opracowałem struktury relacyjnej bazy danych NA randki z żoną, ale myślałem o projektach relacyjnej bazy danych na randkach z żoną.

Teraz słyszę o NoSQL i badam go. Przechodząc do sedna sprawy, czy jest coś w NoSQL, co jest przełomowe, matematycznie powieściowe lub „hej, nawet nie musisz tak naprawdę porządkować swoich danych w relacji, to jest o wiele łatwiejsze” podejście?

Czy NoSQL jest jak super powłoka struktury danych? Moim zdaniem dane muszą mieć ostatecznie strukturę do pobrania, a pobieranie musi być zdefiniowane w jakimś języku.

Samuel Fullman
źródło
2
Jakie typy baz danych NoSQL nie mają struktury? Bazy danych dokumentów mogą być hierarchiczne, ale minimalnie przechowują swoje dane w dokumentach zawierających dane w pewnym formacie. Bazy danych z wykresami i magazyny kluczowych wartości są raczej oczywiste. Jakie bazy danych NoSQL nie mają języka do zapytania? Niektóre bazy danych dokumentów to po prostu wyszukiwanie tekstowe lub XQuery dla XML, jako dwa przykłady. SPARQL jest używany dla sklepów RDF.
Thomas Owens
2
Aktualizacja dla „Myślałem o relacyjnych projektach baz danych na randki z żoną w nocy…” :) LOL. Dobre pytanie też.
Rocklan
2
Bazy danych NoSQL mają strukturę, ale struktura nie zawsze jest łatwa do mapowania na algebrę relacyjną. Różne NoSQL używa różnych struktur, niektóre z nich to mapy wartości klucza, hierarchiczna, obiektowa baza danych, baza danych grafów lub magazyn dokumentów to popularne typy NoSQL. Wszystko, czym tak naprawdę jest NoSQL, to świadomość, że SQL nie jest panaceum, że niektóre problematyczne domeny źle odwzorowują algebrę SQL / relacyjną.
Lie Ryan,
7
NoSQL to myląca nazwa. Sugeruje to grupę z cechami, a jedyną wspólną cechą nie jest klasyczna relacyjna baza danych SQL. To otwarty zestaw. To tak, jakby opisywać każde jedzenie, które nie jest chlebem, jako „rodzinę bez chleba”.
Pieter B
2
Ok, o co tyle zamieszania w NoSQL? To proste: mieliśmy pokolenie ludzi, którzy dorastali z relacyjnymi bazami danych i było to jedyne narzędzie, jakie mieli. Ponieważ jeśli masz tylko młotek, wszystko staje się gwoździem. Potem powstają brzydkie rzeczy, takie jak próba umieszczenia obiektów w relacyjnej bazie danych lub zbudowanie wyszukiwarki. Wielką realizacją było to, że: baza danych SQL nadaje się do wielu rzeczy, ale nie do wszystkiego. „nie wszystko” jest najważniejsze.
Pieter B

Odpowiedzi:

24

NoSQL jest bardziej ewolucyjny niż rewolucyjny. Zasadniczo łączy istniejące idee „zewnętrznego przechowywania danych” z „korzystaniem ze znanych struktur danych, a nie tabel relacyjnych”.

Istnieje więcej rodzajów baz danych niż relacyjne, na przykład hierarchiczne bazy danych . Choć archaiczny według dzisiejszych standardów, bardzo dobrze zazębiał się ze strukturami danych swoich danych (np. Rekordy COBOL ). Chodzi o to, że dane w bazie danych zostały dokładnie modelowane do tego, jak zostały utworzone rekordy w językach programowania, które ich używały.

Szybko przejdź do wynalezienia relacyjnych baz danych , w których baza danych ostatecznie rozdzieliła obawy i, przy odpowiedniej normalizacji, jest doskonałym sposobem na wizualizację większości typów danych i relacji między danymi. Jest naprawdę łatwy do zrozumienia w porównaniu z innymi typami baz danych. Tym, co kompletnie zawodzi, jest jednak przechowywanie danych w sposób, który odzwierciedla obiekty i klasy w programie. Stąd wynalazek mapowania obiektowo-relacyjnego . Innymi słowy, projekt bazy danych jest w rzeczywistości przeszkodą w projektowaniu programu, który z niej korzysta, dlatego potrzebujemy bibliotek ORM, takich jak Hibernacja. Choć czyste i konsekwentne, zawsze mam w głowie tę wątpliwą wątpliwość, że coś nie jest w porządku.

Doprowadziło to do powstania jeszcze dwóch rodzajów baz danych, baz danych obiektów i NoSQL .

Obie próbują rozwiązać problemy wprowadzone przez relacyjne bazy danych, nie narażając nas jednak na przerażające horrory hierarchicznych baz danych. Dane są nadal przechowywane w repozytoriach, które niejasno przypominają tabele, ale w rzeczywistości bardziej przypominają programowanie struktur danych niż tabele relacyjne. Podczas gdy obiektowe bazy danych przestrzegają głównie dobrze zdefiniowanych reguł, rozumiem, że NoSQL jest raczej arbitralny. Na przykład tabela może być wizualizowana jako tabela mieszająca lub tablica. Nie ma łatwego, dobrze zdefiniowanego sposobu na ich zapytanie za pomocą dowolnego narzędzia analogicznego do Oracle SQL Developer lub SQL Server Management Studio .

Chodzi o to, że można zdefiniować struktury danych, które można łatwo przeszukiwać w kodzie, zamiast składać zapytania SQL, które lepiej pasują do silnika bazy danych SQL, niż wyrażać pożądane przez siebie zapytanie. Na przykład dopasowania rozmyte lub częściowe są trudniejsze i działają gorzej w relacyjnej bazie danych, podczas gdy baza danych NoSQL może mieć strukturę zoptymalizowaną do takiego wyszukiwania i kończy się w ułamku czasu.

Istnieją języki do wysyłania zapytań do NoSQL. Nie ma jednak uniwersalnego języka, takiego jak SQL dla relacyjnych baz danych.


Późna edycja:

Chociaż jestem wystarczająco zaznajomiony z bazami danych NoSQL, to pytanie było dla mnie impulsem do zakupu wysokiej jakości książki na ten temat i do przeczytania jej z ostatecznym celem bycia prawdziwym ekspertem w tej dziedzinie. Pozostałe komentarze są oparte na NoSQL destylowanej: krótki przewodnik po Emerging World of Polyglot Trwałość przez Pramod Sadalage i Martin Fowler .

Autorzy twierdzą, że relacyjne bazy danych nie skalują się dobrze do klastrów zdolnych do obsługi danych potrzebnych dla witryn takich jak Amazon i Google: NoSQL został opracowany, aby pasować do tej niszy, rozluźniając współbieżność i trwałość w ACID w celu obsługi dużej liczby zapytań, które w dużej mierze wykorzystują dane statyczne (stąd transakcje ACID nie są tak ważne).

Ponadto zakładają, że bazy danych NoSQL działają bez schematu (strona 10), który pozwala bazom danych NoSQL na łatwiejszą modyfikację struktury danych. Nie jestem pewien, czy obecność lub brak formalnego schematu ma w tym względzie znaczenie, ponieważ bazy danych SQL pozwalają również modyfikować schematy. Niezależnie od tego dwaj uznani autorzy przedstawiają to twierdzenie, dlatego warto je przeanalizować.

Wierzę, że oba te główne punkty służą jedynie do egzekwowania mojego głównego punktu, że NoSQL jest ewolucyjny, a nie rewolucyjny. Nadal przechowują dane i dokonują stopniowych ulepszeń skali i możliwości modyfikacji. Wskazują również, że NoSQL nie dąży do uzurpacji relacyjnych baz danych jako króla przechowywania danych, a jedynie do zapewnienia alternatywnych sposobów przechowywania danych dla typów danych, które muszą być skalowane i przekształcane w sposób (ich zdaniem) relacyjny bazy danych nie obsługują wystarczająco dobrze.


źródło
2
Niektóre bazy danych NoSQL mają język zapytań. Użyłem XQuery i SPARQL wcześniej, jeśli dane są przechowywane w formacie XML lub RDF. Języki te mają zwykle strukturę i zapytania. Ale z drugiej strony dotyczy to tylko baz danych NoSQL, które zawierają dobrze zdefiniowane formaty danych i niewiele robią dla par tekstowych lub par klucz-wartość.
Thomas Owens
@ThomasOwens Zredagowałem swoją odpowiedź, aby być bardziej szczegółowym.
1
Jest to interesujący przegląd NoSQL, ale tak naprawdę nie odpowiada na rzeczywiste pytanie. O ile mogę powiedzieć, jedyną „przełomową” cechą NoSQL jest to, że twoje dane nie muszą być zgodne z określoną strukturą przed przechowywaniem.
Rocklan
2
In other words, the design of the database is actually a hindrance to the design of the program that uses it, ...Mam wrażenie, że w wielu przypadkach stawia wózek przed koniem. Dla dużych firm z dużymi zestawami danych dane są niezwykle cenne i będą dostępne przez bardzo, bardzo długi czas - dłużej niż obecne popularne języki programowania, narzędzia i paradygmaty. Bardziej trafne może być stwierdzenie, że OOP stanowi przeszkodę w projektowaniu bazy danych, a próba zmiany projektu bazy danych w celu dopasowania do paradygmatu programowania może nie być najlepszym pomysłem.
Doval,
2
Po prostu zaznaczę, że wszyscy nadal dość mocno używamy jednej heirarchicznej implementacji bazy danych - nazywa się to systemem plików.
Wyatt Barnett,
13

Myślę, że zdecydowanie chciałbyś spojrzeć na ten artykuł Erika Meijera i Gavina Biermana, zatytułowany „Wbrew powszechnemu przekonaniu, SQL i NoSQL to tak naprawdę tylko dwie strony tej samej monety” . Krótko mówiąc, twierdzi, że matematycznie oba podejścia opierają się na tej samej teorii, ale z pewnymi różnicami.

Moim zdaniem kilka interesujących różnic jest następujące: kierunek zależności między typami (FK w SQL) jest odwrotny w SQL i NoSQL, a typ kolekcji nie jest ograniczony do zestawu w NoSQL (a zatem niektórych operacji teoretycznych może już nie mieć zastosowania w świecie NoSQL, ale niektóre inne są nadal aktualne). Kolejnym interesującym punktem tego artykułu jest zaproponowany język zapytań do przeszukiwania baz danych SQL i NoSQL. Nazywa się LINQ, a jeśli uważasz, że mogłeś już słyszeć tę nazwę, masz rację: to język zapytań Microsoftu z C #.

Haspemulator
źródło
1
„Kolejnym interesującym punktem tego artykułu jest zaproponowany język zapytań do zapytań zarówno do baz danych SQL, jak i NoSQL. Nazywa się to LINQ”, co nie jest do końca prawdą, „Linq” nie jest odwzorowalny na SQL w sposób 1: 1, więc tłumaczenie musi wystąpić, aby działał na SQL DB. Co oznacza, że wszystko może być wprowadzany do kwerendy zarówno, jak długo istnieje warstwa tłumaczenie upewniając się, że działa na docelowym DB
Frans Bouma
6
Cóż, można argumentować, że SQL również nie jest wykonywany bezpośrednio w bazie danych. To, co jest wykonywane, to plan wykonania i można również argumentować, że Linq można przełożyć bezpośrednio na plan wykonania. W końcu nie ma dużej różnicy.
Haspemulator
10

Odpowiedź Snowmana poprawnie opisuje, w jaki sposób SQL i NoSQL różnią się strukturami danych i w jaki sposób są one dostępne. Jednak prawdopodobnie jeszcze ważniejszą różnicą jest ich dziedzina problemowa.

NoSQL nie jest następcą SQL. Przeciwnie, różne gałęzie NoSQL poświęcić pewne cechy SQL, aby być lepiej na innych . Twierdzenie CAP stwierdza, że ​​żaden system rozproszonej bazy danych nie jest w stanie spełnić wszystkich następujących właściwości:

  • Konsystencja
  • Dostępność
  • Tolerancja podziału

Dlatego niektóre warianty NoSQL są zgodne z zasadą BASE , która rozluźnia zawsze zawsze pełną zgodność ACID , która jest podstawą klasycznych baz danych SQL. Tracąc niektóre gwarancje spójności, zyskują możliwość połączenia wysokiej dostępności i tolerancji partycji w szeroko rozpowszechnionych systemach, takich jak strony internetowe z dużą ilością danych i zapytań użytkowników, ale niewielkie zapotrzebowanie na idealną spójność. Tak więc takie bazy danych NoSQL są sercem Google , Facebooka i Amazon . Tak więc, aby odpowiedzieć na twoje pytanie: Tak, NoSQL jest przełomowy pod tym względem, że w zasadzie umożliwia korzystanie z tak ogromnych usług internetowych.

To tylko jeden przykład, ponieważ NoSQL jest różnorodną dziedziną, a jego warianty obejmują prawie wszystkie możliwe kombinacje parametrów w trójkącie CAP .

Florian von Stosch
źródło
Nie znam ElasticSearch. Szukaj w Google wydaje się pokazać, że sacrificies konsystencja (C), a zatem jest AP, nie CAP, który jest teoretycznie niemożliwe. Edycja: Było to w odpowiedzi na już nieistniejący komentarz sugerujący, że ElasticSearch spełnia wszystkie właściwości CAP.
Florian von Stosch,
3
Och, jak słodko, poszli z BASE, aby przeciwdziałać kwasowi. Czy istnieje podejście pośrednie zwane REDOX lub SALT?
Patrick M
3

Typowe przypadki użycia NoSQL są przełomowe pod względem wzrostu wydajności w porównaniu do popularnych baz danych opartych na SQL. Jest w tym kilka czynników.

Jednym z nich jest sprzątanie. Większość NoSQL jest oprogramowaniem typu open source i można je zainstalować na stacji roboczej lub maszynie wirtualnej za pomocą kilku poleceń i pracować z rozsądnymi ustawieniami domyślnymi po wyjęciu z pudełka. Z mojego doświadczenia wynika, że ​​nawet Postgres i MySQL nie są takie; Konfiguracja jest zwykle konieczna, aby rozpocząć pracę nawet na stacji roboczej w celach programistycznych.

Kolejnym jest wygodny rozwój, jak szczegółowo opisano inne odpowiedzi. Możliwości indeksowania JSON w Mongo lub semantyka klucza / wartości redis i Riak mogą być pewnymi aplikacjami internetowymi potrzebnymi do wykonania zadania, a interfejsy API są łatwe. Niektóre biblioteki NoSQL zapewniają własne interfejsy API RESTful, natomiast w języku SQL zwykle trzeba je pisać samodzielnie.

Te czynniki sprawiają, że bazy danych NoSQL są atrakcyjne dla małych projektów. Czas odbioru jest zazwyczaj niski. Pewnie, kiedy idziesz do produkcji, musisz skonfigurować bezpieczeństwo i skalować, ale możliwość szybkiego kodowania i współpracy jest potężna i, jak twierdzę, przełomowa.

Ponadto, w związku z powyższym, w przypadku aplikacji na małą skalę (takich jak wewnętrzne usługi firmy lub usługi aplikacji do aplikacji) zespół może być w stanie znieść produkcyjną bazę danych NoSQL bez angażowania swoich zespołów DBA i bez pogorszenia wydajności lub integralności problemy w wyniku. Profesjonalnym DBA może się to nie podobać, ale programiści, którzy postrzegają DBA jako źródło przeszkód (dobre lub złe), czasami postrzegają NoSQL jako sposób na obejście się z nimi. Przyznaję się do tego - kiedyś zmieniłem niewielką aplikację z Postgres na SQLite, aby wyciąć przeciwny DBA, i zdecydowałem się wdrożyć na Mongo zamiast Oracle, aby uniknąć procesów zatwierdzania DBA i ograniczeń dostępu. Bez żadnego negatywnego wpływu w obu przypadkach.

jagoda
źródło