Datenbanktypen im Vergleich-Big-Data-Enzyklopädie

SQL vs. NoSQL: Wann lohnt sich welche Datenbank?

SQL vs. NoSQL – welche Datenbankstruktur ist in Zeiten von Big Data sinnvoll? Analysten, Ingenieuren und IT-Entscheider sind in der Regel mit relationalen Datenbankmanagementsystemen (RDBMS) und der strukturierten Abfragesprache (SQL) zur Interaktion mit diesen Systemen vertraut. Diese sind nach wie vor breiter Standard. Doch die Vielfalt und Tiefe der Datenbanksysteme kann heute überwältigend sein, sodass es zusätzlicher Alternativen bedarf. Darüber hinaus haben die steigenden Mengen an unstrukturierten Daten, die Verfügbarkeit von Speicher- und Verarbeitungsleistung und die sich entwickelnden analytischen Anforderungen das Interesse an grundlegend anderen Technologien geweckt.

Diese beliebten Alternativen zu traditionellen RDBMS sind unter dem Namen NoSQL bekannt und bieten sich für eine Vielzahl von modernen Anwendungsfällen an.

Um fundierte Entscheidungen zu treffen, lohnt es sich für Anwender die Unterschiede zwischen SQL, NoSQL und den einzelnen Datenbankmanagementsystemen (DBMS) und -sprachen zu kennen – und in welchen Situationen sie die Technologien am besten einsetzen.

Was sind die Unterschiede zwischen SQL und NoSQL?

SQL (Structured Query Language) ist eine Programmiersprache, mit der sich relationale Datenbanken abfragen lassen. Relationale Datenbanken modellieren Daten als Datensätze in Zeilen und Tabellen mit logischen Verknüpfungen zwischen ihnen. NoSQL (not only SQL) stellen dagegen eine Ansammlung an alternativen Datenbankmanagementsystemen (DBMS) dar. Diese sind nicht relational und verwenden in der Regel kein SQL.

Es gibt fünf große Unterschiede zwischen SQL und NoSQL:

Sprache Skalierbarkeit Struktur Eigenschaften Unterstützung und Communities

1. Sprache

SQL gibt es schon seit über 40 Jahren und ist daher vielen bekannt, gut dokumentiert und weit verbreitet. Sicher und vielseitig, eignet es sich besonders gut für komplexe Abfragen. Allerdings schränkt SQL den Benutzer auf die Arbeit innerhalb eines vordefinierten Tabellenschemas ein. Deshalb ist es aufwendiger, die Daten zu organisieren und zu verstehen, bevor sie sich verwenden lassen.

Die dynamischen Schemata von NoSQL-Datenbanken ermöglichen im Vergleich dazu die Darstellung alternativer Strukturen. Diese liegen oft nebeneinander, was eine größere Flexibilität fördert und den Planungsaufwand verringert. Größere Freiheiten liegen ebenfalls beim Hinzufügen neuer Attribute oder Felder vor. Auch die Verwendung einer unterschiedlichen Syntax in verschiedenen Datenbanken ist möglich. Den NoSQL-Sprachen fehlt jedoch die Standardschnittstelle, die SQL bietet, sodass komplexere Abfragen schwierig auszuführen sein können.

Obwohl es viele Dialekte von SQL gibt, haben alle eine gemeinsame Syntax und eine fast identische Grammatik. Wer eine Sprache bei der Abfrage von relationalen Datenbanken beherrscht, kennt ebenfalls die meisten anderen. Unter den NoSQL-Sprachen gibt es wenig Konsistenz, da es sich um eine Reihe unterschiedlicher, nicht miteinander verbundener Technologien handelt. Viele NoSQL-Datenbanken nutzen eine eigene Sprache für die Datenverarbeitung, die durch bestimmte Strukturen und Fähigkeiten eingeschränkt ist.

2. Skalierbarkeit

Die meisten SQL-Datenbanken lassen sich vertikal skalieren, indem die Rechenleistung der vorhandenen Hardware erhöht wird. NoSQL-Datenbanken verwenden eine Master-Slave-Architektur, die besser horizontal skaliert, mit zusätzlichen Servern oder Netzwerkknoten. Dies sind die Grundlagen, jedoch gibt es folgende Ausnahmen zu beachten:

SQL-Datenbanken lassen sich ebenfalls horizontal skalieren. Allerdings wird die Sharding- oder Partitionierungslogik, also die Aufteilung einer Datenbank auf mehrere Server, oft nicht gut unterstützt.

NoSQL-Technologien sind vielfältig. Während viele auf die Master-Slave-Architektur setzen, gibt es auch Optionen für die vertikale Skalierung.

Einsparungen, die sich durch effizientere Datenstrukturen erzielen lassen, können die Unterschiede in der Skalierbarkeit überwiegen. Am wichtigsten ist es, den Anwendungsfall genau zu verstehen und entsprechend zu planen.

3. Struktur

SQL-Datenbankschemata stellen immer relationale, tabellarische Daten dar, mit Regeln für Konsistenz und Integrität. Sie enthalten Tabellen mit Spalten (Attributen) und Zeilen (Datensätzen). Die Einträge haben eingeschränkte logische Beziehungen.

NoSQL-Datenbanken müssen sich nicht an dieses Format halten, sondern passen im Allgemeinen in eine von vier Kategorien:

Spaltenorientierte Datenbanken setzen zeilenorientierte RDBMS um. Sie ermöglichen eine effiziente Speicherung von hochdimensionalen Daten und einzelnen Datensätzen mit unterschiedlichen Attributen.

setzen zeilenorientierte RDBMS um. Sie ermöglichen eine effiziente Speicherung von hochdimensionalen Daten und einzelnen Datensätzen mit unterschiedlichen Attributen. Schlüssel-Werte-Datenbanken sind Wörterbücher, die auf verschiedene Objekte mit einem jeweils eindeutigen Schlüssel zugreifen.

sind Wörterbücher, die auf verschiedene Objekte mit einem jeweils eindeutigen Schlüssel zugreifen. Dokumentenspeicher enthalten halbstrukturierte Daten: Objekte, die alle ihre eigenen relevanten Informationen enthalten und sich voneinander völlig unterscheiden können.

enthalten halbstrukturierte Daten: Objekte, die alle ihre eigenen relevanten Informationen enthalten und sich voneinander völlig unterscheiden können. Graphdatenbanken fügen Dokumenten direkte Verknüpfungen zwischen Objekten hinzu und ermöglichen so ein schnelles Durchsuchen von stark verbundenen Datensätzen.

4. Eigenschaften

SQL und NoSQL sind unterschiedlichen Regeln unterworfen, um Transaktionen abzuwickeln. RDBMSs müssen vier Merkmale, die so genannten „ACID“-Eigenschaften, aufweisen:

Atomarität (Atomicity): Alle Transaktionen müssen vollständig gelingen oder fehlschlagen. Sie können nicht unvollständig sein, auch nicht im Falle eines Systemausfalls.

Alle Transaktionen müssen vollständig gelingen oder fehlschlagen. Sie können nicht unvollständig sein, auch nicht im Falle eines Systemausfalls. Konsistenz (Consistency): Die Datenbank befolgt bei jedem Schritt unveränderliche Größen: Regeln, die validieren und Verfälschungen verhindern.

Die Datenbank befolgt bei jedem Schritt unveränderliche Größen: Regeln, die validieren und Verfälschungen verhindern. Isolation: Sie verhindert, dass sich konkurrierende Transaktionen gegenseitig beeinflussen. Selbst parallel ausgeführte Transaktionen müssen zu demselben Ergebnis führen, als ob sie nacheinander ausgeführt würden.

Sie verhindert, dass sich konkurrierende Transaktionen gegenseitig beeinflussen. Selbst parallel ausgeführte Transaktionen müssen zu demselben Ergebnis führen, als ob sie nacheinander ausgeführt würden. Dauerhaftigkeit (Durability): Selbst ein Systemausfall kann die Auswirkungen einer erfolgreichen Transaktion nicht rückgängig machen.

NoSQL-Technologien halten sich an das „CAP“-Prinzip. Dieses besagt, dass in jeder Datenbank nur zwei der folgenden Eigenschaften gleichzeitig garantiert werden können:

Konsistenz (Consistency): Jede Anfrage erhält das aktuelle Ergebnis oder einen Fehler.

Jede Anfrage erhält das aktuelle Ergebnis oder einen Fehler. Verfügbarkeit (Availability): Jede Anfrage erhält ein fehlerfreies Ergebnis, unabhängig davon, wie aktuell dieses Ergebnis ist.

Jede Anfrage erhält ein fehlerfreies Ergebnis, unabhängig davon, wie aktuell dieses Ergebnis ist. Teilungstoleranz (Partition Tolerance): Verzögerungen oder Verluste zwischen Netzwerkknoten unterbrechen den Betrieb des Systems nicht.

5. Unterstützung und Communities

SQL-Datenbanken verfügen über große Communities, stabile Codebases und bewährte Standards. Es gibt eine Vielzahl von Anwendungsbeispielen im Internet und Experten, die diejenigen unterstützen, die neu in der Programmierung relationaler Daten sind.

NoSQL-Technologien finden schnell Zuspruch, jedoch bleiben die Communities kleiner und sind stärker zersplittert. Viele SQL-Sprachen sind proprietär oder mit großen Einzelanbietern assoziiert. Währenddessen profitieren die NoSQL-Communities von offenen Systemen und einem konzertierten Engagement für die Einbindung von Benutzern.

SQL ist für die meisten wichtigen Plattformen verfügbar, von Betriebssystemen über Architekturen bis hin zu Programmiersprachen. Bei NoSQL variiert die Kompatibilität stärker und es gilt, Abhängigkeiten sorgfältiger zu untersuchen.

Erfahren Sie, wie Talend verlässliche Daten für seine Geschäftsprozesse nutzt E-Book herunterladen

SQL- vs. NoSQL-Datenbanken: MySQL, MongoDB und mehr

SQL-Dialekte haben viele Eigenschaften gemeinsam, obwohl sie mit unterschiedlichen Datenbanken arbeiten. Der vielleicht bekannteste SQL-Dialekt ist MySQL, ein quelloffenes und kostenloses RDBM, das allerdings auch in proprietären Lizenzen erhältlich ist. Nutzer setzen es vermehrt für Webanwendungen ein. Es ist bekannt für Kompatibilität, Support und gute Leistung. MySQL hat mit Funktionen wie einem JSON-Datentyp, dem „Document Store“und der Unterstützung für Sharding (horizontale Skalierung) auch Zugeständnisse an NoSQL-Anwender gemacht.

Die nicht-relationale NoSQL-Seite nutzt vermehrt MongoDB. Hierbei handelt es sich in erster Linie um einen Dokumentenspeicher mit JSON-ähnlichen Strukturen und einer JavaScript-Schnittstelle. MongoDB ist dafür bekannt, dass es durch weniger Administrationsaufwand besonders benutzerfreundlich ist. Weiterhin performt es gut bei einfachen Abfragen und ist dank seiner NoSQL-Grundlage sehr flexibel. Es eignet sich hervorragend für die hierarchische Datenspeicherung und unterstützt vertraute relationale Konzepte von der Indizierung über die Aggregation bis hin zu einem gewissen Maß an ACID-Konformität. Wie MySQL ist es mit vielen Plattformen und Programmierumgebungen kompatibel, obwohl es relativ neu ist.

Andere SQL-Datenbanken

MS-SQL ist Microsofts relationales Datenbankprodukt, das in einem Dutzend Editionen verfügbar ist, die sich an unterschiedliche Endanwender richten. Der Zugriff erfolgt über das proprietäre Transact-SQL (T-SQL). Microsoft Azure enthält eine eigene Komponente zur Skalierung von MS-SQL-Datenbanken in der Cloud.

Oracle Database gehört zu den ältesten und am meisten etablierten RDBMS. Ihr relationaler Speicher lässt sich über PL/SQL verbinden, obwohl sie sich in ein Multi-Modell-System verwandelt.

Andere wichtige RDBMS sind Access, Ingres, PostgreSQL, Sybase und SQLite.

Andere NoSQL-Datenbanken

Apache CouchDB ist, wie MongoDB, eine dokumentenorientierte Datenbank mit JSON-Schemata und Abfragen über JavaScript. CouchDB zeichnet sich durch seine Skalierungsfähigkeiten aus, da es eine Multi-Master-Architektur anstelle des typischen verteilten Single-Master-Designs verwendet.

Redis (Remote Dictionary Server) ist die beliebteste Schlüssel-Werte-Datenbank. Sie ist offen zugänglich, hat eine schnelle und verteilte In-Memory-Implementierung und unterstützt viele abstrakte Datenstrukturen, von denen einige in anderen NoSQL selten zu finden sind.

Mit InfinityDB und Amazons DynamoDB sind zwei weitere Schlüssel-Werte-Datenbanken verfügbar. Spaltenbasierte Speicher wie Cassandra, MariaDB und Scylla lassen sich gut horizontal skalieren. Beliebte Graphdatenbanken sind ArangoDB, InfiniteGraph und Neo4j.

Die Cloud und die Zukunft von SQL und NoSQL

Moderne Marken haben gleich mehrere Schwerpunkte: Sie legen Wert auf die Interaktivität zwischen Endbenutzern, die Rechtfertigung dezentraler, cloudbasierter Architekturen und die Darstellung vielfältiger, neuer Daten. Hier kommt NoSQL ins Spiel, der Experte für umfangreiche, verteilte und sich wandelnde Daten.

Das nicht-relationale Interesse stellte die traditionellen RDBMS eine Zeit lang in den Schatten. Doch nun bekommen sie wieder neuen Aufwind. Denn SQL, als eine Art Verkehrssprache für Daten, bleibt immer noch zugänglicher und verständlicher.

NoSQL stellt zunehmend eine Reihe von Technologien mit allgemeiner Anwendbarkeit dar. Aufgrund der Unterstützung von SQL-ähnlicher Programmierung und der Koexistenz mit RDBMS wird sie oft als „Nicht nur SQL“ bezeichnet. Wie bereits oben beschrieben, lassen sich auch traditionelle RDBMS zu generalisierten Datenbanken umfunktionieren und mit NoSQL verbinden. Es ist klar, dass beide Paradigmen beim modernen Übergang zur Cloud gleichermaßen gültig bleiben.

Wann Sie NoSQL vs. relationale Datenbanken für Ihr Unternehmen nutzen

Im Allgemeinen empfiehlt sich die Nutzung von NoSQL für:

grafische oder hierarchische Daten

sowohl große als auch sich stark verändernde Datensätze

Unternehmen, die extrem schnell wachsen, aber keine Datenschemata haben

Anwendungsfälle können u. a. soziale Netzwerke, Online-Content-Management, Streaming-Analytics oder mobile Anwendungen sein.

SQL ist dahingegen besser geeignet, für:

kleine Daten

tabellarisch modellierte Daten

Systeme, bei denen Konsistenz entscheidend ist

Hierzu gehören z. B. Buchhaltungssysteme kleiner Unternehmen, Verkaufsdatenbanken oder Transaktionssysteme wie die Zahlungsabwicklung im E-Commerce. Im Zweifelsfall ist SQL besser geeignet, da RDBMS besser unterstützt und fehlertolerant sind.

SQL vs. NoSQL: Die beste Lösung für Ihr Geschäft

SQL wirkt etwas veraltet und manchmal einschränkend, ist aber gleichzeitig altbewährt und gilt zunehmend als universelle Schnittstelle für die Datenanalyse. NoSQL-Datenbanken sind neu und flexibel, jedoch noch nicht ausgereift und erfordern eine Spezialisierung der Benutzer. Pragmatisch betrachtet sind beide Modelle durchaus nützlich und wachsen sogar zusammen. Letztlich ist eine Technologie nur dann wertvoll, wenn sie Ihrem Geschäft dient, in der Regel mit einem gesteigerten ROI. Selbst Unternehmen wie Google, die über Ressourcen verfügen, um NoSQL-Systeme von Grund auf neu zu entwickeln, haben festgestellt, dass SQL einen Mehrwert bietet. Daher setzen sie es in kritischen Systemen wieder ein.

Von der Migration von handkodiertem SQL in konforme und regelbare ETL-Tools, über die Verwaltung schwieriger unstrukturierter Daten bis hin zur Integration relationaler und nicht-relationaler Systeme unter einem praktischen Dach – Talend bietet Lösungen für alle Datenspeicherparadigmen.

Unsere zentralisierte und automatisierte Datenintegrationssoftware erleichtert die Verwaltung sowohl relationaler als auch anderer Quellsysteme. Die Produkte von Talend enthalten Werkzeuge, mit denen selbst Anwender mit wenig ETL-Erfahrung ihre Prozesse optimieren können. Konnektoren sind für alle wichtigen RDBMS sowie führende NoSQL-Datenbanken verfügbar.

Probieren Sie Talend Data Fabric jetzt aus und beginnen Sie Ihre Daten und Datenprozesse zu verbinden und zu beschleunigen.

Datenbanken - Informationstechnologie

Allgemeines

Man unterscheidet im wesentlichen vier unterschiedliche Datenbanktypen:

Relationalte Datenbanken objektorientierte Datenbanken hierarchischen Datenbanken netzwerkartige Datenbanken

Diese Modelle unterscheiden sich im logischen Aufbau der Datenstruktur.

Relationale Datenbanken

Die Relationalen Datenbanken bilden die Grundlage dieses Kurses. Am Beispiel von MySQL wird der Umgang mit der Datenbankart erläutert.

Objektorientierte Datenbank

Das objektorientiertes Datenbankmodell folgt dem Ansatz der objektorientierten Programmierung. Dabei werden Daten und Funktionen als Einheit betrachtet. Die Datenbankzugriffe erfolgen anhand etablierter Sprachmodelle z.b. SQL. Dieses Datenbankparadigma ist die logische Konsequenz objektorientierter Projekte moderner Programmiersprachen. Das objektorientiertes Datenbankmodell wird häufig in c, c++ oder java programmiert.

Hierarchische Datenbanken

Diese hierarchisch in Baumstruktur angelegten Datenstrukturen sind die ältesten der Datenbakmodelle. Die Baumstruktur ermöglich sehr schnelle Zugriffe.

Netzwerkartige Datenbanken

Die Einträge in netzwerkartigen Datenbanken bestehen aus records. Records sind in sich schlüssige Datensätze die wiederum in Feldern (Data items) strukturiert sind. Die Datensätze beschreiben Personen, Objekte oder events. Die Beziehungen ergeben sich aus den Datensätzen.

Datenbanktypen im Vergleich

Früher waren relationale Datenbanken das Maß der Dinge, doch in den vergangenen 15 Jahren haben sich zahlreiche andere Datenbanktypen etabliert. Wie unterscheiden sie sich, und spielen relationale Datenbanken heutzutage überhaupt noch eine Rolle?

Der mit Abstand einfachste Datenbanktyp ist die Key-Value-Datenbank. Solche Datenbanken funktionieren quasi wie ein Dictionary, indem sie zu einem gegebenen Schlüssel einen passenden Wert speichern. Diese Werte können durchaus unterschiedliche Datentypen haben, allen gemein ist aber, dass die Indexierung nur über den Schlüssel und nicht über den Wert erfolgt.

Key-Value-Datenbanken eignen sich daher zum Verwalten von Daten, die einer ID zugeordnet werden und auf die auch ausschließlich anhand der ID zugegriffen wird. Dazu zählen beispielsweise das Caching von Daten und das Ablegen von Sessions für eine Webanwendung.

Ein typisches Produkt dieser Art ist Redis, was als Akronym für "Remote Dictionary Server" steht. Redis verwaltet Key-Value-Paare primär in Listen, kennt aber auch andere Strukturen, unter anderem Mengen und sortierte Mengen. Seit Version 5 werden auch Streams, ähnlich zu Kafka, unterstützt. Aufgrund dieser verschiedenen Datenstrukturen eignet sich Redis auch hervorragend für andere Anwendungsfälle wie Pub/Sub und Queues.

Generell können Key-Value-Datenbankeneinfach horizontal skaliert werden, da nur die ID als Diskriminator dient und die Daten auf dem Weg einfach geshardet werden können. Der größte Haken ist die fehlende Standardisierung, die sich aufgrund der Einfachheit aber problemlos in der Anwendung nachbilden lässt.

Empfohlener redaktioneller Inhalt Mit Ihrer Zustimmmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen. YouTube-Video immer laden YouTube-Video jetzt laden Key-Value-Datenbanken

Column- und Wide-Column-Datenbanken

Geringfügig komplexer sind die Wide-Column-Datenbanken, die ebenfalls zu einem Schlüssel passende Daten speichern, allerdings handelt es sich bei diesen Daten um komplexere Werte, die aus mehreren Feldern beziehungsweise Spalten bestehen. Im Prinzip ist eine Wide-Column-Datenbank, wenn man so will, nichts anderes als eine zweidimensionale Key-Value-Datenbank.

Ganz deutlich unterscheiden muss man davon die Column-Datenbanken, die eher den klassischen relationalen Datenbanken entsprechen, im Gegensatz zu diesen aber spalten- und nicht zeilenorientiert arbeiten. Das ist besonders dann praktisch, wenn primär einzelne Spalten über eine große Anzahl von Datensätzen verarbeitet werden.

Häufig trifft man spaltenorientierte Datenbanken daher im OLAP-Bereich an, zeilenorientierte eher im OLTP-Bereich, wobei die Grenzen hier fließend sind. Column-Datenbanken sind daher ein relativ ausgefallener Spezialfall, für den es zwar Anwendungsgebiete gibt, die überwiegende Mehrheit der Datenbanken arbeitet aber zeilenorientiert.

Dokumentenorientierte Datenbanken

Key-Value- und Wide-Column-Datenbanken ist gemein, dass lediglich der Schlüssel zum Indexieren genutzt wird. Die Werte, unabhängig ob einfach oder zusammengesetzt, sind auf dem Weg daher nicht beziehungsweise nicht effizient durchsuchbar. Was aber, wenn man das braucht, um beispielsweise komplexere Abfragen ausführen zu können?

In diesem Fall kann man auf sogenannte dokumentenorientierte Datenbanken zurückgreifen. Unter einem Dokument versteht man hier in der Regel ein JSON-Objekt, theoretisch kann es sich aber auch um andere Datenformate handeln. Die Objekte werden dabei ohne Beziehungen zueinander gespeichert, sondern werden als in sich geschlossene Einheiten betrachtet. Relationen lassen sich theoretisch über IDs abbilden, haben für die Datenbank aber keine Relevanz, sondern müssen in der Regel auf Anwendungsebene aufgelöst werden.

Einer der bekanntesten Vertreter dieser Art von Datenbanken ist MongoDB, was sich ebenfalls wieder gut horizontal skalieren lässt, wobei auch hier Sharding wieder eine große Rolle spielt. Da die Dokumente in sich geschlossene Einheiten sind, werden die ACID-Kriterien häufig nicht unterstützt, wobei es Ausnahmen gibt. So unterstützt auch MongoDB seit der Version 4.0 ACID-konforme Transaktionen, die mehrere Dokumente umfassen.

Wenn Relationen eine große Rolle spielen, kann es hilfreich sein, eine Graph-Datenbank einzusetzen. In einer solchen Datenbank werden nicht nur die Entitäten, sondern auch die Relationen explizit modelliert, wodurch als Datenmodell ein Graph entsteht. Das bedeutet, dass sich unterschiedliche Arten von Beziehungen abbilden und vor allem auch abfragen lassen.

Ein typischer Anwendungsfall für Graphdatenbanken ist das Abbilden menschlicher Beziehungen beziehungsweise Interaktionen, wo sich anschließend über den Graph ermitteln lässt, wer wen über wen kennt oder wer mit wem Kontakt haben könnte. Prinzipiell sind aber auch andere Abfragen denkbar, wobei hier vor allem Themen aus der Graphtheorie relevant sind, beispielsweise das Ermitteln von kürzesten Wegen, Cliquen oder Hotspots.

Ein bekannter Vertreter dieser Art von Datenbanken ist ArangoDB, das als 3-in-1-System fungiert. ArangoDB lässt sich nämlich als Key-Value-, als dokumentenorientierte und auch als Graph-Datenbank einsetzen. Dabei ist die Datenbanken in weiten Teilen sogar kompatibel zu MongoDB, weshalb sich ArangoDB ein bisschen anfühlt wie eine um Graph-Fähigkeiten erweiterte MongoDB.

Empfohlener redaktioneller Inhalt Mit Ihrer Zustimmmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen. YouTube-Video immer laden YouTube-Video jetzt laden Graph-Datenbanken

Relationale Datenbanken

Alle genannten Datenbanktypen, von der Key-Value- bis hin zur Graphdatenbank, haben ihre Berechtigung und adressieren jeweils unterschiedliche Anwendungsfälle. Was sie aber alle gemeinsam haben, ist, dass sie in der Regel schemalos arbeiten und daher für unstrukturierte Daten geeignet sind. Das ist in vielen Fällen ein Vorteil, trotzdem bietet sich gelegentlich auch der Einsatz eines festen Schemas an.

Dann sind häufig klassische relationale und SQL-basierte Datenbanken das Mittel der Wahl. Die Trennlinie verläuft dabei übrigens gar nicht so scharf, wie man das zunächst annehmen könnte, denn gerade die relationalen Datenbanken haben in den vergangenen Jahren aufgeholt beziehungsweise sind um Funktionen für das Verwalten unstrukturierter Daten erweitert worden. So kennen beispielsweise PostgreSQL und MySQL spezielle Datentypen für JSON.

Doch auch in anderer Hinsicht sind relationale Datenbanken häufig weitaus flexibler, als man das zunächst annehmen könnte. Der Microsoft SQL Server kennt zum Beispiel den Index-Typ "Columnstore", mit dem sich eine Tabelle nicht zeilen-, sondern spaltenorientiert verwalten lässt, ähnlich einer Column-Datenbank.

Fazit

Insgesamt sind relationale Datenbanken also nicht per se besser oder schlechter als NoSQL-Datenbanken, sondern es gilt, wie so oft, dass man das richtige Werkzeug für den passenden Anwendungsfall auswählen sollte. Wenn das im konkreten Fall eine NoSQL-Datenbank ist, ist das in Ordnung. Es ist aber ebenfalls in Ordnung, wenn es eine relationale Datenbank ist.

Beide Welten zu kennen ist aber so oder so hilfreich, denn ein Blick über den Tellerrand erweitert den Horizont und befähigt Entwicklerinnen und Entwickler, bessere und vor allem fundiertere Entscheidungen zu treffen. ()

Datenbanktypen im Vergleich

SQL vs. NoSQL: Wann lohnt sich welche Datenbank?

Datenbanken - Informationstechnologie

Datenbanktypen im Vergleich

Leave a Reply Cancel reply