Es gibt kein NoSQL!
NoSQL ist ein Schlagwort.
Wenn Menschen über Datenbanken sprachen, meinten sie jahrzehntelang relationale Datenbanken. Und wenn Leute über relationale Datenbanken sprachen, meinten sie diejenigen, die Sie mit Edgar F. Codds strukturierter Abfragesprache steuern. Daten auf andere Weise speichern? Wahnsinn! Alles andere sind nur Flatfiles.
Aber in den letzten Jahren haben die Leute angefangen, dieses Dogma in Frage zu stellen. Die Leute fragten sich, ob Tabellen mit Zeilen und Spalten wirklich die einzige Möglichkeit sind, Daten darzustellen. Die Leute begannen zu denken und zu codieren und entwickelten viele neue Konzepte, wie Daten organisiert werden könnten. Und sie begannen, neue Datenbanksysteme zu erstellen, die für diese neuen Arten der Arbeit mit Daten entwickelt wurden.
Die Philosophien all dieser Datenbanken waren unterschiedlich. Allen diesen Datenbanken war jedoch gemeinsam, dass die strukturierte Abfragesprache nicht mehr für ihre Verwendung geeignet war. Daher hat jede Datenbank SQL durch ihre eigenen Abfragesprachen ersetzt. Und so wurde der Begriff NoSQL als Bezeichnung für alle Datenbanktechnologien geboren, die sich dem klassischen relationalen Datenbankmodell widersetzen.
Was haben NoSQL-Datenbanken gemeinsam?
Eigentlich nicht viel.
Sie hören oft Sätze wie:
- NoSQL ist skalierbar!
- NoSQL ist für BigData!
- NoSQL verletzt ACID!
- NoSQL ist ein verherrlichter Schlüssel- / Wertspeicher!
Ist das wahr? Nun, einige dieser Aussagen mögen für einige Datenbanken zutreffen, die allgemein als NoSQL bezeichnet werden, aber jede einzelne ist auch für mindestens eine andere falsch. Das einzige, was NoSQL-Datenbanken gemeinsam haben, ist, dass es sich um Datenbanken handelt, die kein SQL verwenden. Das ist es. Das einzige, was sie definiert, ist, was sie voneinander unterscheidet.
Was zeichnet NoSQL-Datenbanken aus?
Daher haben wir klargestellt, dass alle Datenbanken, die üblicherweise als NoSQL bezeichnet werden, zu unterschiedlich sind, um sie zusammen auszuwerten. Jeder von ihnen muss separat bewertet werden, um zu entscheiden, ob sie zur Lösung eines bestimmten Problems geeignet sind. Aber wo fangen wir an? Zum Glück können NoSQL-Datenbanken in bestimmte Kategorien eingeteilt werden, die für verschiedene Anwendungsfälle geeignet sind:
Dokumentorientiert
Beispiele: MongoDB, CouchDB
Stärken: Heterogene Daten, arbeiten objektorientierte, agile Entwicklung
Ihr Vorteil ist, dass sie keine konsistente Datenstruktur benötigen. Sie sind nützlich, wenn sich Ihre Anforderungen und damit Ihr Datenbanklayout ständig ändern oder wenn Sie mit Datensätzen arbeiten, die zusammengehören, aber dennoch sehr unterschiedlich aussehen. Wenn Sie viele Tabellen mit zwei Spalten haben, die als "Schlüssel" und "Wert" bezeichnet werden, sollten Sie sich diese ansehen.
Diagrammdatenbanken
Beispiele: Neo4j, GiraffeDB.
Stärken: Data Mining
Während die meisten NoSQL-Datenbanken das Konzept der Verwaltung von Datenbeziehungen aufgeben, umfassen diese Datenbanken es noch mehr als die sogenannten relationalen Datenbanken.
Ihr Fokus liegt auf der Definition von Daten durch ihre Beziehung zu anderen Daten. Wenn Sie viele Tabellen mit Primärschlüsseln haben, die die Primärschlüssel von zwei anderen Tabellen sind (und möglicherweise einige Daten, die die Beziehung zwischen ihnen beschreiben), sind diese möglicherweise etwas für Sie.
Schlüsselwertspeicher
Beispiele: Redis, Cassandra, MemcacheDB
Stärken: Schnelle Suche nach Werten mit bekannten Schlüsseln
Sie sind sehr simpel, aber das macht sie schnell und einfach zu bedienen. Wenn Sie keine gespeicherten Prozeduren, Einschränkungen, Trigger und all diese erweiterten Datenbankfunktionen benötigen und nur eine schnelle Speicherung und einen schnellen Abruf Ihrer Daten wünschen, sind diese für Sie.
Leider gehen sie davon aus, dass Sie genau wissen, wonach Sie suchen. Sie benötigen das Profil von User157641? Kein Problem, dauert nur Mikrosekunden. Aber was ist, wenn Sie möchten, dass die Namen aller Benutzer zwischen 16 und 24 Jahren "Waffeln" als Lieblingsessen haben und sich in den letzten 24 Stunden angemeldet haben? Pech gehabt. Wenn Sie keinen eindeutigen und eindeutigen Schlüssel für ein bestimmtes Ergebnis haben, können Sie ihn nicht so einfach aus Ihrem KV-Geschäft entfernen.
Ist SQL veraltet?
Einige NoSQL-Befürworter behaupten, dass ihre bevorzugte NoSQL-Datenbank die neue Art ist, Dinge zu tun, und SQL gehört der Vergangenheit an.
Haben sie recht
Nein, natürlich nicht. Obwohl es Probleme gibt, für die SQL nicht geeignet ist, hat es dennoch seine Stärken. Viele Datenmodelle lassen sich einfach am besten als Sammlung von Tabellen darstellen, die aufeinander verweisen. Vor allem, weil die meisten Datenbankprogrammierer jahrzehntelang darin geschult wurden, Daten relational zu denken, und der Versuch, diese Denkweise auf eine neue Technologie zu übertragen, die nicht dafür gemacht wurde, endet selten gut.
NoSQL-Datenbanken sind kein Ersatz für SQL - sie sind eine Alternative.
Die meisten Software-Ökosysteme in den verschiedenen NoSQL-Datenbanken sind noch nicht so ausgereift. Obwohl es Fortschritte gibt, gibt es noch keine zusätzlichen Tools, die so ausgereift und leistungsfähig sind wie die für gängige SQL-Datenbanken verfügbaren.
Außerdem gibt es viel mehr Know-how für SQL. Generationen von Informatikern haben Jahrzehnte ihrer Karriere mit der Erforschung relationaler Datenbanken verbracht. Dies zeigt: Die Literatur über SQL-Datenbanken und die Modellierung relationaler Daten, sowohl in der Praxis als auch in der Theorie, könnte mehrere Bibliotheken voller Bücher füllen. Das Erstellen einer relationalen Datenbank für Ihre Daten ist ein so gut recherchiertes Thema, dass es schwierig ist, einen Eckfall zu finden, in dem es keine allgemein anerkannte Best Practice gibt.
Die meisten NoSQL-Datenbanken stecken dagegen noch in den Kinderschuhen. Wir finden immer noch heraus, wie wir sie am besten nutzen können.