Von MySQL zu MongoDB

Vor rund zwei Jahren habe ich mir die Frage gestellt, ob eine der neumodischen NoSQL Datenbanken wirklich schon ein praxistauglicher Ersatz für die mit jeweils ganz eigenen Problemen behafteten bekannten SQL-Datenbanken sein kann. Heute kann ich diese Frage ganz klar mit JA beantworten und möchte mit dieser Mini-Serie einen Weg zum Umstieg aufzeigen.

Auf SQL-Seite tritt dabei der wohl verbreiteste, aber gleichzeitig auch mit den meisten Problemen behaftete Vertreter an: MySQL. Auf der NoSQL-Seite habe ich mich bereits damals für MongoDB entschieden und halte dies nach wie vor für eine gute Wahl. Das hinter der Entwicklung stehende MongoDB Inc. bezeichnet die NoSQL-Lösung als "the industries best NoSQL database" - so schlecht kann die Wahl also nicht sein.

Die Bezeichnungen "SQL" und "NoSQL" Datenbanken sind eigentlich irreführend: SQL beschreibt lediglich eine Art minimalistische Programmiersprache, in der ein Nutzer mit einer Datenbank kommunizieren kann. SQL selbst ist zwar standatisiert, aber jede Datenbank definiert eigene Erweiterungen zum Standard oder weicht davon ab. Allen voran MySQL, das in der Standardeinstellung recht weit vom ANSI-Standard entfernt ist.

SQL wird allerdings meistens ebenfalls als Bezeichnung für relationale Datenbanken (RDBMS, Relational Database Management System) verwendet. Diese speichern miteinander verbundene Daten getrennt ab, meist in Form einzelner Tabellen, bei denen jede Spalte einen zu speichernden Wert und jede Zeile einen zusammenhängenden Datensatz darstellt. Die Zeilen werden normalerweise automatisch nummeriert.

NoSQL-Datenbanken sind noch irreführender: Zumindest eine lässt sich sogar mit SQL-Befehlen ansprechen, aber sie stehen für einen vollkommen anderen Ansatz der Datenspeicherung. Daten müssen sich keiner vordefinierten Form mehr anpassen, sondern werden einfach so abgespeichert, wie sind sind. Jeder Datensatz ist ein "Dokument" und besteht aus einem Key-Value-Hash, bei dem die einzelnen Values neben Zahlen oder alphanummerischen Werten auch ihrereseits Key-Value-Hashes oder Arrays sein können. Dafür entfallen die (der Datenbank bekannten) Abhängigkeiten und Beziehungen der einzelnen Dokumente.

In den folgenden Posts werde ich beide Datenbankarten kurz beschreiben und dann auf die Gemeinsamheiten und Unterschiede eingehen, bevor es an konkrete Beispiele geht.