Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- bigdata:nosql [2015/10/05 20:42] – [NoSQL] brueck
+++ bigdata:nosql [2015/10/05 20:45] – [Kriterien] brueck
@@ Zeile 16: / Zeile 16: @@
   * **Open Source**
-(Vgl. [[bigdata:literatur|Sadalage/Fowler 2012: S. 12]]; [[bigdata:literatur|Gull 2012: S. 18]]; [[bigdata:literatur|Pürner 2013]]).
+(Vgl. [[bigdata:literatur#s|Sadalage/Fowler 2012: S. 12]]; [[bigdata:literatur#g|Gull 2012: S. 18]]; [[bigdata:literatur#p|Pürner 2013]]).
 \\
@@ Zeile 23: / Zeile 23: @@
 Klassische relationale Datenbanksysteme erfassen strukturierte Daten, die durch Normalisierung aufgeteilt und dann in viele, durch Schlüssel-Beziehungen miteinander verknüpfte Tabellen gespeichert werden.  Um diese verteilten Datensätze nun zu verwenden (z.B. für eine Bestellung), werden sie mit Hilfe des SQL JOIN-Operators anhand von Schlüsseln aus den unterschiedlichen Tabellen (z.B. Artikel, Kundendaten) zusammengeführt. Diese Operation ist jedoch immer auch mit Plattenzugriffen verbunden und entsprechend zeitaufwendig. Je stärker ein Modell normalisiert wurde und je mehr Tabellen dadurch verknüpft werden müssen, desto mehr JOINs fallen auch an und drosseln die Performance und Reaktionszeit der Abfrage.
-Derartige JOINs gibt es in NoSQL-Systemen nicht. Stattdessen umgehen einige NoSQL-Vertreter Referenzen durch JOINs, indem sie jene Informationen zweckmäßig als Aggregat zusammenfassen, die auch zusammen gespeichert, verwaltet und betrachtet werden sollen ([[bigdata:literatur|Sadalage/Fowler 2012: S. 25]]). Das macht das Datenmodell wesentlich flexibler und ermöglicht so auch schnellere Schreib- und Lesezugriffe und vereinfacht ihre Verwaltung auf verteilten Systemen. Dafür nehmen sie Redundanzen in Kauf, da Plattenspeicher mittlerweile günstig ist und ausreichend zur Verfügung steht.
+Derartige JOINs gibt es in NoSQL-Systemen nicht. Stattdessen umgehen einige NoSQL-Vertreter Referenzen durch JOINs, indem sie jene Informationen zweckmäßig als Aggregat zusammenfassen, die auch zusammen gespeichert, verwaltet und betrachtet werden sollen ([[bigdata:literatur#s|Sadalage/Fowler 2012: S. 25]]). Das macht das Datenmodell wesentlich flexibler und ermöglicht so auch schnellere Schreib- und Lesezugriffe und vereinfacht ihre Verwaltung auf verteilten Systemen. Dafür nehmen sie Redundanzen in Kauf, da Plattenspeicher mittlerweile günstig ist und ausreichend zur Verfügung steht.
 Sollen doch einmal Beziehungen hergestellt werden, so ließen sich in den Aggregaten entsprechende Key-IDs einfügen. Diese werden jedoch nicht vom System als solche erkannt und machen nach Lesen der ID einen erneuten Zugriff auf die Datenbank nötig, um das entsprechend referenzierte Aggregat zu laden.
@@ Zeile 34: / Zeile 34: @@
 Allerdings bedeutet das Festlegen auf ein Schema auch, dass nur solche Daten gespeichert werden können, die auch dem vorher definierten Schema entsprechen. Änderungen sind zwar möglich (etwa mit dem SQL-Befehl ''ALTER TABLE''), können sich aber, je nach Umfang des Systems, als schwierig, umständlich und zeitintensiv erweisen und das System für mehrere Minuten oder gar Stunden lahmlegen. Doch gerade im Big Data-Zeitalter fallen viele Daten an, die nur semi- oder ganz unstrukturiert sind und sich eben nicht so einfach in atomare Attribute zerlegen und in Tabellen abspeichern lassen. Um dieser Problematik zu begegnen, verzichten NoSQL-Systeme auf Schemarestriktionen und wollen so einen flexibleren Umgang mit unstrukturierten Daten ermöglichen. Sie erlauben es, Datenbankeinträge frei um zusätzliche Felder zu erweitern, ohne diese Änderung vorher im Schema festlegen zu müssen.
-Sofern jedoch nicht sämtliche Daten eines Eintrags ausgegeben werden sollen, ist davon auszugehen, dass zumindest ein „indirektes Schema“ befolgt wird, das bspw. Annahmen darüber ermöglicht, dass Felder wie „Name“ oder „Preis“ mit entsprechenden Werten und Datentypen dahinter existieren, auf die zugegriffen werden kann. Doch die Datenbank selbst kann dieses nicht validieren, es beschränkt sich also auf Annahmen über die Datenstruktur innerhalb des Applikationscodes, der die Daten manipuliert ([[bigdata:literatur|Sadalage/Fowler 2012: S. 29]]).
+Sofern jedoch nicht sämtliche Daten eines Eintrags ausgegeben werden sollen, ist davon auszugehen, dass zumindest ein „indirektes Schema“ befolgt wird, das bspw. Annahmen darüber ermöglicht, dass Felder wie „Name“ oder „Preis“ mit entsprechenden Werten und Datentypen dahinter existieren, auf die zugegriffen werden kann. Doch die Datenbank selbst kann dieses nicht validieren, es beschränkt sich also auf Annahmen über die Datenstruktur innerhalb des Applikationscodes, der die Daten manipuliert ([[bigdata:literatur#s|Sadalage/Fowler 2012: S. 29]]).
 \\
@@ Zeile 44: / Zeile 44: @@
 **Skalierbarkeit**
-Die Lasten auf moderne internetbasierte Angebote wie etwa Onlineshops, soziale Netzwerke, Medienplattformen und dergleichen wachsen ständig. Sie müssen 24 Stunden am Tag, 7 Tage die Woche verfügbar sein und sehen sich mit immer größeren Lasten durch eine Unzahl an Usern und enormen Datenmengen mit vielen Transaktionen konfrontiert. Um bei solchen Lasten noch reibungslose Abläufe garantieren zu können, müssen die Systeme auf Clustern realisiert werden, die sich bei Bedarf möglichst einfach erweitern lassen können. Daher spielt die [[bigdata:skalierung|Skalierbarkeit]] bei NoSQL eine zentrale Rolle. ([[bigdata:literatur|Gull 2012: S. 18]]) Um nun den steigenden Anforderungen an eine Datenbank gerecht zu werden, ist ein flexibles Aufrüsten des ganzen Systems nötig. Relationale Datenbanken wurden für den Einsatz auf einem zentralisierten (shared everything) Ein-Server-System entwickelt und optimiert und eignen sich durch ihre strengen [[bigdata:konsistenz#acid|ACID]]-Konsistenzeigenschaften bei Transaktionen nur bedingt für eine horizontale Skalierung, da das Verteilen der Datenbank nur noch mehr Umstände bei der Integritätswahrung bedeuten würde. Daher bleibt hier nur ein kostspieliges Aufrüsten der Hardware der bestehenden Server. NoSQL-Systeme wurden dagegen von Anfang an als verteilte Datenbanksysteme und für horizontale Skalierung konzipiert. Sie eignen sich daher hervorragend für eine Lastenverteilung auf ein beliebig großes Cluster, das auch bei Lastenspitzen ohne Probleme flexibel vergrößert werden kann, verfolgen dafür mit „[[bigdata:konsistenz#base|BASE]]“ aber ein weniger strenges Konsistenzmodell („eventual consistency“) und verzichten zudem auf Transaktionen. Auch Replikationen spielen bei NoSQL-Systemen eine wichtige Rolle. Da die Daten auf verteilten Serverknoten gespeichert liegen, aber trotzdem eine Erreichbarkeit und Funktionalität vorausgesetzt wird, ist es nötig, Duplikate anzufertigen, die im Falle eines Ausfalls einzelner Knoten ohne Datenverluste zum Einsatz kommen können.
+Die Lasten auf moderne internetbasierte Angebote wie etwa Onlineshops, soziale Netzwerke, Medienplattformen und dergleichen wachsen ständig. Sie müssen 24 Stunden am Tag, 7 Tage die Woche verfügbar sein und sehen sich mit immer größeren Lasten durch eine Unzahl an Usern und enormen Datenmengen mit vielen Transaktionen konfrontiert. Um bei solchen Lasten noch reibungslose Abläufe garantieren zu können, müssen die Systeme auf Clustern realisiert werden, die sich bei Bedarf möglichst einfach erweitern lassen können. Daher spielt die [[bigdata:skalierung|Skalierbarkeit]] bei NoSQL eine zentrale Rolle. ([[bigdata:literatur#g|Gull 2012: S. 18]]) Um nun den steigenden Anforderungen an eine Datenbank gerecht zu werden, ist ein flexibles Aufrüsten des ganzen Systems nötig. Relationale Datenbanken wurden für den Einsatz auf einem zentralisierten (shared everything) Ein-Server-System entwickelt und optimiert und eignen sich durch ihre strengen [[bigdata:konsistenz#acid|ACID]]-Konsistenzeigenschaften bei Transaktionen nur bedingt für eine horizontale Skalierung, da das Verteilen der Datenbank nur noch mehr Umstände bei der Integritätswahrung bedeuten würde. Daher bleibt hier nur ein kostspieliges Aufrüsten der Hardware der bestehenden Server. NoSQL-Systeme wurden dagegen von Anfang an als verteilte Datenbanksysteme und für horizontale Skalierung konzipiert. Sie eignen sich daher hervorragend für eine Lastenverteilung auf ein beliebig großes Cluster, das auch bei Lastenspitzen ohne Probleme flexibel vergrößert werden kann, verfolgen dafür mit „[[bigdata:konsistenz#base|BASE]]“ aber ein weniger strenges Konsistenzmodell („eventual consistency“) und verzichten zudem auf Transaktionen. Auch Replikationen spielen bei NoSQL-Systemen eine wichtige Rolle. Da die Daten auf verteilten Serverknoten gespeichert liegen, aber trotzdem eine Erreichbarkeit und Funktionalität vorausgesetzt wird, ist es nötig, Duplikate anzufertigen, die im Falle eines Ausfalls einzelner Knoten ohne Datenverluste zum Einsatz kommen können.
 \\
 **Konsistenz**
-Geschwindigkeit ist im schnelllebigen [[bigdata:web20|Web 2.0]]-Zeitalter entscheidend. Unternehmen können sich lange Reaktionszeiten oder gar einen Ausfall des Systems nicht mehr leisten (sei er technischer Ursache oder wartungsbedingt). Services müssen täglich und rund um die Uhr performant verfügbar und funktionstüchtig sein. Untersuchungen haben gezeigt, dass lange Antwortzeiten von potentiellen (Online-)Nutzern nicht toleriert werden und die Wahrscheinlichkeit erhöhen, dass der Nutzer den Vorgang abbricht und eventuell andere Anbieter bevorzugt ([[bigdata:literatur|Borland 2013]]). Das Credo der neuen NoSQL-Generation ist daher Geschwindigkeit und Verfügbarkeit vor Konsistenz. Das steht nun aber im Gegenteil zu den traditionellen relationalen Datenbanken, die für einen konsistenten Zustand nach dem ACID-Prinzip mit Sperren arbeiten und so Verzögerungen in Kauf nehmen. NoSQL-Systeme richten sich nach den BASE-Richtlinien, die weniger Wert auf unbedingte Konsistenz legen, sondern davon ausgehen, dass sich einige Knoten für kurze Zeit inkonsistent sind und „eventuell“ den Konsistenten Zustand erreichen. Das System ist also //„[[bigdata:konsistenz#base|eventually consitent]]“// (optimistisch gesehen „irgendwann konsistent“), wobei Konsistenz eher eine Art Prozess ist. Für den Umgang mit kritischen Daten, etwa im Finanzbereich, sind Relationale Datenbanksysteme, die mit Transaktionen nach dem strengen ACID funktionieren, diesen NoSQL-Systemen vorzuziehen, da es hier darauf ankommt, dass z.B. ein Geldbetrag auch tatsächlich abgebucht wurde und nicht etwa nichtvorhandenes Geld ausgegeben wurde (weil der Kontostand eventuell nicht aktualisiert wurde).
+Geschwindigkeit ist im schnelllebigen [[bigdata:web20|Web 2.0]]-Zeitalter entscheidend. Unternehmen können sich lange Reaktionszeiten oder gar einen Ausfall des Systems nicht mehr leisten (sei er technischer Ursache oder wartungsbedingt). Services müssen täglich und rund um die Uhr performant verfügbar und funktionstüchtig sein. Untersuchungen haben gezeigt, dass lange Antwortzeiten von potentiellen (Online-)Nutzern nicht toleriert werden und die Wahrscheinlichkeit erhöhen, dass der Nutzer den Vorgang abbricht und eventuell andere Anbieter bevorzugt ([[bigdata:literatur#b|Borland 2013]]). Das Credo der neuen NoSQL-Generation ist daher Geschwindigkeit und Verfügbarkeit vor Konsistenz. Das steht nun aber im Gegenteil zu den traditionellen relationalen Datenbanken, die für einen konsistenten Zustand nach dem ACID-Prinzip mit Sperren arbeiten und so Verzögerungen in Kauf nehmen. NoSQL-Systeme richten sich nach den BASE-Richtlinien, die weniger Wert auf unbedingte Konsistenz legen, sondern davon ausgehen, dass sich einige Knoten für kurze Zeit inkonsistent sind und „eventuell“ den Konsistenten Zustand erreichen. Das System ist also //„[[bigdata:konsistenz#base|eventually consitent]]“// (optimistisch gesehen „irgendwann konsistent“), wobei Konsistenz eher eine Art Prozess ist. Für den Umgang mit kritischen Daten, etwa im Finanzbereich, sind Relationale Datenbanksysteme, die mit Transaktionen nach dem strengen ACID funktionieren, diesen NoSQL-Systemen vorzuziehen, da es hier darauf ankommt, dass z.B. ein Geldbetrag auch tatsächlich abgebucht wurde und nicht etwa nichtvorhandenes Geld ausgegeben wurde (weil der Kontostand eventuell nicht aktualisiert wurde).
 \\