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

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.

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.

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

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 .

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.