Menü
Ein Beitrag von Adacor

Big Data – Mehr Durchblick im Datendschungel

Datendschungel Big DataVor kurzem haben mich meine Marketingkollegen darum gebeten, einen Artikel zum Thema „Big Data versus SQL“ zu verfassen. Dieser Anfrage komme ich gerne nach. Sie zeigt aber auch, dass Begriffe wie Big Data, SQL und NoSQL, relationale oder objektorientierte Datenbanken häufig in einen Topf geworfen und in beliebigen Kontexten miteinander verglichen werden. Tatsächlich hat das eine mit dem anderen zwangsweise nichts zu tun. Woher kommt dann diese Denkweise und wie kann man die Themen korrekt einordnen?

Das Datenvolumen steigt um 40 % pro Jahr – und insgesamt um Faktor 50 bis 2020. Das heißt, in drei Jahren werden es weltweit 44 Zettabyte Datenvolumen sein, das entspricht 5.200 Gigabyte pro Erdenbürger. soweit Michael Kroker von der Wirtschaftswoche. Verdeutlicht man sich diese Werte, so wird klar, dass zukünftig kein Unternehmen mehr um das Thema „Big Data“ herumkommen wird. Besonders spannend ist in diesem Zusammenhang die Frage nach den Möglichkeiten der Verarbeitung solcher Massendaten.

So sollte beispielsweise der Einsatz von Datenbanken niemals von der Vorliebe der Entwicklung abhängig sein, sondern sich immer am Anwendungszweck des jeweiligen IT-Projekts – bezogen auf die Gesamtinfrastruktur – orientieren. Der Einsatz einer relationalen Datenbank kann zum Beispiel durchaus sinnvoll sein, auch wenn das Modell selbst gerade nicht en vogue ist. Im Gegensatz dazu ist es vielleicht unvernünftig, eine NoSQL-Datenbank für einen überschaubaren und strukturierten Datenbestand einzusetzen, nur weil das Vorgehen gerade in aller Munde ist. Welches Datenbankmodell sich im Einzelnen am besten eignet, hängt vom Einsatzzweck ab.

Übersicht der gängigen Datenbankmodelle

  1. Relationale Datenbanken
  2. Objektorientierte Datenbanken
  3. Dokumentenbasierte Datenbanken

1. Relationale Datenbanken

Relationale Datenbanken können über SQL abgefragt werden. Sie zählen zu den am weitesten verbreiteten Datenbankmodellen. Der Grund dafür liegt darin, dass relationale Datenbanken einfach und flexibel zu erstellen und zu steuern sind. Am bekanntesten sind die Systeme von ORACLE, MySQL und MSSQL.

Bei dem relationalen Datenbankmodell findet die Datenspeicherung in strukturierten Tabellen statt. Diese stehen zueinander in einer Relation (Beziehung), die über einen Fremdschlüssel realisiert wird. Darüber hinaus können die Beziehungen mithilfe eines Primärschlüssels hergestellt werden. Das Ziel ist es dann, bestimmte Eigenschaften abzufragen, die den gleichen Primärschlüssel oder eine detaillierte Tabelle als Fremdschlüssel besitzen.

Jede Tabellenzeile (Tupel) steht dabei für einen Datensatz (Record). Darüber hinaus besteht jede Zeile aus einer Reihe von Attributen (Merkmalen). Diese stellen die Tabellenspalten dar. Über das Abfragen der in der Relation eingebundenen Tabellen werden die gewünschten Informationen errechnet und aufgelistet.

Die Themen „Performance“ und „fehlende Gewährleistung der Datenintegrität“ bringen bei komplexen Relationsmodellen und vielen Daten einige Nachteile mit. Die Performance-Probleme resultieren aus der Mengenlehre. So müssen die Tabellen zueinander geführt werden, um sie auszuwerten. Das passiert mit jeder Verknüpfung in einer Menge, die dann wieder mit der neuen Verknüpfung zusammengeführt wird. In der daraus entstehenden Endmenge werden die Ergebnisse gefiltert. Dieses Vorgehen führt bei vielen Tabellen zu hoher Komplexität und großen temporären Speicheraktionen. Die Rechenvorgänge dauern deshalb entsprechend lange und verbrauchen viel Speicher. Bei der Datenintegrität hingegen gibt es potenziell falsche Ergebnisse, wenn man die Integrität nicht „programmiert“ hat. Diese Nachteile können nur teilweise über das System und die genutzte Fremdschlüsselstruktur abgefangen werden und sitzen zum Teil in der Applikation.

2. Objektorientierte Datenbanken

Objektorientierte Datenbanken basieren darauf, dass die Datenhaltung zusammen mit ihren Funktionen in einem Objekt erfolgt. Das Objekt, in dem die Daten abgelegt sind, übernimmt dann intern die Datenverwaltung. Dazu gibt es zum Datenbankmodell passende Objektsprachen. Mit deren Hilfe oder über die Objektfunktionen können die Daten ausgelesen werden.

Die Objektsprachen orientierten sich an dem Musterbild der objektorientierten Programmierung und der jeweiligen Programmiersprache wie zum Beispiel Java oder C++.

Objektorientierte Datenbanken sind in der Praxis wenig verbreitet. Dadurch gestaltet sich ihre Implementierung kompliziert, denn es fehlen einige Schnittstellen und Zwischen-Layer, um eine ähnlich flexible Entwicklungsmöglichkeiten zu erreichen wie bei relationalen Datenbanken. Weiterhin kann die Komplexität eines Objektes so stark steigen, dass die Geschwindigkeit des Objektdatenmanagementsystems (ODMS) massiv sinkt. Mit der zunehmenden Verbreitung objektorientierter Programmiersprachen dürfte das Modell in Zukunft jedoch an Bedeutung gewinnen.

3. Dokumentenorientierte Datenbanken

Bei dem dokumentenorientierten Datenbankmodell werden die Daten in Dokumenten abgelegt. Ein Dokument steht in diesem Zusammenhang für einzelne, aber in sich unterschiedlich strukturierte Einheiten. Das können Dokumente im Standarddateiformat sein oder strukturierte Dateien mit einem festlegbaren Schema an Datenfeldern. Jedes dieser Dokumente besitzt einen eindeutigen Identifikator, mit dessen Hilfe das Dokument immer wiedergefunden werden kann. Die einzelnen Dokumente stehen nicht im Zusammenhang zueinander. Die Daten in einem Dokument werden in Form von Schlüssel-/Wertpaaren gesichert. Das heißt, das Dokument besteht aus einer Reihe mit Namen versehener Schlüsselfelder, denen jeweils ein bestimmter Wert zugeordnet ist.

Bei vielen dokumentenorientierten Datenbanken erfolgt die Abfrage mit einem nicht-relationalen Ansatz (NoSQL). Das heißt, es besteht keine SQL-ähnliche Syntax, um Beziehungen zwischen den Tabellen und Spalten beziehungsweise in diesem Fall Dokumenten abzufragen.

Image

Digitalisierung nimmt Fahrt auf

Behind The Scene Ausgabe 33
Topthemen:
Digitale Transformation im Agenturalltag
So funktioniert Cloud Hosting
Die Grenzen von OpenStack

Jetzt PDF kostenfrei downloaden

Bekannte Beispieltechnologien für Datenbanken

Relationale Datenbanken

  • Oracle
  • MySQL
  • MSSQL
  • Adabas DB/SAP DB
  • DB2

Objektorientierte Datenbanken

  • ObjectStore
  • O2
  • EntropyDB
  • db4o

Dokumentenorientierte Datenbanken

  • BaseX
  • CouchDB
  • MongoDB
  • RavenDB
  • Elasticsearch

So unterscheiden sich NoSQL und SQL von den Datenbankmodellen

Aus den bisherigen Ausführungen ist zu erkennen, dass die Begriffe „NoSQL“ und „SQL“ nicht auf einer Ebene mit den Datenbankmodellen stehen. Vielmehr stellen sie die Datenbanksprachen dar, in einer Art und Weise, wie Daten innerhalb dieser Modelle gespeichert und wieder abgefragt werden. Das funktioniert bei relationalen Datenbanken zum Beispiel mit SQL und bei dokumentenorientierten Datenbanken mit dem Sammelbegriff NoSQL. Es gibt also diverse Unterschiede, aber es ist nirgendwo festgelegt, welche Differenzierungen tatsächlich maßgebend sind. Darüber hinaus gibt es weitere Datenbankmodelle, die außerhalb dieser drei Elemente anzusiedeln sind: zum Beispiel grafenorientierte Datenbanken.

Die vier Unterschiede zwischen NoSQL und SQL

Im Wesentlichen gibt es vier Unterschiede zwischen NoSQL und SQL als Datenbanksprache und der Art und Weise, wie die Daten innerhalb des Datenbankmodells gespeichert werden:

  1. Tabellen gegenüber Sammlungen (Tables versus Collections)
  2. Unterschiedlicher Normalisierungsgrad bei den
    Datenbankinhalten
  3. Verschiedene Anforderungen an die Skalierung
  4. ACID versus BASE

ad 1) Tabellen gegenüber Sammlungen (Tables ­versus Collections)

SQL-basierte Datenbanken speichern Daten in Tabellenform. Die Tabellen werden dabei in Relation zueinander gesetzt. Das heißt, bereits ein Excel-Sheet stellt in Form und Aufbau eine Tabelle einer SQL-Datenbank dar.

Ein beliebtes Beispiel ist eine typische Adresskartei ­(Tabelle Adressen):

#schluessel#

NAME

Strasse

PLZ

Ort

1

Max ­Mustermann

Relationsgasse 5

12345

Daten­bergen

2

Maria ­Musterfrau

Objektstrasse 7

54321

Abfragehausen

Innerhalb des Datenbankmodells kann es weitere Tabellen geben, die auf die oben genannte Tabelle verweisen. Dazu wird der in der Tabelle „Adressen“ vorhandene #schluessel# verwendet und als Eintrag in weiteren Tabellen genutzt. So entsteht eine voneinander abhängige Datenstruktur, die in einer Tabellenform aufgebaut ist. Das heißt, eindeutige Schlüssel, Indexspalten zum schnelleren Auffinden von Werten in der Datenbank sowie Verknüpfungen zu anderen Datenbanktabellen (Relationen) sind obligatorisch.

NoSQL-basierte Datenbanksysteme speichern dagegen die Daten auf verschiedene Art und Weise, zum Beispiel indem die Datensätze als flexible Schlüssel-/Wertpaare aufgebaut sind. Diese Schlüssel-/Wertpaare sind nicht statisch festgelegt und befinden sich innerhalb eines „Dokuments“ als Datensatz.

{

NAME: „Max Mustermann“,

Strasse: „Relationsgasse 5“,

PLZ: „12345“,

Ort: „Datenbergen“

}

Ohne die eigentliche Datenbankstruktur zu ändern, könnte innerhalb dieses Datensatzes ein neues Schlüssel-/Wertpaar eingesetzt werden:

{

NAME: „Max Mustermann“,

Strasse: „Relationsgasse 5“,

PLZ: „12345“,

Ort: „Datenbergen“

Telefonnummer: „5552322“

}

ad 2) Unterschiedlicher Normalisierungsgrad bei den Datenbankinhalten

Wenn man die festgelegte Struktur der SQL-basierten Datenbank berücksichtigt und davon ausgeht, dass die dadurch implementierten Regeln strikt eingehalten werden (damit werden Fehler vermieden), ist ein hoher Normalisierungsgrad bei den Datenbankinhalten (Aufteilung in einzelne Werte) nötig, um dies ausreichend zu gewährleisten. Die Normalisierung macht das Datenmodell statischer und sorgt gleichzeitig dafür, dass das Aufspannen der modellierten Struktur über verschiedene Tabellen potenziell mehr Last und Logik im Datenbanksystem erzeugt. So ist die Datenablage in No-SQL-Datenbanken durch zusammenhangslose Datensammlungen wesentlich einfacher. Das Lesen und Schreiben auf ein Element passiert schneller. Dieser Vorgang wird deutlich, wenn Daten aus einem SQL-System gelesen werden sollen und parallel ein Schreibvorgang einzelne Tabellen „sperrt“, um die Transaktion mit allen ihren Abhängigkeiten abzuschließen. SQL wartet mit dem Lesen, bis der Schreibvorgang abgeschlossen wird. NoSQL liest das, was in diesem Moment an Daten vorhanden ist.

ad 3) Verschiedene Anforderungen an die Skalierung

Durch die Normalisierung und die Transaktionstreue ist die Skalierung eines SQL-basierten Systems in der Regel herausfordernder als bei NoSQL-basierten Systemen. Die Verteilung der Tabellen und Verknüpfungen auf unterschiedliche Systeme wird dadurch komplex, dass Transaktionen erst abgeschlossen werden müssen. Danach können sie auf andere Bereiche repliziert werden. Lesende Zugriffe müssen dabei nicht nur auf den Transaktionsabschluss warten, sondern auch auf die Replikation der Datensätze.

Die Skalierbarkeit von SQL-basierten Systemen erkauft man sich meist mit einer Hypothek auf die etwas länger dauernden Schreibvorgänge. NoSQL-Systeme erzeugen Kopien der Datensätze und verteilen diese über verschiedene Knoten. Sollte sich ein Datensatz ändern, werden die Sammlungen eine nach der anderen abgeändert. Gelesen werden kann immer. In diesem Fall kann es allerdings passieren, dass ein alter und noch nicht geänderter Datensatz gelesen wird, obwohl kurz vorher eine Änderung in das System eingespielt wurde.

ad 4) ACID versus BASE

SQL-basierte Datenbanken sind in allen ihren Strukturen und Transaktionen konsistent. Dadurch, dass die lesenden Abfragen auf die schreibenden Vorgänge warten, ist davon auszugehen, dass die Daten nachvollziehbar (bei jeder Abfrage des Systems) und gleich sind. NoSQL-basierte Systeme können, sollte noch eine Synchronisation stattfinden müssen, unterschiedliche Ergebnisse liefern. Ein gutes Beispiel dafür ist ein dreifacher Reload eines Twitter-Feeds im Webbrowser, der zwei unterschiedliche Ergebnisse liefern kann, je nachdem wo die Abfrage landet.

ACID

(SQL-basierte und relationale Datenbanken)

BASE
(viele NoSQL-basierte Datenbanken)

Atomic (Atomisch)

Alle Transaktionsvorgänge sind erfolgreich, oder es wird jeder Vorgang zurückgespielt.

Basic Availibility­ ­(Basisverfügbarkeit)

Die Datenbank scheint die meiste Zeit verfügbar zu sein.

Consistent (Konsistent)

Nach dem Transaktionsabschluss verfügt man über eine vernünftige strukturelle Datenbasis.

Soft-State (Weicher Zustand)

Während des Schreibvorgangs brauchen die Speicher weder konsistent zu sein noch müssen die verschiedenen Kopien die ganze Zeit kohärent zueinander sein.

Isolated (Isoliert)

Die Transaktionen blockieren sich nicht gegenseitig. Ein strittiger Datenzugriff wird durch die Datenbasis abgeschwächt, sodass die Transaktionen so erscheinen, als ob sie aufeinander folgen würden.

Eventual Consistency ­(Mögliche Konsistenz)

In den Speichern zeigt sich die Konsistenz erst zu einem späteren Zeitpunkt (zum Beispiel durch die langsame Lesezeit).

Durable (Beständig)

Die Ergebnisse im Rahmen einer Transaktion werden fortlaufend geliefert, sogar während der Ausfallzeiten.

Welche Datenbank ist nun die richtige?

Aus den bisherigen Betrachtungen lässt sich folgende wichtige Erkenntnis ableiten:

Der Einsatz von Datenbanksystemen in einem Unternehmen sollte nicht davon abhängen, ob dies „strategisch“ so vorgesehen ist, die Entwickler eine bestimmte Vorliebe haben oder das besagte Modell gerade gehypt wird.

Vielmehr sollte die Implementierungsform immer an den spezifischen Anwendungszweck angepasst werden. Dabei sind die Vor- und Nachteile zu beachten, die entstehen, wenn man die Acid-/Base-Situation genau beleuchtet und auf die jeweilige Datenstruktur und Anwendung projiziert. In vielen Projekten werden einige der genannten Systeme parallel zueinander betrieben. Damit wird das Ziel verfolgt, die Vorteile zu nutzen und die Nachteile auszublenden. Genau das ist die richtige Vorgehensweise. So würde ich ein System zur Nutzer-Authentifizierung und -verwaltung eher einem SQL-basierten System zuschreiben und eine Datensatzsammlung, bei der es unerheblich ist, ob sie um zehn Uhr oder zwei Sekunden später über die Applikation ausgeliefert wird, eher dem NoSQL-basierten System.

Was heißt das für Big Data?

Um diese Frage zu beantworten, lohnt es sich, eine weitere Frage zu stellen: Ist es sinnvoll, eine massive Anzahl einzelner Datensätze in eine SQL-Datenbank zu schreiben und jedes Mal auf den Abschluss der Transaktion zu warten? Die Antwort lautet: Nein. Nun wissen Sie, warum Big Data – eigentlich ein Begriff für massive Datenhaltung – häufig als Synonym für NoSQL-Datenbanken genutzt wird.

, ,


Weitere Artikel zum Thema lesen

Power Rack Colocation Hosting – Serverracks flexibel auf Zeit mieten

Biz & Trends, Hosting

Power Rack Colocation Hosting – Serverracks flexibel auf Zeit mieten

Wir bieten ein Mietmodell für Racks, das flexibel mit und ohne Management buchbar ist.

weiter lesen

Wandel durch Digitalisierung

Biz & Trends

Digitaler Wandel verändert Kundenverhalten und Branchen

Nur der Wandel hat Bestand, denn die digitale Transformation verändert Unternehmen, Kundenverhalten und damit ganze Branchen.

weiter lesen

Der Docmanager – Einblicke ins Intranet

Biz & Trends, Cloud, Hosting

Taskmanagement-System nach dem Kanban Prinzip

Das Kanban Prinzip bietet sich zur Umsetzung eines unternehmensweiten Taskmanagement-Systems an. Gerade in einem stetig wachsenden IT-Unternehmen steht man vor der steten Herausforderung, die von...

weiter lesen


Neueste Nachrichten von Adacor

DevOps in Unternehmen

Hosting

Wann DevOps für Unternehmen sinnvoll ist

Das Zusammenfinden der beiden Bereiche „Entwicklung und Betrieb“ ist vor der ersten Zeile Code obligatorisch, denn DevOps ist kein Framework, sondern eine Kultur.

weiter lesen

Der Schlüssel zum effektiven Domain Management

Domains

Domain Management: Verwalten Sie Ihre Domains (noch) selbst?

Die Anzahl der Domains nimmt verstärkt zu. Deren Management wird zunehmend zur Herausforderung. Wir bieten Ihnen den Schlüssel zum effektiven Domain Management.

weiter lesen

So funktioniert Cloud Hosting

Cloud

So funktioniert Cloud Hosting

Das Modell Cloud Hosting verspricht jederzeit skalierbare, virtualisierte Server, die immer die Leistung zur Verfügung stellen, die gerade benötigt wird.

weiter lesen

Diese Website verwendet Cookies. Mit der weiteren Nutzung der Website stimmen Sie unserer Datenschutzerklärung zu.
Für weitere Informationen klicken Sie bitte hier.