Ich hab mich mal am Wocheende etwas um Datenbanktheroie eingelesen. Dabei bin ich über NoSQL gestolpert. Was mir nur keiner (inkl. Wikipedia) genau erklären konnte, wieso NoSQL ein Hype ist.
Wie sieht es z.B. aus wenn man SQL - DB in NoSQL überführen will. Oder wie sieht es aus wenn man Tabellen die auf andere Tabellen verweisen in NoSQL welches Framework ist dabei am besten? CoachDB oder würde es auch mit Apache Jackrabbit gehen? Und wie sieht es aus wenn man Nested Sets in dem gleichen Projekt verwendet?
Das Problem ist, du kannst nicht einfach SQL gegen NoSQL vergleichen.
Unter SQL versteht man die klassischen relationalen Datenbanken.
Bei NoSQL werden verschiedene Ansätze zusammengefasst. Das fängt bei Objekt-DBs an, geht über einfache Key-Value-Stores hinzu Graphen-DBs usw. Hier muss man sich dann über die jeweiligen grundlegenden Eigenschaften informieren.
Der große Unterschied besteht eigentlich darin, das die NoSQL-Systeme für einen bestimmten Anwendungsfall sehr gut passen und die klassischen Datenbanksysteme vielseitig einsetzbar sind.
Ob es nur ein Hype ist, oder sich NoSQL-Systeme etablieren können, wird erst noch zeigen.
No-SQL hat unter anderen den Anwendungsbereich „Big Data“, eben dort wo man keine RDBMS braucht weil zB. Konsistenz und Transaktionen nicht so wichtig sind.
No-SQL ist eben nicht immer ein Ersatz fuer RDBMS, sondern oft Komplementaer, d.h. teilweise werden Daten in RDBMS abgelegt, teilweise in No-SQL Datastores.
Das macht zB. Facebook so, aber ich denke auch Google, und in meiner letzten Firma, Postgres/Oracle nebst Hadoop/HBase.
Klar ist da auch viel Hype dabei, sehe den Einsatzbreich eben nicht ueberall dort wo heute RDBMS verwendet werden.
Fowler definiert zB. „No SQL“ als „Not only SQL“, d.h. SQL kann es da schon geben als Abfragesprache.
Ansonsten bleibt noch zu sagen, das unter No SQL auch Dinge zusammengefasst werden, die wirklich wirklich ALT sind
Teradata hat schon vor 20 Jahren MR DBs gehabt, ADABAS C ist eine sehr alte DB, damals gab es noch keine RDBMS, heute zaehlt es zu den No SQL DBs.
Neben Big Data sind auch Graphdatenbanken (etwa neo4j) ein interessantes Beispiel für NoSQL: Wenn der Fokus weniger auf den Entitäten selbst, sondern auf den (vielfältigen und komplexen) Beziehungen zwischen diesen liegt, und Entitäten auch mehrere “Rollen” spielen können, sind relationale Datenbanken schnell überfordert. Solche Anforderungen finden sich z.B. bei Semantischen Netzen.
Eine Anwendung, die man eigentlich mit einem relationale Datenbanksystem umsetzten würde, einfach in No SQL machen ist nicht gant trivial. RDMS bieten so gute Abfragemöglichkeiten, die die einzelnen Entitäten miteinander auf unterschiedliche Arten verbinden, das habe ich im No SQL Bereich noch nicht gesehen. Und wenn dieser Funktionsumfang annähernd hin kam, waren diese Abfragen in der Hinsicht nicht mal so schnell wie SQL Datenbanken. NoSQL Datenbanken sind meiner Meinung nach für bestimmte Anwendungsfälle sinnvoll. Ich habe für mich keinen Fall gefunden, wo der vermeintliche Performancevorteil tatsächlich so stark ins Gewicht gefallen ist, dass ich auf die Abfrageflexibilät verzichten wollte.
Da sieht man es gibt kein genaues Bild was noSQL überhaupt genau ist, weil es einfach viel ist.
Ich persönlich denke, das die noSQL Systeme sich in verschiedenen Bereichen schon etabliert haben, aber es gibt halt noch genügend Bereiche, wo sie nicht sinnvoll sind. Es kommt einfach auf den Anwendungsfall an.
Das kann man so allgemein nicht sagen. Es ist richtig, das für viele Anwendungsfälle die RDMS-Mittel ausreichen, aber oft hat man auch Konstellationen, die sich nur umständlich - etwa über viele Joins oder geschachtelte Abfragen - abbilden lassen.
Das ist richtig. ich kenne genügend Beispiele für riesige SELECT Statements. Allerdings wüsste ich nicht, dass es die mir bekannten NoSQL Datenbanken an der Stelle einfacher machen. Man würde höchsten dort den Weg gehen und die Daten entsprechend aufbereiten und doppelt ablegen. Das könnte ich allerdings auch im SQL Bereich. Oder hast du ein Beispiel, wo NoSQL in der Hinsicht überlegen wäre?
Da es zig verschiedene NoSQL Systeme gibt, gehe ich jetzt auf dokumentenorientierte DBs wie MongoDB ein. Dort muss man sich von dem Gedanken der Normalisierung verabschieden. Die Schemata der einzelnen Collections werden mehr den den Abfragen angepasst, als wie eine normale Tabelle bei SQL. Wenn dies passt, flitzen die Abfragen auch ziemlich schnell heraus.
In einen MongoDB Buch wurde schon gezeigt, wie man z. B. einen Online Shop mit ein bisschen Denormalisierung mit MongoDB aufbauen kann.
