Jakie są różnice między NoSQL a tradycyjnym RDBMS?

71

Jakie są różnice między NoSQL a tradycyjnym RDBMS?

W ciągu ostatnich kilku miesięcy NoSQL był często wymieniany w wiadomościach technicznych. Jakie są jego najważniejsze cechy w stosunku do tradycyjnego RDBMS? Na jakim poziomie (fizycznym, logicznym) występują różnice?

Gdzie są najlepsze miejsca do korzystania z NoSQL? Dlaczego?

Spredzy
źródło

Odpowiedzi:

61

NoSQL oznacza „nie tylko SQL” i zwykle oznacza, że ​​baza danych nie jest relacyjną bazą danych, która była bardzo popularna w ostatnich dziesięcioleciach.

Powodem, dla którego NoSQL był tak popularny w ciągu ostatnich kilku lat, jest głównie to, że gdy relacyjna baza danych wyrasta z jednego serwera, nie jest już tak łatwa w użyciu. Innymi słowy, nie skalują się zbyt dobrze w systemie rozproszonym. Wszystkie duże witryny, o których wspominałeś Google, Yahoo, Facebook i Amazon (niewiele wiem o Digg), zawierają wiele danych i przechowują je w systemach rozproszonych z kilku powodów. Możliwe, że dane nie mieszczą się na jednym serwerze lub istnieją wymagania dotyczące wysokiej dostępności .

Twierdzenie CAP

Właściwości systemu rozproszonego można opisać twierdzeniem CAP . Z trzech właściwości możesz mieć tylko dwie:

  • C GODNOŚĆ
  • vailability
  • tolerancja na sieci P artitioning

Amazon Dynamo używa Ostatecznej spójności, aby zbliżyć się do wszystkich trzech właściwości. Artykuł Dynamo: sklep Amazon o wysokiej dostępności, którego wartość jest kluczowa, jest wart przeczytania podczas poznawania baz danych NoSQL i systemów rozproszonych. Amazon Dynamo ma właściwości A i P.

Google ma inne podejście do BigTable , który ma właściwości C i A.

Inne bazy danych NoSQL

Jak napisałem na początku, istnieje wiele innych rodzajów baz danych NoSQL, które są zaprojektowane dla różnych wymagań. Wykres baz danych np jak Neo4j , bazy danych dokumentów, jak CouchDB i multimodel / przedmiot baz danych, takich jak OrientDB .

Na koniec chciałbym powiedzieć, że relacyjne bazy danych pozostaną popularne. Są bardzo elastyczne i łatwe w utrzymaniu. Ale nie zawsze są najlepszym wyborem.

Jonas
źródło
1
Dobra, wyczerpująca odpowiedź.
TML
NoSQL NIE oznacza nierelacyjnych, oznacza po prostu coś innego niż SQL DBMS.
nvogel
1
Wygląda na to, że na ostatniej konferencji O'Reilly Strata Mark Madsen wymyślił nową interpretację „NoSQL” w swojej historii baz danych w celu zastąpienia „Nie tylko SQL”. Teraz jest: „Nie, SQL” ;-)
Lukas Eder
6
„Nie tylko” było modernizacją, wczesny ruch NoSQL był wściekły przeciwko relacyjnym bazom danych. Potem uderzyli w prawdziwy świat.
Gajusz
22

NoSQL jest bardzo szerokim terminem i zwykle jest określany jako „Nie tylko SQL”. Termin traci popularność w społeczności spoza RDBMS.

Przekonasz się, że baza danych NoSQL ma kilka wspólnych cech. Można je z grubsza podzielić na kilka kategorii:

  • magazyny kluczy / wartości
  • Bazy danych inspirowane Bigtable (na podstawie dokumentu Google Bigtable)
  • Bazy danych inspirowane dynamem
  • rozproszone bazy danych
  • bazy danych dokumentów

To ogromne pytanie, ale dość dobrze na nie odpowiedzieliśmy w tym badaniu rozproszonych baz danych .

Krótka odpowiedź:

Bazy danych NoSQL mogą zrezygnować z różnych części ACID, aby osiągnąć pewne inne korzyści - tolerancję partycji, wydajność, rozkład obciążenia lub skalowanie liniowe z dodatkiem nowego sprzętu.

Jeśli chodzi o czas ich użycia - zależy to całkowicie od potrzeb Twojej aplikacji.

Jeremiasz Peschka
źródło
12

NoSQL jest rodzajem bazy danych, która nie ma ustalonego schematu, jak tradycyjne RDBMS. W przypadku baz danych NoSQL schemat jest definiowany przez programistę w czasie wykonywania. Nie piszą normalnych instrukcji SQL dla bazy danych, ale zamiast tego używają interfejsu API, aby uzyskać potrzebne dane. Bazy danych NoSQL można zwykle łatwo skalować na różnych serwerach fizycznych, bez konieczności dowiedzenia się, na którym serwerze znajdują się poszukiwane dane.

Istnieją jednak pewne kompromisy za całą tę elastyczność: w bazach danych NoSQL brakuje dość funkcji w porównaniu z systemami RDBMS, takimi jak SQL Server, Oracle, DB2, MySQL itp. Nie ma brokera usług, rejestrowania transakcji, pakietów ETL itp.

NoSQL nie jest czymś nowym. Istnieje już od 50 do 60 lat. Wtedy nazywał się COBOL. Dokładnie ten sam pomysł, wpadła na to inna grupa.

mrdenny
źródło
3
Punkt 1 jest niepoprawny dla wielu (wszystkich?) Baz danych NoSQL, chyba że wyraźnie powiedziałeś bazie danych, że nie obchodzi Cię, czy zapis zakończy się powodzeniem. Np. Dowolna baza danych wspierana przez Hadoop zapisze dane w trzech lokalizacjach: piekło lub woda. Domyślnie Cassandra napisze w trzech lokalizacjach i potwierdzi zapis jako udany, gdy dwa się powiedzie.
Jeremiasz Peschka
3
Jak obsługuje współbieżność podczas wykonywania tych aktualizacji? Czy istnieje transakcja typu rozproszonego, która przechodzi między nimi, czy też zapis jest potwierdzany ręcznie, a serwery obsługują resztę w tle?
mrdenny,
Współbieżność zależy całkowicie od implementacji. Riak używa zegarów wektorowych, aby zapewnić współbieżność, aw przypadku sprzecznych zapisów można je zwrócić do aplikacji wywołującej w celu rozwiązania problemu. Inni używają wygranych z ostatniego zapisu.
Jeremiah Peschka
Jeśli chodzi o potwierdzenie zapisu - w większości przypadków zapisy nie są potwierdzane, dopóki system operacyjny nie potwierdzi zapisu. Możesz nawet posunąć się do żądania potwierdzenia trwałych zapisów, co oznacza, że ​​bity są faktycznie opróżniane na dysk zamiast w buforze systemu operacyjnego. MongoDB domyślnie przyjmuje zapisy do pamięci, ale można je skonfigurować tak, aby wymagały potwierdzenia zapisu na dysk. Replikacja jest obsługiwana inaczej dla każdego produktu. Dzięki Hadoop klient zapisuje na serwerze A, który zapisuje na B, który zapisuje na C. Gdy C odpowie, zapis jest zakończony, a klient otrzymuje potwierdzenie zapisu.
Jeremiah Peschka
W takim razie stoję skorygowany. Usunąłem nieprawidłowe oświadczenie. Czy FUBAR coś jeszcze?
mrdenny,
6

Zasadniczo zrezygnowanie z konfiguracji relacyjnej, z kluczami głównymi i obcymi oraz z dodatkowym kosztem związanym z utrzymaniem bezpieczeństwa transakcji, często zapewnia ekstremalny wzrost wydajności. Jednak nie jest to unikalne w przypadku nowych baz danych / magazynów danych, ponieważ np. MySQL został dostrojony do działania na „poziomach NoSQL” z pominięciem warstw.

Krótko mówiąc, często możesz uzyskać imponującą wydajność, jeśli nie masz nic przeciwko ryzyku utraty danych. Większość systemów NoSQL to robi. Np. MongoDB umożliwia zapisywanie zmian danych, gdy jest to wygodne. Same dane są bezpieczne i zabezpieczone transakcyjnie, ale przechowywane w nietrwałej pamięci (pamięci). Jeśli stracisz moc, nie możesz być w 100% pewien, że nie straciłeś danych lub że nie masz uszkodzonych danych.

Jest to kompromis między bezpieczeństwem a wydajnością.

Johanna Larsson
źródło
5

Dobrym miejscem na początek jest wpis w Wikipedii . Zasadniczo zamiast tego powiązać dane w jednej tabeli z drugą, przechowujesz rzeczy jako pary klucz-wartość i nie ma schematu bazy danych, zamiast tego jest obsługiwany w kodzie.

Kilka witryn używa jednocześnie NoSQL i typowych serwerów RDBMS, ale do przechowywania różnych danych. Więc nie musisz wybierać jednego lub drugiego.

steve.lippert
źródło
Fakt, że na większość tego pytania można odpowiedzieć, przechodząc do WP, sprawia, że ​​pocieram brodę, gdy zastanawiam się nad odpowiedziami tutaj. Myślę, że to trochę zbyt „pytanie uzupełniające”, ale to naprawdę wszystko, co mamy teraz.
jcolebrand
1
Ważną kwestią jest to, że unikanie obsługi relacji (klucza obcego) w infrastrukturze bazy danych / serwera uwalnia bazę danych / serwery od obciążenia i obciążenia związanego z zarządzaniem blokadami związanymi z utrzymywaniem integralności referencyjnej. Konsekwencją tego, kompromisu, jest to, że integralność referencyjna, spójność i inne obawy ACID są następnie wypychane do aplikacji. Wiele aplikacji korzysta z tego, a nie jest przez to ograniczone. (Niektóre aplikacje muszą zostać zaklinowane w modelu klient / serwer).
Jim Dennis
0

Ciężko pracowałem nad bazą danych MongoDB NoSQL i Oracle.

Schemat

Baza danych SQL ma własny predefiniowany schemat do przechowywania danych strukturalnych.

W bazie danych NoSQL nie ma predefiniowanego schematu, tutaj schemat jest najbardziej dynamicznym elementem opartym na elementach danych.

Skalowalność

Bazy danych SQL są skalowalne w pionie, co oznacza, że ​​jeśli chcemy skalować bazę danych SQL, musimy wzmocnić sprzęt, na którym zainstalowany jest system DBMS. W tym przypadku czasami ogranicza się skalowalność.

Bazy danych NoSQL są skalowalne w poziomie, co oznacza, że ​​jeśli chcemy je skalować, musimy dodać więcej węzłów i stworzyć sieć dystrybucji w oparciu o nasze własne potrzeby i wymaganą moc. W ten sposób zmniejszają obciążenie bazy danych

Odzyskiwanie danych

W bazach danych opartych na SQL do definiowania i manipulowania danymi możemy używać SQL (Structured Query Language), który jest obecnie bardzo wydajny.

Jeśli chodzi o bazę danych NoSQL, zapytania koncentrują się na zbiorze i dokumentach. Czasami nazywa się to UnQL (Unstructured Query Language). Jest to wciąż w fazie ewolucji, więc różni się od dostawcy do bazy danych NoSQL.

Aby uzyskać więcej informacji na temat kluczowych różnic, mój blog: Różnica między bazą danych SQL i NoSQL

Virat Gaywala
źródło