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:32] – [Neuer Ansatz] 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]]).