Danke NoSQL, wir haben's verstanden

Ich bin seit über 25 Jahren fast täglich mit RDBMS (Relational Database Management Systems) und SQL beschäftigt. Als um die Jahrtausendwende die NoSQL Datenspeicher Furore zu machen begannen, beschäftigte ich mich natürlich auch damit.

Ich bin recht gut im Datenmodell-Design - doch wo ist das Schema in NoSQL? Aha, keines, hmm, wie soll das denn gehen? Da hatte ich schon ein ungutes Gefühl, denn bei mir waren die Anforderungen an DBMS seltener das superschnelle Schreiben auf die Disk, sondern die klevere Extraktion von Daten mittels Joins und die dafür notwendigen Index-Optimierungen. Wie formuliert man ein Join ohne Schema-Informationen? Und selbst wenn man irgendeinen Common-Sense entwickelt über die Struktur der Daten, wie hilft einem das Abfrage-Interface des NoSQL-Systems, die Daten zu finden? Wie also als UX und wie als sich selbst intern optimierender Daten-Store? Ohne die Bedeutung von Daten und deren Beziehungen zu kennen, sind Daten halt eben nur ein grosser Ozean von gleichartigen Key-Value Tupeln.

Die Problematiken, die NoSQL vor allem für die grossen Datenkraken lösen sollte, hatten allesamt damit zu tun, dass Schema-Änderungen in grossen Datenbanken ja schon problematisch, zumindest langsam sind. Wie soll das gehen in grossen, geographisch verteilten Systemen, wenn das RDBMS Paradigma ACID ist?

NoSQL versprach, das Heilmittel für Skalierung zu werden. Aber auch in meiner Einschätzung und später Wahrnehmung konnte das nicht richtig klappen. Daher erachtete ich dann erstmals das Startup NuoDB als die richtige neue Technologie, bei der SQL und ACID nicht erst nachträglich aufs Key-Value System aufgepfropft, sondern als Product-Highlight verstanden wurden.

Ein schöner englischer Artikel fasst das nun zusammen und zeigt, dass die klassischen RDBMS Hersteller den Kick der NoSQL Companies in den Allerwertesten mittlerweile verspürt und Abhilfe geschaffen haben. Lesenswert.