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

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ść?

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.

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

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.

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.