Eine der großen Herausforderungen für nosql DBMS ist, dass sie sich leichter gruppieren lassen. Angeblich können Sie mit NoSQL Hunderte von billigen Maschinen erstellen, auf denen verschiedene Daten gespeichert und gleichzeitig abgefragt werden.

Meine Frage ist, warum kann relationales DBMS dies nicht wie MySQL oder SQL Server? Ist es so, dass die Anbieter einfach keine technische Lösung für dieses Problem mit ihrem vorhandenen Produkt gefunden haben, oder gibt es ein Problem mit dem relationalen Modell, das verhindert, dass dies möglich ist? Was ist so großartig an der NoSQL-Methode zum Speichern und Zugreifen auf Daten (Schlüssel / Wert, Dokumente usw.), die das Clustering erleichtert, wenn dies überhaupt zutrifft?

Verteilte Datenbanksysteme 101

Oder verteilte Datenbanken - was bedeutet die FK " Web-Skala " eigentlich?

Verteilte Datenbanksysteme sind komplexe Lebewesen und in verschiedenen Geschmacksrichtungen erhältlich. Wenn ich mich an der Universität mit den Tiefen meiner schwer in Erinnerung gebliebenen Studien befasse, werde ich versuchen, einige der wichtigsten technischen Probleme beim Aufbau eines verteilten Datenbanksystems zu erklären.

Zunächst einige Begriffe

ACID-Eigenschaften (Atomicity, Consistency, Isolation and Durability): Dies sind die wichtigsten Invarianten, die erzwungen werden müssen, damit eine Transaktion zuverlässig durchgeführt werden kann, ohne dass unerwünschte Nebenwirkungen auftreten.

Atomicity setzt voraus , dass die Transaktion vollständig oder ein Rollback vollständig durchgeführt wurde. Teilweise abgeschlossene Transaktionen sollten niemals sichtbar sein, und das System muss so aufgebaut sein, dass dies verhindert wird.

Konsistenz erfordert, dass eine Transaktion niemals Invarianten (wie deklarative referenzielle Integrität) verletzt, die vom Datenbankschema garantiert werden. Wenn beispielsweise ein Fremdschlüssel vorhanden ist, sollte es nicht möglich sein, einen untergeordneten Datensatz einzufügen, der einem nicht vorhandenen übergeordneten Element entspricht.

Die Isolation erfordert, dass sich Transaktionen nicht gegenseitig stören. Das System sollte die gleichen Ergebnisse garantieren, wenn die Transaktionen parallel oder nacheinander ausgeführt werden. In der Praxis erlauben die meisten RDBMS-Produkte Modi, die die Isolierung gegen die Leistung abwägen.

Für die Dauerhaftigkeit ist es erforderlich, dass die Transaktion nach dem Festschreiben in einem dauerhaften Speicher verbleibt, der robust gegenüber Hardware- oder Softwarefehlern ist.

Im Folgenden werden einige der technischen Hürden erläutert, die diese Anforderungen für verteilte Systeme darstellen.

Shared Disk Architecture: Eine Architektur, in der alle Verarbeitungsknoten in einem Cluster auf den gesamten Speicher zugreifen können. Dies kann einen zentralen Engpass für den Datenzugriff darstellen. Ein Beispiel für ein Shared-Disk-System ist Oracle RAC oder Exadata .

Shared Nothing-Architektur: Eine Architektur, in der Verarbeitungsknoten in einem Cluster über einen lokalen Speicher verfügen, der für andere Clusterknoten nicht sichtbar ist. Beispiele für Shared-Nothing-Systeme sind Teradata und Netezza .

Shared Memory Architecture: Eine Architektur, in der mehrere CPUs (oder Knoten) auf einen gemeinsam genutzten Speicherpool zugreifen können. Die meisten modernen Server sind vom Typ Shared Memory. Shared Memory erleichtert bestimmte Vorgänge wie Caches oder atomare Synchronisationsprimitive, die auf verteilten Systemen viel schwieriger durchzuführen sind.

Synchronisation: Ein Oberbegriff, der verschiedene Methoden beschreibt, um den konsistenten Zugriff auf eine gemeinsam genutzte Ressource durch mehrere Prozesse oder Threads sicherzustellen. Dies ist auf verteilten Systemen viel schwieriger als auf gemeinsam genutzten Speichersystemen, obwohl einige Netzwerkarchitekturen (z. B. BYNET von Teradata) Synchronisationsprimitive im Netzwerkprotokoll hatten. Die Synchronisierung kann auch mit einem erheblichen Overhead verbunden sein.

Semi-Join: Ein Grundelement, das zum Verbinden von Daten verwendet wird, die sich auf zwei verschiedenen Knoten eines verteilten Systems befinden. Im Wesentlichen besteht es aus genügend Informationen zu den zu verbindenden Zeilen, die gebündelt und von einem Knoten an den anderen weitergeleitet werden, um die Verbindung aufzulösen. Bei großen Abfragen kann dies zu erheblichem Netzwerkverkehr führen.

Eventual Consistency: Ein Begriff, der zur Beschreibung der Transaktionssemantik verwendet wird, bei der die sofortige Aktualisierung (Konsistenz bei Lesevorgängen) aller Knoten eines verteilten Systems für die Leistung (und damit für einen höheren Transaktionsdurchsatz) bei Schreibvorgängen abgewogen wird. Eventuelle Konsistenz ist ein Nebeneffekt der Verwendung von Quorum Replication als Leistungsoptimierung zur Beschleunigung von Transaktions-Commits in verteilten Datenbanken, in denen mehrere Kopien von Daten auf separaten Knoten gespeichert sind.

Lamports Algorithmus: Ein Algorithmus zum Implementieren des gegenseitigen Ausschlusses (Synchronisation) zwischen Systemen ohne gemeinsamen Speicher. Normalerweise erfordert ein gegenseitiger Ausschluss innerhalb eines Systems eine atomare Lese-Vergleich-Schreib- oder ähnliche Anweisung eines Typs, der normalerweise nur auf einem gemeinsam genutzten Speichersystem praktikabel ist. Andere verteilte Synchronisationsalgorithmen existieren, aber Lamports war einer der ersten und ist der bekannteste. Wie die meisten verteilten Synchronisationsmechanismen hängt der Lamport-Algorithmus stark von der genauen Zeitsteuerung und Taktsynchronisation zwischen Clusterknoten ab.

Two Phase Commit (2PC): Eine Familie von Protokollen, die sicherstellen, dass Datenbankaktualisierungen, an denen mehrere physische Systeme beteiligt sind, konsistent festgeschrieben oder zurückgesetzt werden. Unabhängig davon, ob 2PC innerhalb eines Systems oder über mehrere Systeme hinweg über einen Transaktionsmanager verwendet wird, ist der Aufwand erheblich.

In einem zweiphasigen Festschreibungsprotokoll fordert der Transaktionsmanager die beteiligten Knoten auf, die Transaktion so fortzusetzen, dass sie garantieren kann, dass sie festgeschrieben wird, und signalisiert dann diesen Status. Wenn alle Knoten einen "Happy" -Status zurückgegeben haben, werden die Knoten zum Festschreiben aufgefordert. Die Transaktion wird weiterhin als offen betrachtet, bis alle Knoten eine Antwort senden, die angibt, dass das Festschreiben abgeschlossen ist. Wenn ein Knoten ausfällt, bevor signalisiert wird, dass der Festschreibevorgang abgeschlossen ist, fragt der Transaktionsmanager den Knoten erneut ab, wenn er wieder hochgefahren wird, bis er eine positive Antwort erhält, die angibt, dass die Transaktion festgeschrieben wurde.

Multi-Version Concurrency Control (MVCC): Verwaltung von Konflikten durch Schreiben neuer Versionen der Daten an einen anderen Speicherort und Anzeigen der alten Version der Daten durch andere Transaktionen, bis die neue Version festgeschrieben ist. Dies reduziert Datenbankkonflikte auf Kosten von zusätzlichem Schreibverkehr, um die neue Version zu schreiben und die alte Version dann als veraltet zu markieren.

Wahlalgorithmus: Verteilte Systeme, an denen mehrere Knoten beteiligt sind, sind von Natur aus weniger zuverlässig als ein einzelnes System, da es mehr Fehlermodi gibt. In vielen Fällen ist ein Mechanismus erforderlich, damit Cluster-Systeme den Ausfall eines Knotens beheben können. Wahlalgorithmen sind eine Klasse von Algorithmen, die zum Auswählen eines Leiters zum Koordinieren einer verteilten Berechnung in Situationen verwendet werden, in denen der Leiterknoten nicht zu 100% bestimmt oder zuverlässig ist.

Horizontale Partitionierung: Eine Tabelle kann durch ihren Schlüssel auf mehrere Knoten oder Speicherdatenträger aufgeteilt werden. Auf diese Weise kann ein großes Datenvolumen in kleinere Blöcke aufgeteilt und auf die Speicherknoten verteilt werden.

Sharding: Ein Datensatz kann in einer Architektur ohne gemeinsame Nutzung horizontal auf mehrere physische Knoten aufgeteilt sein. Wenn diese Partitionierung nicht transparent ist (dh der Client muss das Partitionsschema kennen und herausfinden, welcher Knoten explizit abgefragt werden soll), spricht man von Sharding. Einige Systeme (z. B. Teradata) teilen Daten auf Knoten auf, der Standort ist jedoch für den Client transparent. Der Begriff wird normalerweise nicht in Verbindung mit dieser Art von System verwendet.

Konsistentes Hashing: Ein Algorithmus zum Zuweisen von Daten zu Partitionen basierend auf dem Schlüssel. Es zeichnet sich durch eine gleichmäßige Verteilung der Hash-Schlüssel und die Fähigkeit aus, die Anzahl der Eimer effizient zu erweitern oder zu reduzieren. Diese Attribute sind nützlich, um Daten zu partitionieren oder Daten über einen Cluster von Knoten zu laden, wobei sich die Größe dynamisch ändern kann, wenn Knoten zum Cluster hinzugefügt oder daraus entfernt werden (möglicherweise aufgrund eines Fehlers).

Multi-Master-Replikation: Eine Technik, mit der Schreibvorgänge über mehrere Knoten in einem Cluster auf die anderen Knoten repliziert werden können. Diese Technik erleichtert die Skalierung, indem ermöglicht wird, dass einige Tabellen zwischen Servern partitioniert oder aufgeteilt werden und andere im gesamten Cluster synchronisiert werden. Schreibvorgänge müssen im Gegensatz zu einem Quorum auf alle Knoten repliziert werden, sodass Transaktions-Commits in einer replizierten Multi-Master-Architektur teurer sind als in einem replizierten Quorum-System.

Nicht blockierender Switch: Ein Netzwerk-Switch, der interne Hardware-Parallelität verwendet, um einen Durchsatz zu erzielen, der proportional zur Anzahl der Ports ohne interne Engpässe ist. Eine naive Implementierung kann einen Crossbar-Mechanismus verwenden, der jedoch eine O (N ^ 2) -Komplexität für N Ports aufweist und sich auf kleinere Switches beschränkt. Größere Switches können eine komplexere interne Topologie verwenden, die als nicht blockierender Minimal-Spanning-Switch bezeichnet wird, um eine lineare Durchsatzskalierung zu erzielen, ohne dass O (N ^ 2) -Hardware erforderlich ist.

Wie schwierig kann es sein, ein verteiltes DBMS zu erstellen?

Verschiedene technische Herausforderungen erschweren dies in der Praxis. Abgesehen von der zusätzlichen Komplexität beim Aufbau eines verteilten Systems muss der Architekt eines verteilten DBMS einige knifflige technische Probleme bewältigen.

Atomarität auf verteilten Systemen: Wenn die von einer Transaktion aktualisierten Daten auf mehrere Knoten verteilt sind, muss das Festschreiben / Zurücksetzen der Knoten koordiniert werden. Dies erhöht den Aufwand für Shared-Nothing-Systeme erheblich. Auf Systemen mit gemeinsam genutzten Datenträgern ist dies weniger problematisch, da der gesamte Speicher für alle Knoten sichtbar ist, sodass ein einzelner Knoten das Festschreiben koordinieren kann.

Konsistenz auf verteilten Systemen: Um das oben genannte Fremdschlüsselbeispiel zu verwenden, muss das System in der Lage sein, einen konsistenten Status zu bewerten. Wenn sich beispielsweise das übergeordnete und das untergeordnete Element einer Fremdschlüsselbeziehung auf verschiedenen Knoten befinden könnten, ist eine Art verteilter Sperrmechanismus erforderlich, um sicherzustellen, dass veraltete Informationen nicht zur Validierung der Transaktion verwendet werden. Wenn dies nicht erzwungen wird, können Sie beispielsweise eine Race-Bedingung haben, bei der der Elternteil gelöscht wird, nachdem sein Vorhandensein überprüft wurde, bevor das Einfügen des Kindes zugelassen wird.

Die verzögerte Durchsetzung von Einschränkungen (dh das Warten bis zur Bestätigung der DRI) erfordert, dass die Sperre für die Dauer der Transaktion aufrechterhalten wird. Diese Art der verteilten Sperrung ist mit einem erheblichen Mehraufwand verbunden.

Wenn mehrere Kopien von Daten gespeichert sind (dies kann auf Systemen ohne gemeinsame Nutzung erforderlich sein, um unnötigen Netzwerkverkehr durch Semi-Joins zu vermeiden), müssen alle Kopien der Daten aktualisiert werden.

Isolation auf verteilten Systemen: Wenn sich die in einer Transaktion betroffenen Daten auf mehreren Systemknoten befinden, müssen die Sperren und die Version (falls MVCC verwendet wird) auf den Knoten synchronisiert werden. Um die Serialisierbarkeit von Vorgängen zu gewährleisten, insbesondere auf Shared-Nothing-Architekturen, auf denen redundante Kopien von Daten gespeichert werden können, ist ein verteilter Synchronisationsmechanismus wie Lamports Algorithmus erforderlich, der auch einen erheblichen Overhead im Netzwerkverkehr mit sich bringt.

Haltbarkeit auf verteilten Systemen: Auf einem gemeinsam genutzten Festplattensystem ist das Problem der Haltbarkeit im Wesentlichen dasselbe wie bei einem System mit gemeinsam genutztem Speicher, mit der Ausnahme, dass verteilte Synchronisationsprotokolle weiterhin für mehrere Knoten erforderlich sind. Das DBMS muss Journal-Schreibvorgänge in das Protokoll schreiben und die Daten konsistent ausschreiben. Auf einem System ohne gemeinsame Nutzung können mehrere Kopien der Daten oder Teile der Daten auf verschiedenen Knoten gespeichert sein. Ein zweiphasiges Festschreibungsprotokoll ist erforderlich, um sicherzustellen, dass die Festschreibung über die Knoten hinweg korrekt erfolgt. Dies verursacht ebenfalls einen erheblichen Mehraufwand.

Auf einem System ohne gemeinsame Nutzung kann der Verlust eines Knotens bedeuten, dass dem System keine Daten zur Verfügung stehen. Um dies zu vermeiden, können die Daten auf mehrere Knoten repliziert werden. Konsistenz in dieser Situation bedeutet, dass die Daten auf alle Knoten repliziert werden müssen, auf denen sie sich normalerweise befinden. Dies kann zu einem erheblichen Mehraufwand beim Schreiben führen.

Eine in NoSQL-Systemen häufig durchgeführte Optimierung ist die Verwendung der Quorum-Replikation und der eventuellen Konsistenz, um eine träge Replikation der Daten zu ermöglichen und gleichzeitig ein gewisses Maß an Ausfallsicherheit der Daten zu gewährleisten, indem vor dem Melden der Transaktion als festgeschrieben in ein Quorum geschrieben wird. Die Daten werden dann träge auf die anderen Knoten repliziert, auf denen sich Kopien der Daten befinden.

Beachten Sie, dass "eventuelle Konsistenz" ein wichtiger Kompromiss in Bezug auf die Konsistenz ist, der möglicherweise nicht akzeptabel ist, wenn die Daten konsistent angezeigt werden müssen, sobald die Transaktion festgeschrieben ist. Beispielsweise sollte bei einer Finanzanwendung ein aktualisierter Saldo sofort verfügbar sein.

Shared-Disk-Systeme

Bei einem System mit gemeinsam genutzten Festplatten haben alle Knoten Zugriff auf den gesamten Speicher. Somit ist die Berechnung ortsunabhängig. Viele DBMS-Plattformen können auch in diesem Modus arbeiten - Oracle RAC ist ein Beispiel für eine solche Architektur.

Shared Disk-Systeme können erheblich skaliert werden, da sie eine M: M-Beziehung zwischen Speicherknoten und Verarbeitungsknoten unterstützen können. Ein SAN kann mehrere Controller haben und mehrere Server können die Datenbank ausführen. Diese Architekturen haben einen Switch als zentralen Engpass, aber Crossbar-Switches ermöglichen diesem Switch eine große Bandbreite. Ein Teil der Verarbeitung kann auf die Speicherknoten ausgelagert werden (wie im Fall von Oracle Exadata), wodurch der Datenverkehr auf der Speicherbandbreite verringert werden kann.

Obwohl der Switch theoretisch einen Engpass darstellt, bedeutet die verfügbare Bandbreite, dass Architekturen mit gemeinsam genutzten Festplatten sehr effektiv auf große Transaktionsvolumina skaliert werden können. Die meisten gängigen DBMS-Architekturen verwenden diesen Ansatz, da er eine ausreichende Skalierbarkeit und hohe Zuverlässigkeit bietet. Bei einer redundanten Speicherarchitektur wie Fibre Channel gibt es keinen einzigen Fehlerpunkt, da zwischen einem Verarbeitungsknoten und einem Speicherknoten mindestens zwei Pfade bestehen.

Shared-Nothing-Systeme

Shared-nothing-Systeme sind Systeme, bei denen zumindest ein Teil der Daten lokal auf einem Knoten gespeichert und für andere Knoten nicht direkt sichtbar ist. Dies beseitigt den Engpass eines zentralen Switch, sodass die Datenbank (zumindest theoretisch) mit der Anzahl der Knoten skaliert werden kann. Durch die horizontale Partitionierung können die Daten auf mehrere Knoten aufgeteilt werden. Dies kann für den Client transparent sein oder nicht (siehe oben unter Sharding).

Da die Daten von Natur aus verteilt sind, sind für eine Abfrage möglicherweise Daten von mehr als einem Knoten erforderlich. Wenn ein Join Daten von verschiedenen Knoten benötigt, wird eine Semi-Join-Operation verwendet, um genügend Daten zu übertragen, um den Join von einem Knoten auf einen anderen zu unterstützen. Dies kann zu einem hohen Datenaufkommen im Netzwerk führen. Daher kann die Optimierung der Datenverteilung einen großen Unterschied für die Abfrageleistung bedeuten.

Oft werden Daten über Knoten eines Shared-Nothing-Systems repliziert, um die Notwendigkeit von Semi-Joins zu verringern. Dies funktioniert auf Data Warehouse-Appliances recht gut, da die Dimensionen in der Regel um viele Größenordnungen kleiner sind als die Faktentabellen und problemlos über Knoten hinweg repliziert werden können. Sie werden in der Regel auch in Stapeln geladen, sodass der Replikationsaufwand geringer ist als bei einer Transaktionsanwendung.

Die inhärente Parallelität einer Shared-Nothing-Architektur macht sie für die Art von Table-Scan / Aggregate-Abfragen, die für ein Data-Warehouse charakteristisch sind, gut geeignet. Diese Art von Operation kann nahezu linear mit der Anzahl der Verarbeitungsknoten skaliert werden. Große Verknüpfungen über Knoten hinweg verursachen in der Regel einen höheren Aufwand, da die Semi-Join-Vorgänge viel Netzwerkverkehr generieren können.

Das Verschieben großer Datenmengen ist weniger nützlich für Transaktionsverarbeitungsanwendungen, bei denen der Aufwand für mehrere Aktualisierungen diese Art von Architektur weniger attraktiv macht als bei einer gemeinsam genutzten Festplatte. Daher wird diese Art von Architektur in Data-Warehouse-Anwendungen häufig nicht verwendet.

Sharding, Quorum-Replikation und mögliche Konsistenz

Die Quorum-Replikation ist eine Einrichtung, bei der ein DBMS Daten für eine hohe Verfügbarkeit repliziert. Dies ist nützlich für Systeme, die auf billigerer Standardhardware ohne integrierte Hochverfügbarkeitsfunktionen wie einem SAN arbeiten sollen. Bei diesem Systemtyp werden die Daten für Leseleistung und redundanten Speicher auf mehrere Speicherknoten repliziert, um das System gegen Hardwareausfälle eines Knotens resistent zu machen.

Die Replikation von Schreibvorgängen an alle Knoten ist jedoch O (M x N) für M Knoten und N Schreibvorgänge. Dies verteuert Schreibvorgänge, wenn der Schreibvorgang auf alle Knoten repliziert werden muss, bevor eine Transaktion festgeschrieben werden darf. Die Quorum-Replikation ist ein Kompromiss, mit dem Schreibvorgänge sofort auf eine Teilmenge der Knoten repliziert und dann von einer Hintergrundaufgabe träge auf die anderen Knoten geschrieben werden können. Schreibvorgänge können schneller festgeschrieben werden, wobei ein gewisses Maß an Redundanz gewährleistet wird, indem sichergestellt wird, dass sie auf eine minimale Teilmenge (Quorum) von Knoten repliziert werden, bevor die Transaktion als festgeschrieben an den Client gemeldet wird.

Das bedeutet, dass beim Ablesen von Knoten außerhalb des Quorums veraltete Versionen der Daten angezeigt werden, bis der Hintergrundprozess das Schreiben von Daten auf die restlichen Knoten abgeschlossen hat. Die Semantik ist als "Endgültige Konsistenz" bekannt und kann je nach den Anforderungen Ihrer Anwendung akzeptabel oder nicht akzeptabel sein, bedeutet jedoch, dass Transaktions-Commits bei der Ressourcennutzung näher an O (1) als an O (n) liegen.

Beim Sharding muss der Client über die Partitionierung von Daten in den Datenbanken informiert sein. Dabei wird häufig ein Algorithmus verwendet, der als "konsistentes Hashing" bezeichnet wird. In einer Sharded-Datenbank hat der Client den Schlüssel, um zu bestimmen, an welchen Server im Cluster die Abfrage gesendet werden soll. Da die Anforderungen auf die Knoten im Cluster verteilt sind, gibt es keinen Engpass mit einem einzelnen Abfragekoordinatorknoten.

Mit diesen Techniken kann eine Datenbank nahezu linear skaliert werden, indem dem Cluster Knoten hinzugefügt werden. Theoretisch ist eine Quorum-Replikation nur erforderlich, wenn das zugrunde liegende Speichermedium als unzuverlässig angesehen werden soll. Dies ist nützlich, wenn Commodity-Server verwendet werden sollen, ist jedoch von geringerem Wert, wenn der zugrunde liegende Speichermechanismus über ein eigenes Hochverfügbarkeitsschema verfügt (z. B. ein SAN mit gespiegelten Controllern und Mehrwegekonnektivität zu den Hosts).

Beispielsweise implementiert Googles BigTable die Quorum-Replikation nicht selbst, obwohl es sich in GFS befindet, einem Cluster-Dateisystem, das die Quorum-Replikation verwendet. BigTable (oder ein anderes Shared-Nothing-System) könnte ein zuverlässiges Speichersystem mit mehreren Controllern verwenden und die Daten auf die Controller verteilen. Ein paralleler Zugriff würde dann durch Partitionierung der Daten erreicht.

Zurück zu RDBMS-Plattformen

Es gibt keinen inhärenten Grund, warum diese Techniken nicht mit einem RDBMS verwendet werden könnten. Das Sperr- und Versionsmanagement wäre auf einem solchen System jedoch recht komplex, und jeder Markt für ein solches System dürfte ziemlich spezialisiert sein. Keine der gängigen RDBMS-Plattformen verwendet die Quorum-Replikation, und mir ist kein RDBMS-Produkt bekannt (zumindest keines mit einer signifikanten Akzeptanz), das dies tut.

Shared-Disk- und Shared-Nothing-Systeme können auf sehr große Workloads skaliert werden. Beispielsweise kann Oracle RAC 63 Verarbeitungsknoten (die selbst große SMP-Maschinen sein können) und eine beliebige Anzahl von Speichercontrollern im SAN unterstützen. Ein IBM Sysplex (ein Cluster aus zSeries-Mainframes) kann mehrere Mainframes (jeweils mit einer beträchtlichen Verarbeitungsleistung und einer eigenen E / A-Bandbreite) und mehrere SAN-Controller unterstützen. Diese Architekturen können sehr große Transaktionsvolumina mit ACID-Semantik unterstützen, setzen jedoch einen zuverlässigen Speicher voraus. Teradata, Netezza und andere Anbieter stellen leistungsstarke Analyseplattformen auf der Basis von Shared-Nothing-Designs her, die sich für extrem große Datenmengen eignen.

Bisher wird der Markt für billige, aber hochvolumige ACID-RDBMS-Plattformen von MySQL dominiert, das Sharding und Multi-Master-Replikation unterstützt. MySQL verwendet keine Quorum-Replikation, um den Schreibdurchsatz zu optimieren. Daher sind Transaktions-Commits teurer als auf einem NoSQL-System. Sharding ermöglicht sehr hohe Lesedurchsätze (z. B. verwendet Facebook MySQL in großem Umfang), sodass sich diese Art von Architektur gut auf leselastige Workloads skalieren lässt.

Eine interessante Debatte

BigTable ist eine Shared-Nothing-Architektur (im Wesentlichen ein verteiltes Schlüssel-Wert-Paar), auf die Michael Hausenblas weiter unten hinweist . Meine ursprüngliche Evaluierung umfasste die MapReduce-Engine, die nicht Teil von BigTable ist, aber normalerweise in Verbindung mit den gängigsten Implementierungen (z. B. Hadoop / HBase und das MapReduce-Framework von Google) verwendet wird.

Wenn Sie diese Architektur mit Teradata vergleichen, das eine physische Affinität zwischen Speicher und Verarbeitung aufweist (dh die Knoten verfügen über einen lokalen Speicher und nicht über ein gemeinsam genutztes SAN), könnten Sie argumentieren, dass BigTable / MapReduce über das global sichtbare parallele Speichersystem eine gemeinsam genutzte Festplattenarchitektur ist.

Der Verarbeitungsdurchsatz eines MapReduce-Systems wie Hadoop wird durch die Bandbreite eines nicht blockierenden Netzwerkschalters eingeschränkt. ¹ Nicht blockierende Switches können jedoch aufgrund der Parallelität, die dem Design eigen ist, Aggregate mit großer Bandbreite verarbeiten, sodass sie in der Praxis nur selten eine signifikante Einschränkung der Leistung darstellen. Dies bedeutet, dass eine gemeinsam genutzte Festplattenarchitektur (möglicherweise besser als gemeinsam genutztes Speichersystem bezeichnet) für große Arbeitslasten skaliert werden kann, obwohl der Netzwerk-Switch theoretisch ein zentraler Engpass ist.

Der ursprüngliche Punkt war, zu beachten, dass ein partitioniertes Speichersubsystem mit mehreren Speicherknoten (z. B. BigTable-Tablet-Server oder SAN-Controller), obwohl dieser zentrale Engpass in Systemen mit gemeinsam genutzten Festplatten besteht, immer noch auf große Arbeitslasten skaliert werden kann. Eine nicht blockierende Switch-Architektur kann (theoretisch) so viele aktuelle Verbindungen verarbeiten, wie Ports vorhanden sind.

¹ Natürlich stellen auch die verfügbaren Verarbeitungs- und E / A-Durchsätze eine Leistungsbeschränkung dar, aber der Netzwerk-Switch ist ein zentraler Punkt, durch den der gesamte Datenverkehr geleitet wird.

Relationale Datenbanken können wie NoSQL-Lösungen gruppiert werden. Das Beibehalten von ACID-Eigenschaften kann dies komplexer machen, und man muss sich der Kompromisse bewusst sein, die zum Beibehalten dieser Eigenschaften gemacht wurden. Leider hängt genau das, was die Kompromisse sind, von der Arbeitsbelastung und natürlich von den Entscheidungen ab, die beim Entwerfen der Datenbanksoftware getroffen wurden.

Beispielsweise kann ein primärer OLTP-Workload eine zusätzliche Wartezeit für einzelne Abfragen aufweisen, selbst wenn der Durchsatz des Clusters gut skaliert wird. Diese zusätzliche Latenz kann unbemerkt bleiben oder zu einem echten Deal Breaker werden, je nach Anwendung. Im Allgemeinen wird durch Clustering der Durchsatz verbessert und die Latenz beeinträchtigt, aber selbst diese "Regel" ist verdächtig, wenn die Abfragen einer Anwendung besonders für die parallele Verarbeitung geeignet sind.

Das Unternehmen, für das ich arbeite, Clustrix , bietet eine Reihe homogener Rechen- und Speicherknoten, die durch ein relativ schnelles Netzwerk verbunden sind. Relationale Daten werden auf Indexbasis in Teilen, die wir "Slices" nennen, über die Knoten verteilt. Jedes Segment verfügt über zwei oder mehr Replikate, die im Cluster verteilt sind, um die Lebensdauer bei einem Ausfall des Knotens oder der Festplatte zu gewährleisten. Clients können eine Verbindung zu einem beliebigen Knoten im Cluster herstellen, um mithilfe des MySQL-Verbindungsprotokolls Abfragen durchzuführen.

Es ist etwas unnatürlich, die Komponenten einer ACID-Datenbank unabhängig voneinander zu betrachten, da so viele davon zusammenpassen.

Atomizität - Clustrix verwendet zwei Phasen-Commits, um die Atomizität sicherzustellen. UPDATE- und DELETE-Operationen sperren auch Zeilen in unserem Distributed Lock Manager, da wir diese Operationen intern in SELECT umwandeln, gefolgt von exakten UPDATE / DELETE-Operationen.

Atomicity erhöht offensichtlich die Menge an Nachrichten zwischen den an einer Transaktion beteiligten Knoten und erhöht die Belastung dieser Knoten, um das Festschreibungsprotokoll zu verarbeiten. Dies ist Teil des Overheads für ein verteiltes System und würde die Skalierbarkeit einschränken, wenn jeder Knoten an jeder Transaktion beteiligt ist. Knoten nehmen jedoch nur an einer Transaktion teil, wenn eine der Repliken geschrieben wird.

Konsistenz - Fremdschlüssel werden als Trigger implementiert, die zum Festschreibungszeitpunkt ausgewertet werden. UPDATE- und DELETE-Operationen mit großem Bereich können unsere Leistung aufgrund von Sperren beeinträchtigen, aber wir sehen diese glücklicherweise nicht allzu oft. Es ist weitaus üblicher, dass eine Transaktion einige Zeilen aktualisiert / löscht und dann festschreibt.

Der andere Teil der Konsistenz besteht darin, ein Quorum über das PAXOS-Konsensprotokoll aufrechtzuerhalten, das sicherstellt, dass nur Cluster mit der Mehrheit der bekannten Knoten Schreibvorgänge ausführen können. Es ist natürlich möglich, dass ein Cluster ein Quorum hat, aber noch Daten fehlen (alle Replikate eines Slices sind offline), was dazu führt, dass Transaktionen, die auf eines dieser Slices zugreifen, fehlschlagen.

Isolierung - Clustrix bietet MVCC-Isolierung auf Containerebene. Unsere Atomicity-Garantie, dass alle anwendbaren Replikate einen bestimmten Schreibzugriff erhalten, bevor wir die festgelegte Transaktion melden, reduziert das Isolationsproblem größtenteils auf das, was Sie im nicht gruppierten Fall hätten.

Haltbarkeit - Jeder Teil relationaler Daten wird auf zwei oder mehr Knoten gespeichert, um die Ausfallsicherheit bei einem Knoten- oder Festplattenfehler zu gewährleisten. Es ist wahrscheinlich auch erwähnenswert, dass die Appliance-Version unseres Produkts über eine NVRAM-Karte verfügt, auf der der WAL aus Leistungsgründen gespeichert ist. Viele Einzelinstanzdatenbanken verbessern die Leistung ihrer WALs, indem sie nicht bei jedem Commit, sondern in Intervallen prüfen. Dieser Ansatz ist in einem verteilten System problematisch, da die Wiedergabe auf "Wohin?" eine komplizierte Frage. Wir umgehen dies im Gerät, indem wir eine Garantie für die harte Haltbarkeit geben.

Die grundlegende Antwort lautet, dass das Konsistenzmodell anders ist. Ich schreibe dies, um die Antwort von ConcernedOfTunbridge zu erweitern, die eigentlich der Bezugspunkt dafür sein sollte.

Der Grundgedanke des ACID-Konsistenzmodells besteht darin, dass es eine Reihe grundlegender Garantien für den Zustand der Daten im gesamten System gibt. Diese Garantien unterliegen den Einschränkungen des CAP-Theorems. Dies bedeutet, dass Sie alle maßgeblichen Quellen auf derselben Seite haben müssen, damit sie funktionieren, bevor Sie der Anwendung mitteilen, dass Sie eine Transaktion durchgeführt haben. Die Multi-Master-Replikation ist daher sehr schwierig, ohne auf diese Einschränkungen zu stoßen. Sobald Sie mit der asynchronen Replikation in einer Multi-Master-Umgebung beginnen, gehen diese Garantien aus dem Fenster. Das ACID-Konsistenzmodell ist ein starkes Konsistenzmodell für wichtige oder kritische Informationen.

Das BASE-Konsistenzmodell ist ein schwaches Konsistenzmodell für nicht kritische Informationen. Da die Garantien erheblich schwächer sind, ist die Fähigkeit, solche schwachen Garantien in Multi-Master-Systemen anzubieten, leichter zu erreichen, da die Garantien ebenfalls schwach sind.

RDBMS kann und kann aber genauso gut skalieren wie NoSQL-Lösungen!

Es gibt jedoch Fälle, in denen RDBMS in einem Ausmaß skaliert werden können und können, das NoSQL möglicherweise nicht einmal erreichen kann. Das macht es einfach anders. Ich werde Postgres-XC als Beispiel dafür betrachten, wie eine Skalierung möglich ist, ohne auf starke Konsistenzgarantien zu verzichten.

Diese speziellen RDBMS implementieren eine Art Sharding-Lösung mit einem Proxy und eine Art Shared-Disk-Architektur, die jedoch erheblich komplexer ist als beide. Diese lassen sich nicht auf die gleiche Weise skalieren wie NoSQL-Lösungen, sodass die Kompromisse unterschiedlich sind.

Das Postgres-XC-Modell ist meines Wissens von Teradata inspiriert. Es besteht aus Knoten in zwei verschiedenen Rollen, als Speicherknoten oder Koordinatoren. Koordinatoren sind multimasterfähig (es ist keine echte Replikation erforderlich) und stellen eine Verbindung zu Speicherknoten her, um die eigentliche Datenverarbeitung durchzuführen. Die Speicherknoten werden in einer Master-Slave-Konfiguration repliziert. Jeder Speicherknoten enthält im Wesentlichen einen Shard der Datenbank, die Koordinatoren behalten jedoch ein konsistentes Bild der Daten bei.

Hierbei handelt es sich um eine wesentliche Aufgabentrennung. Die Speicherknoten verwalten Daten, überprüfen Einschränkungen, lokal durchsetzbare Fremdschlüsseleinschränkungen und verarbeiten zumindest einige Datenaggregationen. Die Koordinatoren behandeln Fremdschlüssel, die nicht lokal erzwungen werden können, sowie Fenster- und andere Datenaspekte, die möglicherweise von mehreren Datenknoten abgerufen werden. Im Wesentlichen ermöglichen Koordinatoren ACID bei verteilten Transaktionen in einem Multi-Master-Setup, bei dem der Benutzer nicht einmal weiß, dass die Transaktionen verteilt sind.

In dieser Hinsicht bietet Postgres-XC etwas wie die NoSQL-Skalierungsoptionen, jedoch ist die Komplexität aufgrund der zusätzlichen Konsistenzgarantien etwas höher. Ich verstehe, dass es kommerzielle RDBMS gibt, die diese Art von Skalierbarkeit bieten. Teradata macht das. Darüber hinaus können gemeinsam genutzte Festplattensysteme auf ähnliche Weise skaliert werden, und sowohl DB2 als auch Oracle bieten solche Lösungen an. Es ist also völlig unfair zu sagen, dass RDBMS dies nicht können. Sie können. In der Vergangenheit war der Bedarf jedoch so gering, dass Skaleneffekte nicht ausreichten, um die proprietären Lösungen für die meisten Spieler sehr erschwinglich zu machen.

Endlich ein Hinweis zu VoltDB. Wie die NoSQL-Lösungen sehe ich VoltDB als ein sehr spezialisiertes Tool. Es ist sehr schnell, geht jedoch zu Lasten von Multi-Round-Trip-Transaktionen und der Haltbarkeit auf der Festplatte. Dies bedeutet, dass Sie ganz andere Bedenken haben. VoltDB bekommen Sie, wenn RDBMS-Pioniere eine NoSQL-Lösung bauen ;-). VoltDB ist zum Teil schnell, weil es Nebenläufigkeit und Haltbarkeit außerhalb der Gleichung definiert. Die Dauerhaftigkeit wird zu einer Netzwerkeigenschaft, nicht zu einer Eigenschaft innerhalb des Hosts, und die Parallelität wird dadurch verwaltet, dass Abfragen einzeln, intern parallelisiert, in sequenzieller Reihenfolge ausgeführt werden. Es ist kein traditionelles RDBMS (und das ist auch gut so, da es dort eingesetzt werden kann, wo es das traditionelle RDBMS nicht kann, aber das Gegenteil ist auch sehr richtig).

Bearbeiten: Es ist auch wichtig, die Auswirkungen von Verknüpfungen zu berücksichtigen. In einem Cluster werden Verknüpfungen zu einem ganz anderen Leistungsproblem. Befindet sich alles auf demselben Knoten, kann dies die Leistung verbessern. Wenn Sie jedoch einen Roundtrip zu einem anderen Knoten durchführen müssen, sind die Kosten sehr hoch. Datenmodelle machen also Unterschiede und der Ansatz des Clusters hat Auswirkungen auf die Leistung. Ansätze wie Postgres-XC und Postgres-XL setzen voraus, dass Sie ein wenig Zeit damit verbringen können, sich Gedanken zu machen, um Ihre Daten angemessen zu speichern und verbundene Daten zusammenzuhalten. Dies bedeutet jedoch einen Mehraufwand für das Design. Auf der anderen Seite skaliert dies viel besser als viele NoSQL-Lösungen und kann entsprechend angepasst werden. Zum Beispiel verwenden wir (bei Adjust) eine NoSQL-ähnliche Clustering-Strategie für unsere 3.5PB-Daten in PostgreSQL, die im Grunde genommen eine Protokollanalyse ist. Ein Großteil unseres Designs ist stark von NoSQL-Clustering-Strategien inspiriert. Daher schränkt das Datenmodell manchmal auch das Clustering-Modell ein.

Meine Antwort ist nicht so gut geschrieben wie die vorherige, aber es geht los.

Michael Stonebraker von Ingres Fame hat einen MPP-Shared-Nothing-Spaltenspeicher (Vertica) und eine MPP-Shared-Nothing-New-SQL-Datenbank (VoltDB) erstellt, die Daten zwischen verschiedenen Knoten in einem Cluster verteilt und ACID verwaltet. Vertica wurde inzwischen von HP gekauft.

Ich glaube, dass auch andere New SQL-Datenbanken ACID beibehalten, obwohl ich nicht sicher bin, wie viele von ihnen ihre Zeilen über einen Cluster usw. verteilen.

Hier ist ein Vortrag, den Stonebraker über New SQL im Vergleich zu NoSQL und "Old SQL" hielt. http://www.youtube.com/watch?v=uhDM4fcI2aI

Das MySQL-Clustering kann mithilfe von Multi-Mastering-Replikation und Hashing-Shards im gesamten Cluster Shards erstellen.