Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- bigdata:newsql [2015/10/05 21:31] – [Architektur-Prinzipien] brueck
+++ bigdata:newsql [2015/10/05 21:33] – [Vergleich OldSQL, NoSQL und NewSQL] brueck
@@ Zeile 64: / Zeile 64: @@
 Auf Grundlage von Shore wurde dann mit „H-Store“, aus dem später „VoltDB“ hervorging, eine moderne, relationale Datenbank geschaffen, bei der versucht wurde, diesen Overhead zu eliminieren oder zu minimieren, um ein möglichst effizientes System zu schaffen, das auch für modernes OLTP (Online Transaction Processing/Online Transaktionsverarbeitung) geeignet ist.
-Für die Umsetzung nutzten sie Techniken wie die **Shared-Nothing**-Architektur, bei der jeder Cluster-Knoten unabhängig ist, da er keine Ressourcen (Speicher) teilt und selbst auch nur auf seinem Teil der Daten arbeitet. Somit stellt ein einzelner Knoten auch keinen Single Point of Failure für das ganze System mehr dar, da die anderen im Falle des Versagens unabhängig weiterarbeiten können. Dafür kommt es bei Anfragen zu Performance-Einbußen, wenn auf Daten über mehrere Knoten/Shards hinweg zugegriffen werden muss ([[bigdata:literatur|Pavlo 2012]]).
+Für die Umsetzung nutzten sie Techniken wie die **Shared-Nothing**-Architektur, bei der jeder Cluster-Knoten unabhängig ist, da er keine Ressourcen (Speicher) teilt und selbst auch nur auf seinem Teil der Daten arbeitet. Somit stellt ein einzelner Knoten auch keinen Single Point of Failure für das ganze System mehr dar, da die anderen im Falle des Versagens unabhängig weiterarbeiten können. Dafür kommt es bei Anfragen zu Performance-Einbußen, wenn auf Daten über mehrere Knoten/Shards hinweg zugegriffen werden muss ([[bigdata:literatur#p|Pavlo 2012]]).
 Vor allem wurde auf [[bigdata:inmemory|In-Memory-Technik]] gesetzt, womit auch sämtliche Puffer-Verwaltung und Plattenzugriffe vermieden werden, da die Daten allzeit im RAM sofort verfügbar gehalten werden. Transaktionen dauern so auch nur wenige Milli- bis Mikrosekunden. Datenhaltung auf Festplatten ist nicht vorgesehen, zur Ausfallsicherheit gehört es daher, dass Daten (im RAM) auf verschiedenen Rechnern repliziert werden.
-Um Latching- und Locking-Overhead zu vermeiden, wurde auf klassisches Multithreading mit geteilten Ressourcen verzichtet, stattdessen wird pro Prozessorkern ein **Single-Thread** betrieben, der einen eigenes Stück RAM für sich bekommt und keinerlei Ressourcen oder Datenstrukturen teilt. In einem System mit n CPUs wird der Hauptspeicher also in n Teile geteilt. Somit ist auch keine aufwendige Ressourcenverwaltung wie in aktuellen (multithreaded) RDBMS nötig. ([[bigdata:literatur|Pavlo 2012]])
+Um Latching- und Locking-Overhead zu vermeiden, wurde auf klassisches Multithreading mit geteilten Ressourcen verzichtet, stattdessen wird pro Prozessorkern ein **Single-Thread** betrieben, der einen eigenes Stück RAM für sich bekommt und keinerlei Ressourcen oder Datenstrukturen teilt. In einem System mit n CPUs wird der Hauptspeicher also in n Teile geteilt. Somit ist auch keine aufwendige Ressourcenverwaltung wie in aktuellen (multithreaded) RDBMS nötig. ([[bigdata:literatur#p|Pavlo 2012]])
-Für die Sicherheit des Datenbestandes setzen H-Store und VoltDB auf **Command-Logging**, bei dem ein Logfile auf ein Minimum reduziert wird, indem nur die „Befehle“ (in diesen Systemen sind es „Stored Procedures“, die wiederum mehrere SQL-Befehle enthalten können) geloggt werden, die die Daten verändern. Zusammen mit Snapshots lässt sich bei einem Ausfall der letzte Datenstand wiederherstellen. Um Plattenzugriffe zu minimieren, werden die Logs zunächst im RAM gehalten, und erst nach festgelegtem Zeitintervall auf Platte persistiert. ([[bigdata:literatur|VoltDB 2015]]) Um zusätzlich für Ausfallsicherheit und einen konsistenten Datenbestand zu sorgen, werden Knoten mit Partitions-Kopien geführt. Vor einem Transaktions-Commit werden die Daten synchron an alle replizierten Partitionen gesendet ([[bigdata:literatur|VoltDB o.J.]]).
+Für die Sicherheit des Datenbestandes setzen H-Store und VoltDB auf **Command-Logging**, bei dem ein Logfile auf ein Minimum reduziert wird, indem nur die „Befehle“ (in diesen Systemen sind es „Stored Procedures“, die wiederum mehrere SQL-Befehle enthalten können) geloggt werden, die die Daten verändern. Zusammen mit Snapshots lässt sich bei einem Ausfall der letzte Datenstand wiederherstellen. Um Plattenzugriffe zu minimieren, werden die Logs zunächst im RAM gehalten, und erst nach festgelegtem Zeitintervall auf Platte persistiert. ([[bigdata:literatur#v|VoltDB 2015]]) Um zusätzlich für Ausfallsicherheit und einen konsistenten Datenbestand zu sorgen, werden Knoten mit Partitions-Kopien geführt. Vor einem Transaktions-Commit werden die Daten synchron an alle replizierten Partitionen gesendet ([[bigdata:literatur#v|VoltDB o.J.]]).
-Logging kann alternativ auf ein kurzlebigen, im Hauptspeicher gehaltenen Undo-Log (für den Fall, dass eine Transaktion fehlschlägt) reduziert werden, der nach einer erfolgreichen Transaktion wieder gelöscht wird ([[bigdata:literatur|Stonebraker et al. 2007: S. 3]]).
+Logging kann alternativ auf ein kurzlebigen, im Hauptspeicher gehaltenen Undo-Log (für den Fall, dass eine Transaktion fehlschlägt) reduziert werden, der nach einer erfolgreichen Transaktion wieder gelöscht wird ([[bigdata:literatur#s|Stonebraker et al. 2007: S. 3]]).
 Für Abfragen kommen vom Nutzer vordefinierte **Stored Procedures** zum Einsatz, die in Java geschrieben werden und eingebetteten SQL-92-Code zur Datenbankabfrage nutzen.
-Eine weitere interessante NewSQL-Implementierung ist „**Splice Machine**“. Dabei handelt es sich um eine relationale Datenbank, die auf [[bigdata:hadoop|Hadoop]] aufsetzt. Genauer ersetzt sie die Storage-Engine der leichtgewichtigen relationalen Datenbank Apache „Derby“ mit dem HDFS und HBase. Damit ist es möglich, auch große Datenvolumen zu verarbeiten, die die Kapazitäten eines einzelnen RDBMS-Servers oder eines NewSQL-In-Memory-Clusters übersteigen würden. Sie eignet sich sowohl für ACID-Transaktionen, als auch analytische Aufgaben und bietet volle ANSI-SQL-Kompatibilität. (Vgl. [[bigdata:literatur|Splice Machine 2015]])
+Eine weitere interessante NewSQL-Implementierung ist „**Splice Machine**“. Dabei handelt es sich um eine relationale Datenbank, die auf [[bigdata:hadoop|Hadoop]] aufsetzt. Genauer ersetzt sie die Storage-Engine der leichtgewichtigen relationalen Datenbank Apache „Derby“ mit dem HDFS und HBase. Damit ist es möglich, auch große Datenvolumen zu verarbeiten, die die Kapazitäten eines einzelnen RDBMS-Servers oder eines NewSQL-In-Memory-Clusters übersteigen würden. Sie eignet sich sowohl für ACID-Transaktionen, als auch analytische Aufgaben und bietet volle ANSI-SQL-Kompatibilität. (Vgl. [[bigdata:literatur#s|Splice Machine 2015]])
-Es vereint dabei SQL mit der [[bigdata:skalierung|Skalierbarkeit]] von Hadoop. Aufgaben verteilt, parallel bearbeitet und nachher wieder zusammengeklebt (engl. „splice“). Splice Machine sieht sich als Ersatz, wenn Systeme wie Microsoft SQL Server, IBM DB2 oder MySQL an ihre Performance- oder Kostengrenzen stoßen (nach [[bigdata:literatur|Henschen 2014]]).
+Es vereint dabei SQL mit der [[bigdata:skalierung|Skalierbarkeit]] von Hadoop. Aufgaben verteilt, parallel bearbeitet und nachher wieder zusammengeklebt (engl. „splice“). Splice Machine sieht sich als Ersatz, wenn Systeme wie Microsoft SQL Server, IBM DB2 oder MySQL an ihre Performance- oder Kostengrenzen stoßen (nach [[bigdata:literatur#h|Henschen 2014]]).
 ===== Vergleich OldSQL, NoSQL und NewSQL =====
-Im Gegensatz zu den traditionellen RDBMS (OldSQL) sind NewSQL-Systeme, ebenso wie die [[bigdata:nosql|NoSQL-Systeme]], [[bigdata:skalierung|skalierbar]] und hochverfügbar, sind aber dennoch relationale Systeme, die vollwertige [[bigdata:konsistenz|ACID]]-Transaktionen und SQL unterstützen.
+Im Gegensatz zu den traditionellen RDBMS (OldSQL) sind NewSQL-Systeme, ebenso wie die [[bigdata:nosql|NoSQL-Systeme]], [[bigdata:skalierung|skalierbar]] und hochverfügbar, sind aber dennoch relationale Systeme, die vollwertige [[bigdata:konsistenz#acid|ACID]]-Transaktionen und SQL unterstützen.
-Ein Vorteil gegenüber NoSQL ist, dass sie mit den standardisierten Zugriffs-APIs und Treiber der traditionellen Systeme kompatibel sind, das heißt, dass bestehende Applikationen auch nicht angepasst werden müssen. Dies ist auch ein Vorteil gegenüber den NoSQL-Systemen, die noch über keinen einheitlichen Zugriffs-Standard verfügen. ([[bigdata:literatur|Welkenbach/Schmutz 2012]]) Da sie jedoch auf das relationale Modell und SQL als Abfragesprache bauen, liegt ihnen, anders als den NoSQL-Datenbanken, ein Schema zugrunde, was sie in Hinsicht auf die Flexibilität im Umgang mit [[bigdata:big_data|Big Data]] doch einschränkt.
+Ein Vorteil gegenüber NoSQL ist, dass sie mit den standardisierten Zugriffs-APIs und Treiber der traditionellen Systeme kompatibel sind, das heißt, dass bestehende Applikationen auch nicht angepasst werden müssen. Dies ist auch ein Vorteil gegenüber den NoSQL-Systemen, die noch über keinen einheitlichen Zugriffs-Standard verfügen. ([[bigdata:literatur#w|Welkenbach/Schmutz 2012]]) Da sie jedoch auf das relationale Modell und SQL als Abfragesprache bauen, liegt ihnen, anders als den NoSQL-Datenbanken, ein Schema zugrunde, was sie in Hinsicht auf die Flexibilität im Umgang mit [[bigdata:big_data|Big Data]] doch einschränkt.
-Allgemein bestimmt die Art der Daten auch die Wahl der Datenbank. Wird Datenintegrität und Konsistenz verlangt, steht die Wahl zwischen RDBMS und NewSQL. NewSQL-Systeme wurden dabei mit besonderem Fokus auf Performance und Skalierbarkeit entworfen. OldSQL-Systeme wurden für die Hardware-Architekturen der 70er und 80er entwickelt und werden so teilweise durch unnötig großen Overhead gebremst, wohingegen die neue Generation versucht, diesen unter Einbeziehung neuer Hardwareentwicklungen weitestgehend zu minimieren, um so um Größenordnungen schneller als traditionelle RDBMS zu werden (vgl. [[bigdata:literatur|Stonebraker et al 2007]]).
+Allgemein bestimmt die Art der Daten auch die Wahl der Datenbank. Wird Datenintegrität und Konsistenz verlangt, steht die Wahl zwischen RDBMS und NewSQL. NewSQL-Systeme wurden dabei mit besonderem Fokus auf Performance und Skalierbarkeit entworfen. OldSQL-Systeme wurden für die Hardware-Architekturen der 70er und 80er entwickelt und werden so teilweise durch unnötig großen Overhead gebremst, wohingegen die neue Generation versucht, diesen unter Einbeziehung neuer Hardwareentwicklungen weitestgehend zu minimieren, um so um Größenordnungen schneller als traditionelle RDBMS zu werden (vgl. [[bigdata:literatur#s|Stonebraker et al 2007]]).
-Ist es nötig, dass das System zu skalieren, bieten sich NoSQL- und NewSQL-Systeme an, da sie, im Gegensatz du RDBMS, nicht auf ein kostspieliges [[bigdata:skalierung#vertikale_skalierung|vertikales Skalieren]] beschränkt sind, sondern frei [[bigdata:skalierung#horizontale_skalierung|horizontal skalierbar]] sind, sich also ohne große Komplikationen durch neue Maschinen (mit kostengünstiger Standardhardware) ergänzen lassen. Dabei gelten jedoch insofern Einschränkungen, als dass die meisten NewSQL-Systeme hauptsächlich für schnelle Transaktionen und Operationen ausgelegt wurden, diese also nur in kleinem Umfang machen und JOINs über zu viele Knoten vermeiden, da sich dies negativ auf die Performance auswirkt (vgl. [[bigdata:literatur|Cattel 2010: S. 9]]; [[bigdata:literatur|Pavlo 2012]]).
+Ist es nötig, dass das System zu skalieren, bieten sich NoSQL- und NewSQL-Systeme an, da sie, im Gegensatz du RDBMS, nicht auf ein kostspieliges [[bigdata:skalierung#vertikale_skalierung|vertikales Skalieren]] beschränkt sind, sondern frei [[bigdata:skalierung#horizontale_skalierung|horizontal skalierbar]] sind, sich also ohne große Komplikationen durch neue Maschinen (mit kostengünstiger Standardhardware) ergänzen lassen. Dabei gelten jedoch insofern Einschränkungen, als dass die meisten NewSQL-Systeme hauptsächlich für schnelle Transaktionen und Operationen ausgelegt wurden, diese also nur in kleinem Umfang machen und JOINs über zu viele Knoten vermeiden, da sich dies negativ auf die Performance auswirkt (vgl. [[bigdata:literatur#c|Cattel 2010: S. 9]]; [[bigdata:literatur#p|Pavlo 2012]]).