SQL vs. NoSQL - Was sollten Sie für Ihr nächstes Projekt verwenden?

Eine der am häufigsten gestellten Fragen - welche Datenbank soll ich verwenden...

SQL steht für Structured Query Language (strukturierte Abfragesprache). Sie wurde erstmals in den 1970er Jahren von einem Team von IBM-Forschern entwickelt. NoSQL-Datenbanken hingegen wurden erstmals 1998 von Carlo Strozzi verwendet.

Der häufigste Unterschied zwischen diesen beiden Datenbanksystemen (DB) besteht darin, dass SQL relational ist und NoSQL nicht-relational ist.

Lassen Sie uns diese beiden Datenbanken genauer unter die Lupe nehmen, damit Sie Ihre Entscheidung besser treffen können, wenn Sie das nächste Mal über eine Datenbank für Ihr Projekt.

Struktur der Datenbank

Lassen Sie uns über die Strukturierung sprechen.

SQL

SQL Datenbank eine eindeutige Schemastruktur haben.

Ein Schema enthält Tabellen, und jede Tabelle enthält eine bestimmte Anzahl von Spalten. Das bedeutet, dass ein Benutzer die Tabelle nicht über die in der Tabelle angegebene Anzahl von Spalten hinaus aktualisieren kann. Dies ist besonders nützlich, wenn Sie die Datenintegrität wahren und sicherstellen müssen, welche Art von Daten in Ihrer Datenbank gespeichert wird.

Jede Tabelle in einer SQL-Datenbank kann in Beziehung zueinander stehen, d.h. Sie können Beziehungen zwischen Tabellen haben. Diese Beziehungen können Eins zu Viele, Viele zu Viele oder Eins zu Eins sein. Welche Art von Beziehung Sie implementieren, hängt davon ab, was Sie benötigen.

Betrachten wir zum Beispiel die hypothetische Situation, dass wir ein Unternehmen mit Benutzern haben, die Bestellungen für Produkte aufgeben können. Dann könnten wir beschließen, dass Benutzer mehrere Bestellungen erstellen können, aber jede Bestellung kann nur von einem Benutzer erstellt werden. Dies wäre eine eins zu viele Beziehung, d. h. ein Benutzer zu vielen Bestellungen. Die Tabellenstruktur für beide Tabellen wird also ähnlich aussehen wie unten.

In unserer DB könnten wir eine Benutzertabelle haben, die wie folgt strukturiert ist,

users_table
----------------------------------------------------
id          |          name       |           email
-----------------------------------------------------
1                    Idris              idris@idrislawal.com

Wir könnten auch eine Auftragstabelle haben

orders_table
---------------------------------------------------------------------------------
id                   |             user_id             |             order_number
---------------------------------------------------------------------------------
1                                      1                               20000001

Die user_id in der Tabelle "Bestellungen" macht es einfach, jede Bestellung in der Tabelle "Bestellungen" dem Benutzer zuzuordnen, zu dem sie gehört. Im Falle einer Eins-zu-Eins-Beziehung könnten wir die order_id auch auf der users_table wenn wir beschließen, den Benutzer anhand der zugehörigen Bestellnummer zu ermitteln.

Für Many-to-Many-Situationen ist in der Regel eine zusätzliche Tabelle, eine so genannte Pivot-Tabelle, erforderlich. Diese ermöglicht es, mehrere Datensätze einander zuzuordnen. Nehmen wir das obige Beispiel. Wir hätten dann,

users_table
-------------------------------------------------------------------------------------
id               |                    name                   |                  email
-------------------------------------------------------------------------------------
1                               Idris                             idris@idrislawal.com

und die Auftragstabelle wird

orders_table
---------------------------------------------------------
id                      |                    order_number
---------------------------------------------------------
1                                             2000001

und dann enthält die Pivot-Tabelle beide IDs als Fremdschlüssel.

users_orders_table
------------------------------------------------------------------------------
id               |                  order_id              |           user_id
------------------------------------------------------------------------------
1                                     1                                 1

Auf der Grundlage dieser von SQL bereitgestellten Struktur können Sie bequem Joins zwischen Tabellen schreiben, die Daten aus verschiedenen Tabellen in einer Abfrage zusammenführen.

NoSQL

NoSQL Datenbanken wurden entwickelt, um flexibler zu sein als SQL-DBs und auch um größere Datenmengen zu speichern.

In NoSQL-DBs gibt es keine vordefinierten Schemata oder Tabellen. Es gibt Sammlungen, und in jeder Sammlung gibt es Dokumente. Auf diese Weise können Sie Daten in verschiedenen Formen speichern, wenn sie anfallen. Sie können mehrere unterschiedliche Dokumente mit unterschiedlichen Feldern in einer Collection haben. Es ist auch möglich, manuell Beziehungen zwischen Collections herzustellen. Sie sind jedoch für diesen Zweck nicht geeignet. Stattdessen können Sie alles, was für eine einzige Abfrage benötigt wird, in ein und derselben Sammlung speichern.

Wenn Sie ein SQL-Kenner sind, denken Sie vielleicht an Sammlungen als Tabellen und an Dokumente als Zeilen in den Tabellen. Es gibt jedoch keine Einschränkungen hinsichtlich der Datenspalten, die Sie der Tabelle hinzufügen können.

Wir kehren zu unserem zuvor definierten hypothetischen Beispiel eines Unternehmens mit Benutzern und Aufträgen zurück.

Eine Benutzersammlung könnte definiert werden als,

{id: 1, name: 'idris', email: 'idris@idrislawal.com'}

Und die Auftragssammlung könnte wie folgt definiert werden,

{id: 1, order_number: 2000001, user_id:1}

In diesem Fall wollen wir jedoch vermeiden, dass wir beide Sammlungen manuell zusammenführen müssen (was wir in diesem Fall nicht tun sollten). Wir können die Einträge in der Sammlung speichern, die am häufigsten gelesen wird. Ich habe mich (für dieses Beispiel) für die Sammlung "Orders" entschieden.

{id:1, order_number:200001, user{id:1, name: 'idris', email:'idris@idrislawal.com'}}

In diesem Fall müssen wir nicht mehr aus der Users Collection lesen, sondern nur noch aus der Orders Collection, die nun alle benötigten Daten enthält.

Ein wichtiger Punkt ist hier zu beachten: Wenn Sie eine Anwendung entwickeln, bei der mehr gelesen als geschrieben wird, ist eine NoSQL-Option wahrscheinlich besser für Sie geeignet. Denn Sie können Ihre Daten alle in derselben Sammlung speichern und bequem aus dieser Quelle lesen, um alle erforderlichen Daten zu erhalten.

Für eine Anwendung, die viele Schreibvorgänge erfordert (ca. 10.000 Schreibvorgänge pro Sekunde), ist es jedoch keine gute Idee, eine NoSQL-Option zu verwenden, bei der dieselben Daten an mehrere Stellen geschrieben werden müssen. In dieser Situation ist eine SQL-Option wahrscheinlich besser geeignet, bei der Beziehungen zu allen Tabellen bestehen und dieselben Daten nicht wiederholt in mehrere Speicherorte geschrieben werden müssen, wobei die Aktualisierung von Daten an einem Speicherort über die bestehende Beziehung für andere Tabellen verfügbar sein kann. Das bedeutet natürlich nicht, dass jede dieser Datenbanken nicht skalierbar ist.

Skalierung

Sehen wir uns an, wie die Skalierung funktioniert.

SQL

SQL-DBs können nicht horizontal, sondern nur vertikal skaliert werden. Was bedeutet das überhaupt?

Horizontale Skalierung bedeutet, dass Daten von einer DB auf mehrere Datenbanken aufgeteilt werden, um die Last zu verringern. SQL-Daten können jedoch aufgrund ihrer strengen Natur nicht auf separate DBs aufgeteilt werden. Die eigentliche Skalierung einer SQL-DB besteht in der Erhöhung der CPU, des Arbeitsspeichers und des Festplattenspeichers des vorhandenen DB-Servers, und genau das bedeutet vertikale Skalierung.

NoSQL

NoSQL-DBs können sowohl horizontal als auch vertikal skaliert werden. Dies ist auf die Flexibilität bei der Datenspeicherung zurückzuführen. So können die Daten auf mehrere Datenbanken aufgeteilt werden, wie es bei der horizontalen Skalierung der Fall ist. Bei Bedarf kann sie auch vertikal skaliert werden.

Ein wichtiger Punkt ist hier zu beachten: Wenn es um Skalierung geht, können sowohl SQL- als auch NoSQL-Datenbanken effektiv skaliert werden. Bei SQL-DBs kann die vertikale Skalierung jedoch eine Einschränkung darstellen; ein einzelner DB-Server kann nur eine bestimmte Menge an Rechenleistung übertragen.

An dieser Stelle sei auch darauf hingewiesen, dass Sie bei den meisten Anwendungen, die Sie erstellen werden, nicht die maximale Rechenleistung Ihres Servers ausschöpfen werden, aber es ist hilfreich, dies im Hinterkopf zu behalten. Für große Geschäftsanwendungen, die SQL implementieren, ist jedoch eine beliebte Option, diese Beschränkung zu umgehen, indem man Sharding.

Was ist Sharding?

Unter Sharding versteht man das Aufteilen großer Tabellen in kleine Teile, die als Shards bezeichnet werden. Sharding kann durch horizontale Partitionierung einer Datenbank erfolgen. Dies ist nicht zu verwechseln mit der horizontalen und vertikalen Skalierung. Die horizontale Partitionierung bezieht sich auf die Speicherung von Tabellenzeilen in mehreren Datenbankknoten. Bei der vertikalen Partitionierung hingegen werden Spalten einer Tabelle auf verschiedenen Knoten gespeichert. Dadurch kann die Datenbank effektiv skaliert und die Leistung gesteigert werden.

Datenbank-Beispiele

SQL

MySQL - Eine sehr beliebte Open-Source-Datenbank. Die Datenbank der Wahl für viele PHP-Entwickler, kann aber auch mit Node.js, C#, C++, Java, Perl, Ruby und Python verwendet werden.
MSSQL - Microsoft SQL bietet viel Stabilität, da es direkt von Microsoft entwickelt wird, das auch eine gewisse Unterstützung in Bezug auf Disaster Recovery bietet.
MariaDB - wurde von den Machern von MySQL auf MySQL aufgebaut, mit der Absicht, MariaDB als kostenlose Version für immer zu behalten.
PostgresSQL - Eine sehr beliebte Open-Source-Datenbank. Stolz auf sich selbst als die weltweit fortschrittlichste Open-Source-Datenbank
Oracle - Diese Version ist in der Regel auf die Unternehmenslösungen von Oracle zugeschnitten und weist in der kostenlosen Version einige Einschränkungen auf.

NoSQL

MongoDB - Die wohl bekannteste NoSQL-DB, die unter Anwendungsentwicklern, die mit dem MERN-Stack (MongoDB, Express, React, Node) oder MEAN-Stack (MongoDB, Express, Angular, Node) arbeiten, weit verbreitet ist.
Firebase - 2011 eingeführt und 2014 von Google übernommen, wird von vielen Web- und Mobilanwendungsentwicklern genutzt.
Apache Couch DB - Eine dokumentenbasierte NoSQL-DB, die Daten als JSON speichert.
Redis: Hierbei handelt es sich um eine NoSQL-DB, die wahrscheinlich am bekanntesten für ihre Verwendung bei der Speicherung von Daten mit optionaler Lebensdauer ist. Sie ist auch für ihre Geschwindigkeit bekannt.

Schlussfolgerung

Sie können jede Art von Anwendung entweder mit einer SQL- oder NoSQL-Datenbank erstellen. Das hängt von Ihren Anforderungen ab. Wenn Sie eine Datenbank mit mehr Lese- und weniger Schreibzugriffen benötigen, könnte eine NoSQL-Datenbank eine gute Option sein. Wenn Sie jedoch eine Anwendung entwickeln wollen, bei der mehr geschrieben als gelesen wird, ist eine SQL-Datenbank möglicherweise die bessere Lösung. Was die Skalierbarkeit anbelangt, so werden Sie bei einer sehr großen Anwendung möglicherweise beide DBs verwenden.

Idris Lawal

Autor