Warum sind noSQL-Datenbanken skalierbarer als SQL?

100

In letzter Zeit habe ich viel über noSQL DBMS gelesen. Ich verstehe das CAP-Theorem , die ACID- Regeln, die BASE- Regeln und die Basistheorie. Sie haben jedoch keine Ressourcen gefunden, warum noSQL einfacher zu skalieren ist als RDBMS (z. B. bei einem System, das viele DB-Server erfordert)?

Ich vermute, dass das Beibehalten von Einschränkungen und Fremdschlüsseln Ressourcen kostet und wenn ein DBMS verteilt wird, ist es viel komplizierter. Aber ich gehe davon aus, dass es noch viel mehr gibt.

Kann mir jemand erklären, wie noSQL / SQL die Skalierbarkeit beeinflusst?

Ducin
quelle
7
"Ich vermute, dass das Beibehalten von Einschränkungen und Fremdschlüsseln Ressourcen kostet und wenn ein DBMS verteilt wird, ist es viel komplizierter. Aber ich gehe davon aus, dass es noch viel mehr gibt." - Eigentlich ist es das. Genauer gesagt ist dies das gemeinsame Merkmal, das die meisten NoSQL-Lösungen skalierbarer macht als ihre SQL-Verwandten (für bestimmte Datenmodelle). Aber NoSQL ist ein äußerst vager Begriff. Verschiedene Familien von NoSQL-Datenbanken haben unterschiedliche Eigenschaften, die sie skalierbarer machen.
Yannis
8
Natürlich lassen sich SQL-Datenbanken perfekt auf Billionen von Datensätzen skalieren. Sie benötigen lediglich einige Kenntnisse, um sie zu entwerfen und einzurichten, über die Anwendungsentwickler nicht verfügen. Und im Allgemeinen ein ziemlich teurer Satz an Hardware und Lizenzen.
HLGEM
6
Meiner Meinung nach handelt es sich bei dieser Frage nicht um ein Duplikat. Die Mongodb-Frage ist (abgesehen von einem schlechten Titel, der es spezifischer erscheinen lässt), etwas anderes zu fragen, das in der Tat allgemeiner ist. Zur Wiedereröffnung gewählt.
Joeri Sebrechts

Antworten:

79

noSQL-Datenbanken bieten eine enorme Menge an Funktionen, die Ihnen eine SQL-Datenbank von Natur aus bietet.

Dinge wie die automatische Durchsetzung der referenziellen Integrität, Transaktionen usw. Dies sind alles Dinge, die für einige Probleme sehr nützlich sind und die einige interessante Techniken für die Skalierung außerhalb eines einzelnen Servers erfordern (denken Sie darüber nach, was passiert, wenn Sie zwei sperren müssen Tabellen für eine atomare Transaktion, und sie sind auf verschiedenen Servern!).

noSQL-Datenbanken haben das alles nicht. Wenn Sie das Zeug brauchen, müssen Sie es selbst machen, aber wenn Sie es NICHT brauchen (und es gibt viele Anwendungen, die dies nicht tun), haben Sie Glück, Junge. Die Datenbank muss nicht all diese komplexen Operationen ausführen und einen Großteil des Datensatzes sperren, sodass es wirklich einfach ist, das Objekt auf viele Server / Festplatten / was auch immer zu partitionieren und es sehr schnell arbeiten zu lassen.

Michael Kohne
quelle
2
Wusste nicht, dass es so einfach war
Abdul
7
In dieser akzeptierten Antwort wird die in SQL fehlende NoSQL-Sharding-Fähigkeit überhaupt nicht erwähnt. Sharding macht NoSQL horizontal skalierbar.
Hyankov
8
@HristoYankov Und es funktioniert, weil das NoSQL-System nicht alle Dinge erledigt, die mit Sharding nicht gut zu tun haben.
immibis
1
@HristoYankov: SQL-Datenbanken können horizontal und nicht alle NoSQL-Datenbanken können problemlos horizontal aufgeteilt werden. Sharding ist nicht wirklich der Grund, warum Sie NoSQL verwenden möchten.
Lie Ryan
@HristoYankov Die akzeptierte Antwort geht eine Ebene tiefer als Ihre Bemerkung, dass "die in SQL fehlende NoSQL-Sharding-Fähigkeit überhaupt nicht erwähnt wird". Die akzeptierte Antwort spricht zu Recht davon, warum horizontales Sharding bei SQL-Datenbanken schwieriger ist. Tatsächlich habe ich gut 20 Minuten damit verbracht, nach der Antwort darauf zu suchen, und so ziemlich jeder rollt einfach die "ohh NoSQL-Shards besser" aus, ohne irgendeinen Grund zu erwähnen. Völlig nutzlose Antwort. Die hier akzeptierten Antworten beantworten die Frage perfekt - wenn auch sehr kurz. Wäre nett, wenn noch mehr Gründe aufgeführt wären.
Phoeniyx
176

Es geht nicht um NoSQL vs SQL, es geht um BASE vs ACID.

Skalierbar muss in seine Bestandteile zerlegt werden:

  • Leseskalierung = Erledigt höhere Volumina von Lesevorgängen
  • Schreibskalierung = Erledigt höhere Volumina von Schreibvorgängen

ACID-kompatible Datenbanken (wie herkömmliche RDBMS) können Lesevorgänge skalieren. Sie sind von Natur aus nicht weniger effizient als NoSQL-Datenbanken, da die (möglichen) Leistungsengpässe durch Dinge verursacht werden, die NoSQL (manchmal) fehlt (wie Joins und wo Einschränkungen), die Sie nicht verwenden können. Mit SQL-RDBMS-Clustern können Lesevorgänge skaliert werden, indem zusätzliche Knoten in den Cluster eingefügt werden. Es gibt Einschränkungen, inwieweit Leseoperationen skaliert werden können. Diese ergeben sich jedoch aus der Schwierigkeit, Schreibvorgänge zu skalieren, wenn Sie mehr Knoten in den Cluster einfügen.

Beim Skalieren von Texten wird es haarig. Das ACID-Prinzip unterwirft verschiedene Einschränkungen, die Sie in schließlich konsistenten (BASE-) Architekturen nicht sehen:

  • Atomicity bedeutet, dass Transaktionen als Ganzes abgeschlossen werden müssen oder fehlschlagen müssen. Daher muss eine Menge Buchhaltung hinter den Kulissen betrieben werden, um dies zu gewährleisten.
  • Konsistenzbeschränkungen bedeuten, dass alle Knoten im Cluster identisch sein müssen. Wenn Sie auf einen Knoten schreiben, muss dieser Schreibvorgang auf alle anderen Knoten kopiert werden, bevor eine Antwort an den Client zurückgegeben wird. Dies macht es schwierig, einen herkömmlichen RDBMS-Cluster zu skalieren.
  • Haltbarkeitsbeschränkungen bedeuten, dass Sie sicherstellen müssen, bevor eine Antwort an den Client zurückgesendet wird, dass der Schreibvorgang auf die Festplatte geschrieben wurde, um niemals einen Schreibvorgang zu verlieren.

Um Schreibvorgänge oder die Anzahl der Knoten in einem Cluster über einen bestimmten Punkt hinaus zu skalieren, müssen Sie einige der ACID-Anforderungen lockern können:

  • Durch das Löschen von Atomicity können Sie die Dauer verkürzen, für die Tabellen (Datensätze) gesperrt sind. Beispiel: MongoDB, CouchDB.
  • Durch das Löschen von Consistency können Sie Schreibvorgänge über Clusterknoten hinweg skalieren. Beispiele: Riak, Cassandra.
  • Durch das Löschen von Durability können Sie auf Schreibbefehle reagieren, ohne die Festplatte zu leeren. Beispiele: Memcache, Redis.

NoSQL-Datenbanken folgen normalerweise dem BASE-Modell anstelle des ACID-Modells. Sie geben die A-, C- und / oder D-Anforderungen auf und verbessern im Gegenzug die Skalierbarkeit. Bei einigen wie Cassandra können Sie sich für die Garantien von ACID entscheiden, wenn Sie diese benötigen. Es sind jedoch nicht immer alle NoSQL-Datenbanken skalierbarer.

Der SQL-API fehlt ein Mechanismus zur Beschreibung von Abfragen, bei denen die Anforderungen von ACID gelockert werden. Aus diesem Grund sind alle BASE-Datenbanken NoSQL.

Persönliche Anmerkung: Ein letzter Punkt, den ich ansprechen möchte, ist, dass in den meisten Fällen, in denen NoSQL zur Verbesserung der Leistung verwendet wird, eine Lösung für ein ordnungsgemäßes RDBMS möglich ist, indem ein ordnungsgemäß normalisiertes Schema mit geeigneten Indizes verwendet wird. Wie von genau dieser Site (unterstützt von MS SQL Server) bewiesen, können RDBMS auf hohe Arbeitslasten skaliert werden, wenn Sie sie ordnungsgemäß verwenden. Leute, die nicht verstehen, wie man RDBMS optimiert, sollten sich von NoSQL fernhalten, weil sie nicht verstehen, welche Risiken sie mit ihren Daten eingehen.

Update (17.09.2019):

Die Datenbanklandschaft hat sich seit dem Posten dieser Antwort weiterentwickelt. Obwohl es immer noch eine Dichotomie zwischen der RDBMS ACID-Welt und der NoSQL BASE-Welt gibt, ist die Linie unübersichtlicher geworden. Die NoSQL-Datenbanken haben Funktionen aus der RDBMS-Welt wie SQL-APIs und Transaktionsunterstützung hinzugefügt. Es gibt jetzt sogar Datenbanken, die SQL, ACID und Schreibskalierung versprechen , wie Google Cloud Spanner, YugabyteDB oder CockroachDB. Typischerweise steckt der Teufel im Detail, aber für die meisten Zwecke sind diese "SÄURE genug". Für einen tieferen Einblick in die Datenbanktechnologie und deren Entwicklung können Sie sich dieses Foliendeck ansehen (die Foliennotizen enthalten die dazugehörige Erklärung).

Joeri Sebrechts
quelle
Ich bin damit einverstanden, dass einige NoSQL-Stores ACID durch BASE ersetzen, aber dies ist immer noch keine gemeinsame Funktion für alle Stores, die unter die "Kategorie" von NoSQL fallen, die an erster Stelle falsch definiert ist. Nach einer Weile hat sich die Interpretation des Begriffs von "No SQL" in "Not Only SQL" geändert, aber da viele dieser Datenbanken noch JOINs ausführen oder SQLesque-Dialekte implementieren, hat Mark Madsen den Begriff neu definiert, um etwas anderes zu bedeuten seine datenbankhistorie in notation : "no, SQL" ;-)
Lukas Eder
2
Um Verknüpfungen zu vermeiden, haben wir Daten in NoSQL de-normalisiert, was zu Wiederholungen und mehr Speicher führt. Aber dasselbe kann in RDBMS erreicht werden, wenn die De-Normalisierung in Ordnung ist. "Joins" oder "No Joins" hängt also vom DBA und nicht vom Datenbanktyp ab. Richtig ?
Kaushik Lele
2
@dynamic Bei diesen Sites wird entweder starkes Caching verwendet, oder es handelt sich um Shards. Diese Entwürfe stellen die Komplexität der Skalierung der Daten außerhalb der Datenbank. Sie können in einem solchen Fall auch nosql verwenden, da dies genau der Kompromiss ist, den nosql eingeht.
Joeri Sebrechts
1
Msgstr "In der SQL - API fehlt ein Mechanismus zur Beschreibung von Abfragen, bei denen die Anforderungen von ACID gelockert werden". Technisch gesehen stimmt das, aber SQL Server hat einen schüchternen Schritt in diese Richtung getan. In SQL 2014 wird Delayed Durability eingeführt, wodurch das D in ACID gelockert wird, um den Druck beim Schreiben von Protokollen zu verringern.
EBarr
3
Dies sollte die akzeptierte Antwort sein. Es ist sehr klar mit Beispielen, aber es gelingt, kurz zu bleiben.
Olshansk
4

Es ist richtig, dass NoSQL-Datenbanken (MongoDB, Redis, Riak, Memcached usw.) keine Fremdschlüsseleinschränkungen beibehalten und atomare Operationen genauer spezifiziert werden müssen. Es ist auch richtig, dass SQL-Datenbanken (SQL Server, Oracle, PostgreSQL usw.) skaliert werden können, um sehr große Leistungsanforderungen durch erfahrene DBAs zu erfüllen.

Mit NoSQL-Datenbanken können erfahrene Programmierer, die sich mit den Race-Bedingungen und den atomaren Operationen gut auskennen, auf einen großen Verarbeitungsaufwand verzichten, der nur in einem geringen Prozentsatz des heutigen Webanwendungscodes erforderlich ist. NoSQL-Datenbanken haben zweifellos atomare Operationen und die meisten Transaktionsanforderungen, die in SQL-Datenbanken vorhanden sind, können auch in NoSQL-Datenbanken abgerufen werden. Der Unterschied ist die Abstraktionsebene. NoSQL-Datenbanken entfernen die höheren Abstraktions- und Handlungsstufen an den Anwendungsprogrammierer, wodurch der Code insgesamt schneller wird und die Wahrscheinlichkeit von Datenverfälschungen durch ungewöhnliche Programmierer steigt.

Infolgedessen ist es viel wahrscheinlicher, dass NoSQL-Datenbanken im Webanwendungsbereich, in dem Entwicklungszeit und Leistung sehr wichtig sind, immer häufiger verwendet werden. Finanz- und Unternehmenssoftware wird wahrscheinlich ihr SQL-Erbe beibehalten, da die Hardwareleistung relativ günstig ist, erfahrene Datenbankadministratoren zur Verfügung stehen und das erhöhte Risiko, das durch ungewöhnliche Programmierer verursacht wird, nicht akzeptabel ist.

RandomProgrammer
quelle
2
Ich bin mir nicht sicher, ob ich mit dem Teil über atomare Transaktionen im Sinne von ACID einverstanden bin (obwohl es schwierig ist, "NoSQL" zu kommentieren, da diskutiert wird, was genau wir meinen). Die meisten Leistungsgewinne in "typischen" NoSQL-DBs werden durch Lockerung der Konsistenzgarantien erzielt (siehe: Eventuelle Konsistenz , ACID vs. BASE). Wenn die Konsistenz für eine Anwendung ausreichend ist (und dies häufig der Fall ist), kann die horizontale Skalierung wesentlich effizienter durchgeführt werden.
Daniel B
4

Von IBM developerWorks: Bieten Sie Daten-Skalierbarkeit auf Cloud-Ebene mit NoSQL-Datenbanken

Skalierbarkeit ist das System, das sehr große Datenbanken mit sehr hohen Anforderungsraten bei sehr geringer Latenz unterstützen soll.

NoSQL-Systeme haben eine Reihe von Designmerkmalen gemeinsam:

  • Die Möglichkeit, den Durchsatz über viele Server horizontal zu skalieren.
  • Eine einfache Schnittstelle oder ein Protokoll auf Aufrufebene (im Gegensatz zu einer SQL-Bindung).
  • Unterstützung für schwächere Konsistenzmodelle als die ACID-Transaktionen in den meisten herkömmlichen RDBMS.
  • Effiziente Nutzung von verteilten Indizes und RAM zur Datenspeicherung.
  • Die Fähigkeit, neue Attribute oder Datenschemata dynamisch zu definieren.

Warum relationale Datenbanken für die Skalierung möglicherweise nicht optimal sind

Im Allgemeinen werden relationale Datenbankverwaltungssysteme seit Jahrzehnten als "einheitliche Lösung für die Persistenz und den Abruf von Daten" angesehen. Sie sind nach umfangreichen Forschungs- und Entwicklungsanstrengungen gereift und haben sehr erfolgreich einen großen Markt und Lösungen in verschiedenen Geschäftsbereichen geschaffen.

Das stetig wachsende Bedürfnis nach Skalierbarkeit und neuen Anwendungsanforderungen hat die traditionellen RDBMS vor neue Herausforderungen gestellt, einschließlich einiger Unzufriedenheit mit diesem einheitlichen Ansatz in einigen Web-Anwendungen. Die Antwort auf diese Frage war eine neue Generation von kostengünstiger und leistungsstarker Datenbanksoftware, die die Dominanz relationaler Datenbankverwaltungssysteme in Frage stellen soll. Ein wichtiger Grund für die NoSQL-Bewegung ist, dass bei verschiedenen Implementierungen von Web-, Unternehmens- und Cloud-Computing-Anwendungen unterschiedliche Anforderungen an die Datenbanken gestellt werden. Nicht jede Anwendung erfordert beispielsweise eine starre Datenkonsistenz.

Ein weiteres Beispiel: Für Websites mit hohem Volumen wie eBay, Amazon, Twitter oder Facebook sind Skalierbarkeit und hohe Verfügbarkeit wesentliche Voraussetzungen, die nicht gefährdet werden dürfen. Bei diesen Anwendungen kann jeder noch so kleine Ausfall erhebliche finanzielle Konsequenzen haben und das Kundenvertrauen beeinträchtigen.

Over on DBA.SE: Was bedeutet horizontale Skalierung?

Die horizontale Skalierung baut sich im Wesentlichen auf, anstatt auf. Sie kaufen keinen größeren Server und verlagern Ihre gesamte Last darauf. Stattdessen kaufen Sie 1 oder mehr zusätzliche Server und verteilen Ihre Last auf diese Server.

Die horizontale Skalierung wird verwendet, wenn Sie mehrere Instanzen gleichzeitig auf Servern ausführen können. Normalerweise ist es viel schwieriger, von 1 Server auf 2 Server zu wechseln, als von 2 auf 5, 10, 50 usw.

Sobald Sie die Probleme beim Ausführen paralleler Instanzen behoben haben, können Sie Umgebungen wie Amazon EC2, den Cloud-Service von Rackspace, GoGrid usw. optimal nutzen, da Sie Instanzen je nach Bedarf hoch- und runterfahren können, sodass Sie weniger für die Serverleistung zahlen müssen Sie verwenden nicht nur, um diese Spitzenlasten abzudecken.

Relationale Datenbanken sind eines der schwierigeren Elemente, um das vollständige Lesen / Schreiben parallel auszuführen.

Md Mahbubur Rahman
quelle