SQL vs. NoSQL - Welches 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. Es wurde erstmals in den 1970er Jahren von einem Team von IBM-Forschern entwickelt. NoSQL-Datenbanken wurden 1998 erstmals von Carlo Strozzi verwendet.

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

Lassen Sie uns tief in diese beiden Datenbanken eintauchen, um Ihre Entscheidung besser zu informieren, wenn Sie das nächste Mal über eine nachdenken Datenbank für Ihr Projekt.

Database Structure

Sprechen wir über die Strukturierung.

SQL

SQL Datenbank haben eine bestimmte Schemastruktur.

Ein Schema enthält Tabellen, und jede Tabelle enthält eine bestimmte Anzahl von Spalten. Dies 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 aufrechterhalten und sicherstellen müssen, welche Art von Daten in Ihrer Datenbank gespeichert werden.

Jede Tabelle in einer SQL-Datenbank kann verknüpft werden. Das heißt, Sie können Beziehungen zwischen Tabellen haben. Diese Beziehungen können Eins zu Viele, Viele zu Viele oder Eins zu Eins sein. Die Art der Beziehung, die Sie implementieren, hängt davon ab, was Sie benötigen.

Betrachten wir zum Beispiel die hypothetische Situation. Wir haben eine Firma mit Benutzern, und Benutzer können Bestellungen für Produkte aufgeben. Dann könnten wir entscheiden, dass Benutzer mehrere Bestellungen erstellen können, aber jede Bestellung kann nur von einem Benutzer erstellt werden. Dies wäre eine zu viele Beziehungen, dh ein Benutzer zu vielen Bestellungen. Daher sieht die Tabellenstruktur für beide Tabellen ähnlich wie unten aus.

In unserer Datenbank 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 Auftragstabelle ist es einfach, jede Bestellung in der Auftragstabelle dem Benutzer zuzuordnen, zu dem sie gehört. Im Falle einer Eins-zu-Eins-Beziehung könnten wir die haben order_id auch auf der users_table wenn wir uns entscheiden, den Benutzer anhand seiner zugehörigen Bestellnummer zu ermitteln.

In vielen bis vielen Situationen ist normalerweise eine zusätzliche Tabelle beteiligt, die als Pivot-Tabelle bezeichnet wird. Dadurch können mehrere Datensätze einander zugeordnet werden. Verwenden Sie die obige Instanz. Wir würden haben,

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

und die Bestelltabelle wird sein

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

Basierend auf dieser von SQL bereitgestellten Struktur können Sie bequem Verknüpfungen zwischen Tabellen schreiben, die Daten aus verschiedenen Tabellen bereitstellen, die in einer Abfrage miteinander verbunden sind.

NoSQL

NoSQL Datenbanken wurden flexibler als SQL-DBs erstellt und enthalten auch größere Datenmengen.

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. Sie können mehrere unterschiedliche Dokumente mit unterschiedlichen Feldern in einer Sammlung auswählen. Es ist auch möglich, Beziehungen zwischen Sammlungen manuell herzustellen. Sie sind jedoch für einen solchen Zweck nicht geeignet. Stattdessen können Sie alles, was für eine einzelne Abfrage erforderlich ist, in derselben Sammlung speichern.

Wenn Sie eine SQL-Person sind, können Sie sich Sammlungen als Tabellen und Dokumente als Zeilen mit den Tabellen vorstellen. Es gibt jedoch keine Einschränkungen für die Datenspalten, die Sie mit der Tabelle hinzufügen können.

Zurück zu unserer zuvor definierten hypothetischen Instanz eines Unternehmens mit Benutzern und Aufträgen.

Eine Benutzersammlung kann definiert werden als:

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

Und die Auftragssammlung könnte definiert werden als:

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

In diesem Fall möchten wir jedoch vermeiden, dass beide Sammlungen manuell verbunden werden müssen (was in diesem Fall nicht der Fall sein sollte). Wir können Einträge in der Sammlung speichern, die am meisten gelesen werden. Ich habe (für dieses Beispiel) entschieden, dass dies die Orders-Sammlung sein wird.

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

In diesem Fall müssen wir nicht mehr aus der Benutzersammlung und nur noch aus der Auftragssammlung lesen, die jetzt alle benötigten Daten enthält.

Eine wichtige Sache, die Sie hier beachten sollten: Wenn Sie eine App erstellen, die viel liest als schreibt, ist eine NoSQL-Option wahrscheinlich besser für Sie geeignet. Weil Sie Ihre Daten alle in derselben Sammlung speichern und bequem aus dieser Quelle lesen können, um alle erforderlichen Daten zu erhalten.

Für eine Anwendung, die viele Schreibvorgänge (ca. 10,000 Schreibvorgänge pro Sekunde) in diesem Maßstab erfordert, ist es jedoch keine gute Idee, die NoSQL-Option zu verwenden, bei der Sie dieselben Daten an mehrere Speicherorte schreiben müssen. In dieser Situation ist eine SQL-Option wahrscheinlich besser geeignet, wenn Beziehungen zu allen Tabellen vorhanden sind und dieselben Daten nicht wiederholt an mehrere Speicherorte geschrieben werden müssen. Das Aktualisieren von Daten an einem Speicherort kann über das Beenden für andere Tabellen verfügbar sein Beziehung. Dies bedeutet natürlich nicht, dass jede dieser Datenbanken nicht mit Skalierung umgehen kann.

Scaling

Lassen Sie uns untersuchen, wie die Skalierung funktioniert.

SQL

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

Horizontale Skalierung bedeutet, Daten aus einer Datenbank in mehrere Datenbanken aufzuteilen, um das Laden zu erleichtern. SQL-Daten können jedoch aufgrund ihrer strengen Natur nicht in separate DBs aufgeteilt werden. Das richtige Skalieren einer SQL-Datenbank besteht darin, den CPU-, Speicher- und Speicherplatz des vorhandenen DB-Servers zu vergrößern. Dies bedeutet, dass die vertikale Datenbank vertikal skaliert wird.

NoSQL

NoSQL-DBs können sowohl horizontal als auch vertikal skaliert werden. Dies liegt an der Flexibilität bei der Datenspeicherung. Auf diese Weise können die Daten in mehrere Datenbanken aufgeteilt werden, wie dies bei der horizontalen Skalierung der Fall ist. Bei Bedarf kann es auch vertikal skaliert werden.

Eine wichtige Sache, die Sie hier beachten sollten: Bei der Skalierung 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 ist in seiner Rechenleistung begrenzt.

Hierbei ist auch zu beachten, dass Sie bei den meisten Anwendungen, die Sie erstellen, möglicherweise nicht die maximale Rechenleistung Ihres Servers erreichen. Es ist jedoch hilfreich, dies zu berücksichtigen. Für große Geschäftsanwendungen, die SQL implementieren, ist jedoch eine beliebte Option, um diese Einschränkung zu umgehen Schärfen.

Was ist Scherben?

Beim Sharding werden die großen Tische in kleine Stücke zerlegt, die als Shards bezeichnet werden. Das Sharding kann durch horizontale Partitionierung einer Datenbank erfolgen. Dies ist nicht mit horizontaler und vertikaler Skalierung zu verwechseln. Die horizontale Partitionierung bezieht sich auf den Prozess des Speicherns von Zeilen einer Tabelle in mehreren Datenbankknoten. Für die vertikale Partitionierung müssen dagegen Spalten einer Tabelle auf verschiedenen Knoten gespeichert werden. Dadurch kann die Datenbank effektiv skaliert und die Leistung gesteigert werden.

Database Examples

SQL

• MySQL - Eine sehr beliebte Open-Source-Datenbank. Die Datenbank der Wahl für viele PHP-Entwickler kann jedoch auch mit Node.js, C #, C ++, Java, Perl, Ruby und Python verwendet werden.
• MSSQL - Microsoft SQL bietet viel Stabilität, da seine Entwicklung direkt von Microsoft stammt, das auch Unterstützung bei der Notfallwiederherstellung bietet.
• MariaDB - Dies wurde von den Herstellern von MySQL auf MySQL aufgebaut, um MariaDB als kostenlose Version für immer beizubehalten.
• PostgresSQL - Eine sehr beliebte Open-Source-Datenbank. Stolz auf sich selbst als die fortschrittlichste Open Source-Datenbank der Welt
• Oracle - Dies ist normalerweise auf die Unternehmenslösungen von Oracle zugeschnitten, wobei die kostenlose Version einige Einschränkungen aufweist.

NoSQL

• MongoDB - Wahrscheinlich die bekannteste NoSQL-Datenbank, die unter Anwendungsentwicklern üblich ist, die mit MERN-Stack (MongoDB, Express, React, Node) oder MEAN-Stack (MongoDB, Express, Angular, Node) arbeiten.
• Firebase - 2011 eingeführt und 2014 von Google übernommen, wird es von Entwicklern von Web- und Mobilanwendungen häufig verwendet.
• Apache Couch DB - Eine dokumentbasierte NoSQL-Datenbank, in der Daten als JSON gespeichert werden.
• Redis: Dies ist NoSQL DB, wahrscheinlich am bekanntesten für seine Verwendung zum Speichern von Daten mit optionaler Lebensdauer. Es ist auch bekannt für seine Geschwindigkeit.

Conclusion

Sie können jede Art von Anwendung mit einer SQL- oder NoSQL-Datenbank erstellen. Das hängt von Ihren Anforderungen ab. Wenn Sie eine Datenbank in Betracht ziehen, in der Sie mehr Lese- und Schreibvorgänge ausführen, ist NoSQL möglicherweise eine gute Option. Wenn Sie jedoch in Betracht ziehen, eine App mit mehr Schreibvorgängen als Lesevorgängen zu erstellen, ist SQL möglicherweise die bessere Lösung. In Bezug auf die Skalierbarkeit verwenden Sie möglicherweise beide DBs, wenn Ihre App einen sehr großen Umfang erreicht.