dlaczego bazy danych noSQL są bardziej skalowalne niż SQL?

98

Ostatnio dużo czytałem o DBMS noSQL. Rozumiem twierdzenie CAP , reguły ACID, reguły BASE i podstawową teorię. Ale nie znalazłem żadnych zasobów na temat tego, dlaczego noSQL jest łatwiejszy do skalowania niż RDBMS (np. W przypadku systemu, który wymaga wielu serwerów DB)?

Myślę, że utrzymanie ograniczeń i kluczy obcych kosztuje zasoby, a kiedy DBMS jest dystrybuowany, jest to o wiele bardziej skomplikowane. Ale spodziewam się, że jest o wiele więcej.

Czy ktoś może wyjaśnić, w jaki sposób noSQL / SQL wpływa na skalowalność?

ducin
źródło
7
„Wydaje mi się, że utrzymanie ograniczeń i kluczy obcych kosztuje zasoby, a kiedy DBMS jest dystrybuowany, jest to o wiele bardziej skomplikowane. Ale spodziewam się, że jest o wiele więcej”. - Właściwie to tyle. Dokładniej, jest to jedna wspólna cecha, która sprawia, że ​​większość rozwiązań NoSQL jest bardziej skalowalna niż ich kuzyni SQL (dla niektórych modeli danych). Ale NoSQL jest bardzo niejasnym terminem, różne rodziny baz danych NoSQL mają różne cechy, które czynią je bardziej skalowalnymi.
yannis
8
Oczywiście bazy danych SQL doskonale skalują się do trylionów rekordów, potrzebują jedynie specjalistycznej wiedzy, aby zaprojektować i skonfigurować je, czego nie mają twórcy aplikacji. I ogólnie dość drogi zestaw sprzętu i licencji.
HLGEM
6
Moim zdaniem pytanie to nie jest duplikatem żadnego z nich. Pytanie mongodb to (oprócz złego tytułu, który wydaje się bardziej szczegółowy) zadawanie czegoś innego, co w rzeczywistości jest bardziej ogólne. Zagłosowano ponownie otworzyć.
Joeri Sebrechts

Odpowiedzi:

77

Bazy danych noSQL dają ogromną funkcjonalność, jaką daje baza SQL z samej swojej natury.

Rzeczy takie jak automatyczne wymuszanie integralności referencyjnej, transakcje itp. Są to wszystkie rzeczy, które są bardzo przydatne w przypadku niektórych problemów i które wymagają kilku interesujących technik skalowania poza jednym serwerem (zastanów się, co się stanie, jeśli musisz zablokować dwa tabele dla transakcji atomowej i znajdują się na różnych serwerach!).

Bazy danych noSQL nie mają tego wszystkiego. Jeśli potrzebujesz takich rzeczy, musisz zrobić to sam, ale jeśli NIE JESTEŚ potrzebny (a jest wiele aplikacji, które tego nie robią), to dlaczego chłopcze, masz szczęście. DB nie musi wykonywać wszystkich tych skomplikowanych operacji i blokować wielu zbiorów danych, więc naprawdę łatwo jest podzielić tę partycję na wiele serwerów / dysków / cokolwiek i sprawić, by działała naprawdę szybko.

Michael Kohne
źródło
2
Nie wiedziałem, że to takie proste
Abdul,
7
ta zaakceptowana odpowiedź zupełnie nie wspomina o możliwości dzielenia NoSQL, której brakuje w SQL. Sharding sprawia, że ​​NoSQL jest skalowalny poziomo.
hyankov,
8
@HristoYankov I to działa, ponieważ system NoSQL nie robi wszystkich rzeczy, które nie działają dobrze z shardingiem.
immibis
1
@HristoYankov: Baza danych SQL może być dzielona poziomo i nie wszystkie bazy danych NoSQL można łatwo dzielić poziomo. Sharding nie jest tak naprawdę powodem, dla którego chcesz używać NoSQL.
Lie Ryan,
@HristoYankov Zaakceptowana odpowiedź jest o jeden poziom głębsza niż twoja uwaga „całkowicie nie wspominając o możliwości dzielenia NoSQL, której brakuje w SQL”. Przyjęta odpowiedź słusznie mówi o tym, DLACZEGO dzielenie na poziomy jest trudniejsze w przypadku baz danych SQL. Właściwie spędziłem dobre 20 minut na szukaniu odpowiedzi na to pytanie i prawie wszyscy po prostu wprowadzają „ohh NoSQL shards better”, nie podając żadnego powodu. Całkowicie bezużyteczna odpowiedź. Przyjęte tutaj odpowiedzi doskonale odpowiadają na pytanie - choć bardzo krótko. Byłoby miło mieć także więcej powodów.
Phoeniyx
175

Nie chodzi o NoSQL kontra SQL, chodzi o BASE vs ACID.

Skalowalny musi zostać rozbity na składniki:

  • Skalowanie odczytu = obsługa większej liczby operacji odczytu
  • Skalowanie zapisu = obsługa większej liczby operacji zapisu

Bazy danych zgodne z ACID (takie jak tradycyjne RDBMS) mogą skalować odczyty. Nie są one z natury mniej wydajne niż bazy danych NoSQL, ponieważ (możliwe) wąskie gardła wydajności są wprowadzane przez rzeczy, których NoSQL (czasami) brakuje (jak sprzężenia i ograniczenia), których nie można użyć. Klastrowy SQL RDBMS może skalować odczyty, wprowadzając dodatkowe węzły w klastrze. Istnieją ograniczenia co do skalowania operacji odczytu, ale są one narzucone przez trudność skalowania zapisu podczas wprowadzania większej liczby węzłów do klastra.

Skalowanie zapisu jest miejscem, w którym rzeczy stają się owłosione. Istnieją różne ograniczenia nałożone przez zasadę ACID, których nie widać w ostatecznie spójnych architekturach (BASE):

  • Atomowość oznacza, że ​​transakcje muszą zostać sfinalizowane lub zakończyć się niepowodzeniem jako całość, dlatego należy dużo zaksięgować, aby to zagwarantować.
  • Ograniczenia spójności oznaczają, że wszystkie węzły w klastrze muszą być identyczne. Jeśli piszesz do jednego węzła, ten zapis musi zostać skopiowany do wszystkich innych węzłów przed zwróceniem odpowiedzi do klienta. To sprawia, że ​​tradycyjny klaster RDBMS jest trudny do skalowania.
  • Ograniczenia dotyczące trwałości oznaczają, że aby nigdy nie utracić zapisu, należy upewnić się, że przed zwróceniem odpowiedzi klientowi zapis został wypłukany na dysk.

Aby skalować operacje zapisu lub liczbę węzłów w klastrze poza pewien punkt, musisz być w stanie rozluźnić niektóre wymagania ACID:

  • Upuszczenie Atomowości pozwala skrócić czas, przez który tabele (zestawy danych) są zablokowane. Przykład: MongoDB, CouchDB.
  • Porzucenie spójności pozwala skalować zapisy między węzłami klastra. Przykłady: riak, cassandra.
  • Upuszczanie Trwałość pozwala reagować na polecenia zapisu bez opróżniania dysku. Przykłady: memcache, redis.

Bazy danych NoSQL zwykle stosują model BASE zamiast modelu ACID. Porzucają wymagania A, C i / lub D, aw zamian poprawiają skalowalność. Niektóre, takie jak Cassandra, pozwalają ci korzystać z gwarancji ACID, kiedy ich potrzebujesz. Jednak nie wszystkie bazy danych NoSQL są przez cały czas bardziej skalowalne.

SQL API nie ma mechanizmu opisywania zapytań, w których wymagania ACID są złagodzone. Dlatego wszystkie bazy danych BASE są NoSQL.

Osobista uwaga: ostatnią kwestią, którą chciałbym poruszyć, jest to, że w większości przypadków, gdy NoSQL jest obecnie używany do poprawy wydajności, możliwe byłoby rozwiązanie na właściwym RDBMS przy użyciu poprawnie znormalizowanego schematu z odpowiednimi indeksami. Jak udowodniła ta sama witryna (obsługiwana przez MS SQL Server), RDBMS może skalować się do dużych obciążeń, jeśli odpowiednio je wykorzystasz. Ludzie, którzy nie rozumieją, jak zoptymalizować RDBMS, powinni trzymać się z dala od NoSQL, ponieważ nie rozumieją, jakie ryzyko podejmują ze swoimi danymi.

Aktualizacja (17.09.2019):

Krajobraz baz danych ewoluował od opublikowania tej odpowiedzi. Chociaż wciąż istnieje dychotomia między światem ACID RDBMS a światem BASE NoSQL, linia stała się bardziej niewyraźna. Bazy danych NoSQL dodają funkcje ze świata RDBMS, takie jak SQL API i obsługa transakcji. Obecnie istnieją nawet bazy danych, które obiecują skalowanie SQL, ACID i zapisu, takie jak Google Cloud Spanner, YugabyteDB lub CockroachDB. Zazwyczaj diabeł tkwi w szczegółach, ale dla większości celów są one „wystarczająco KWASOWE”. Aby głębiej zapoznać się z technologią baz danych i jej ewolucją, możesz zapoznać się z tym pokładem slajdów (notatki ze slajdami mają dołączone wyjaśnienie).

Joeri Sebrechts
źródło
Chociaż zgadzam się, że niektóre sklepy NoSQL zastępują ACID na BASE, nadal nie jest to wspólna cecha wszystkich sklepów należących do „kategorii” NoSQL, która jest źle zdefiniowana. Po pewnym czasie interpretacja tego terminu zmieniła się z „No SQL” na „Not Only SQL”, ale ponieważ wiele takich baz danych nadal łączy JOIN lub zaczęło implementować dialekty SQLesque, Mark Madsen ponownie nadał temu terminowi znaczenie jego historia baz danych w notacji : „Nie, SQL” ;-)
Lukas Eder
2
Aby uniknąć dołączeń, będziemy mieć znormalizowane dane w NoSQL, co prowadzi do powtórzeń i większej ilości miejsca. Ale to samo można osiągnąć w RDBMS, jeśli jesteśmy w porządku z dezormalizacją. Zatem „Złączenia” lub „brak połączeń” zależą od DBA, a nie od typu bazy danych. Poprawne
Kaushik Lele
2
@dynamic Witryny te używają intensywnego buforowania lub dzielą się na fragmenty. Te projekty stawiają złożoność skalowania danych poza db. Równie dobrze możesz użyć nosql w takim przypadku, ponieważ to właśnie powoduje kompromis nosql.
Joeri Sebrechts
1
„SQL API nie ma mechanizmu opisywania zapytań, w których wymagania ACID są złagodzone”. Technicznie prawda, ale serwer SQL zrobił nieśmiałe kroki w tym kierunku. SQL 2014 wprowadza Opóźnioną Trwałość, rozluźniając D w ACID, w zamian za zmniejszenie ciśnienia zapisu dziennika.
EBarr
3
To powinna być zaakceptowana odpowiedź imo. Jest to bardzo jasne z przykładami, ale udaje się zachować zwięzłość.
Olszańsk
4

Prawdą jest, że bazy danych NoSQL (MongoDB, Redis, Riak, Memcached itp.) Nie utrzymują ograniczeń klucza obcego, a operacje atomowe muszą być bardziej szczegółowo określone. Prawdą jest również to, że bazy danych SQL (SQL Server, Oracle, PostgreSQL itp.) Mogą być skalowane w celu obsługi bardzo dużych wymagań wydajnościowych przez doświadczonych DBA.

Bazy danych NoSQL pozwalają doświadczonym programistom, dobrze znającym warunki rasowe i operacje atomowe, zrezygnować z dużej ilości przetwarzania wymaganego tylko w niewielkim odsetku dzisiejszego kodu aplikacji WWW. Bazy danych NoSQL z pewnością mają operacje atomowe i większość wszystkich wymagań transakcyjnych obecnych w bazach SQL można również uzyskać baz danych NoSQL. Różnica polega na poziomie abstrakcji. Bazy danych NoSQL usuwają wyższy poziom abstrakcji i podają tę zdolność programistom aplikacji, dzięki czemu ogólnie powstaje szybszy kod ze zwiększonym prawdopodobieństwem uszkodzenia danych przez niesezonowanych programistów.

W rezultacie znacznie bardziej prawdopodobne jest, że bazy danych NoSQL będą coraz częściej wykorzystywane w przestrzeni aplikacji internetowych, gdzie czas i wydajność programowania są bardzo ważne. Oprogramowanie finansowe i korporacyjne prawdopodobnie zachowa swoje dziedzictwo SQL, ponieważ wydajność sprzętu jest stosunkowo tania, przygotowali DBA pod ręką, a zwiększone ryzyko spowodowane przez niesezonowanych programistów jest nie do przyjęcia.

RandomProgrammer
źródło
2
Nie jestem pewien, czy zgadzam się z częścią dotyczącą transakcji atomowych w sensie ACID (chociaż trudno jest komentować „NoSQL”, ponieważ jest to kwestia dyskusyjna, co dokładnie mamy na myśli). Większość przyrostów wydajności w „typowych” bazach danych NoSQL osiąga się przez poluzowanie gwarancji spójności (patrz: ostateczna spójność , ACID vs. BASE). Jeśli ostateczna spójność jest wystarczająca dla aplikacji (i często tak jest), pozwala to na znacznie bardziej wydajne skalowanie w poziomie.
Daniel B
4

Od IBM developerWorks: Dostarcz skalowalność danych na poziomie chmury za pomocą baz danych NoSQL

Skalowalność to system, który powinien być w stanie obsługiwać bardzo duże bazy danych o bardzo wysokich wskaźnikach żądań przy bardzo niskim opóźnieniu.

Systemy NoSQL mają wiele wspólnych cech projektowych:

  • Możliwość skalowania w poziomie przepustowości na wielu serwerach.
  • Prosty interfejs lub protokół na poziomie połączenia (w przeciwieństwie do powiązania SQL).
  • Obsługa słabszych modeli spójności niż transakcje ACID w większości tradycyjnych RDBMS.
  • Wydajne wykorzystanie indeksów rozproszonych i pamięci RAM do przechowywania danych.
  • Możliwość dynamicznego definiowania nowych atrybutów lub schematu danych.

Dlaczego relacyjne bazy danych mogą nie być optymalne dla skalowania

Ogólnie rzecz biorąc, systemy zarządzania relacyjnymi bazami danych są od dziesięcioleci uważane za „uniwersalne rozwiązanie do przechowywania i wyszukiwania danych”. Dojrzewają po szeroko zakrojonych pracach badawczo-rozwojowych i bardzo skutecznie stworzyły duży rynek i rozwiązania w różnych obszarach biznesowych.

Stale rosnące zapotrzebowanie na skalowalność i nowe wymagania dotyczące aplikacji stworzyły nowe wyzwania dla tradycyjnego RDBMS, w tym pewne niezadowolenie z tego uniwersalnego podejścia w niektórych aplikacjach na skalę internetową. Odpowiedzią na to jest nowa generacja niedrogiego, wysokowydajnego oprogramowania bazodanowego zaprojektowanego w celu podważenia dominacji systemów zarządzania relacyjnymi bazami danych. Głównym powodem ruchu NoSQL jest to, że różne implementacje aplikacji internetowych, korporacyjnych i chmurowych mają różne wymagania dotyczące baz danych - nie każda aplikacja wymaga na przykład sztywnej spójności danych.

Kolejny przykład: w przypadku witryn o dużej objętości, takich jak eBay, Amazon, Twitter lub Facebook, skalowalność i wysoka dostępność to podstawowe wymagania, których nie można skompromitować. W przypadku tych aplikacji nawet najmniejsze awarie mogą mieć znaczące konsekwencje finansowe i wpływać na zaufanie klientów.

Over na DBA.SE: Co oznacza skalowanie w poziomie?

Skalowanie w poziomie zasadniczo buduje się zamiast w górę. Nie kupujesz większego, mocniejszego serwera i przenosisz na niego całe swoje obciążenie, zamiast tego kupujesz ponad 1 dodatkowe serwery i rozkładasz obciążenie na nie.

Skalowanie w poziomie jest używane, gdy masz możliwość uruchamiania wielu instancji na serwerach jednocześnie. Zazwyczaj dużo trudniej jest przejść z 1 serwera na 2 serwery, niż z 2 do 5, 10, 50 itd.

Po rozwiązaniu problemów z uruchamianiem równoległych instancji możesz w pełni korzystać ze środowisk takich jak Amazon EC2, usługa Cloud Rackspace, GoGrid itp., Ponieważ możesz zwiększać i zmniejszać liczbę instancji w zależności od zapotrzebowania, zmniejszając potrzebę płacenia za moc serwera nie używasz tylko do pokrycia tych szczytowych obciążeń.

Relacyjne bazy danych są jednym z trudniejszych elementów do równoległego uruchamiania pełnego odczytu / zapisu.

Md Mahbubur Rahman
źródło