nicht angemeldet
NO-SQL - Eure Erfahrung
Moin,
ich bin dann mal auf den NO-SQL Zug aufgesprungen. Nachdem ich von mehreren unabhängigen Quellen gehört habe wie leicht und welche Vorteile eine nicht relationale Datenbank hätte. Von einem Bekannten wurde mir Mongo DB ans herz gelegt. Da die Installation anscheinend für Deppen ist( denn ich konnte es unter windows installieren) habe ich ein wenig rumgespielt. War auch durchaus positiv überrascht.
Es ist super einfach ein Array (oder Objekt?) ab zu speichern und auch sehr einfach dieses Array wieder aus der Datenbank zu laden. Jedoch denke ich kommt das ganze relativ schnell an seine Grenzen.
Ein Beispiel:
Es gibt einen Artikel. Dieser Artikel kann kommentiert werden. Ein Kommentar kann bewertet werden.
Bei einer relationalen Datenbank würde man 3(2) Tabellen haben. Artikel, Kommentar und eventuell noch eine extra Tabelle für Bewertung pro Kommentar (könnte man aber auch als Extrafeld beim Kommentar erfassen). Bei Mongo wäre das ein Mehrdimensionales. Jetzt frage ich mich, wie bekommt man eine Durchschnittsbewertung der Kommentare hin? Gibts da ein AVG bei Mongo? oder wie kann ich z.B. nur Kommentare von Männlichen Usern ausgeben? Kann man das per Subquery? Gerade bei diesem Beispiel gäbe es ein Querverweis von Kommentaren zu Usern. Das wäre eine klassische relation für mich. Wie wird sowas in Mongo oder anderen Datenbank Sprachen abgebildet?
Wie man sieht fehlt mir wahrscheinlich massiv Erfahrung mit den No-SQL Datenbanken bzw. auch Vorstellungkraft. Gibts dazu vielleicht gute Artikel?
Habe eben eine gute Verbindung zwischen SQL und Mongo gefunden (http://api.mongodb.org/wiki/current/SQL%20to%20Mongo%20Mapping%20Chart.html)
Gibt es auch Visualisiserungshilfen für die No-SQL Sachen so wie phpmyadmin?
Gruß
der spezial Mongo
T-Rex
-
Was für mich ein sehr wichtiges Kriterium wäre, was passiert wenn die Struktur deiner Daten sich ändert?
Heute hat dein Objekt 5 Felder. Davon packst du ein paar in die DB. Dann kommen zwei Felder hinzu. Eine SQL Datenbank kannst du nachziehen und die Spalten einfügen und passend füllen. Was machen deine bisher gespeicherten Objekte?
Dann fällt ein Feld weg oder wird umbenannt. Was machen hier deine Objekte?Kannst du definieren was zum Objekt gespeichert werden soll und was nicht?
Wie sieht es mit Indexen aus? Mit Auswertungen wie du sie angesprochen hast?-
Was für mich ein sehr wichtiges Kriterium wäre, was passiert wenn die Struktur deiner Daten sich ändert?
Heute hat dein Objekt 5 Felder. Davon packst du ein paar in die DB. Dann kommen zwei Felder hinzu. Eine SQL Datenbank kannst du nachziehen und die Spalten einfügen und passend füllen. Was machen deine bisher gespeicherten Objekte?
Dann fällt ein Feld weg oder wird umbenannt. Was machen hier deine Objekte?Kannst du definieren was zum Objekt gespeichert werden soll und was nicht?
Wie sieht es mit Indexen aus? Mit Auswertungen wie du sie angesprochen hast?Woher soll ich das wissen? Aber das sind alles gute Fragen die ich auch hätte stellen können. Da dies hier mein Thread ist, tun wir einfach mal so als ob diese sehr intelligenten Fragen gestellt habe!
Gruß
DECODERierender
T-Rex -
Tach!
Vorab: Ich habe noch keine direkten Erfahrungen mit NoSQL-Systemen. Ich gebe hier nur mein angelesenes Wissen und meine Interpretation desselben zum besten.
Was für mich ein sehr wichtiges Kriterium wäre, was passiert wenn die Struktur deiner Daten sich ändert?
MongoDB ist wie viele NoSQL-Datenbanken schemafrei. Das heißt, es gibt keine starre Struktur. Selbst in einer Liste gleichartiger Dinge können einzelne oder auch alle Dokumente (das Äquivalent zu Datensätzen) strukturell voneinander abweichen.
Heute hat dein Objekt 5 Felder. Davon packst du ein paar in die DB. Dann kommen zwei Felder hinzu. Eine SQL Datenbank kannst du nachziehen und die Spalten einfügen und passend füllen. Was machen deine bisher gespeicherten Objekte?
Daselbe wie bei einer Datenbank: die neuen Felder haben keinen oder einen Default-Wert.
Dann fällt ein Feld weg oder wird umbenannt. Was machen hier deine Objekte?
Ohne weiteres Zutun behalten sie die zusätzlichen Daten. Das kann man bei Bedarf bereinigen.
Kannst du definieren was zum Objekt gespeichert werden soll und was nicht?
Wegen der Schemafreiheit kann man das nicht. Die Frage wäre aber, ob man das will? NoSQL-Datenbanken sind nicht der Nachfolger von relationalen Datanbanken oder gar ein adäquater Ersatz. Die Gemeinsamkeit ist mehr oder weniger nur, dass sie Daten speichern. Ansonsten sind sie für andere Bedürfnisse entworfen worden. Es ist nicht sinnvoll, das RDBMS-Wissen und die dort gelernten Vorgehensweisen 1:1 in NoSQL-DBMS verwenden zu wollen. Besser ist es, das Wissen im Hinterkopf wegzustecken und sich erstmal ganz unvoreingenommen mit NoSQL-DBs zu beschäftigen und deren Möglichkeiten zu erschließen. Die im OP verlinkte Übersetzungsliste zu verwenden kann hinderlich sein, wenn man sie nur so verwendet, dass man sich das passende SQL-Statement für ein RDBMS zurechtlegt und dann nur noch die Entsprechung in der MongoDB-Syntax sucht. Das führt vermutlich nur dazu, dass man die neuen Möglichkeiten nicht erkennt, die Philosophie des anderen Systems nicht optimal kennenlernt und nicht ihr entsprechend die Lösungen entwirft, welche dann suboptimal sein können.
dedlfix.
-
Hallo
Meine Fragen waren als Anregung gedacht, über was man sich Gedanken machen sollte bevor man ein größeres Projekt anfängt ;-)
Ich hab mich mal interessehalber kurz damit beschäftigt, da bin ich auf diese Ideen gestoßen.NoSQL-Datenbanken sind nicht der Nachfolger von relationalen Datanbanken oder gar ein adäquater Ersatz. Die Gemeinsamkeit ist mehr oder weniger nur, dass sie Daten speichern. Ansonsten sind sie für andere Bedürfnisse entworfen worden.
Das war auch meine Folgerung.
Ich würde sowas zum Beispiel als temporäre Datenbank anwenden, die während der Programmlaufzeit Daten speichert und wieder lädt. Dazu braucht man keine "echte" DB installieren und kann einfach Objekte reinstecken und wieder rausholen.
Um wirklich- persistent
- viele Daten
- mit umfangreichen Selektionsmethoden
zu speichern und laden, würde ich bei SQL bleiben. Das ist für mich durchsichtiger. Mehr Arbeit macht es natürlich, aber ich habs lieber wenn ich gleich sehe was ich tu und nicht evtl. irgendwann mal merke, dass ich zig unterschiedliche Datenstände habe.
-
Tach!
Um wirklich
- persistent
- viele Daten
- mit umfangreichen Selektionsmethoden
zu speichern und laden, würde ich bei SQL bleiben. Das ist für mich durchsichtiger. Mehr Arbeit macht es natürlich, aber ich habs lieber wenn ich gleich sehe was ich tu und nicht evtl. irgendwann mal merke, dass ich zig unterschiedliche Datenstände habe.
Wenn du zig unterschiedliche Datenstände befürchtest, muss deine Anwendung schon ziemlich chaotisch sein, wenn sie selbst im Produktivbetrieb so viele Varianten erzeugt.
dedlfix.
-
Wenn du zig unterschiedliche Datenstände befürchtest, muss deine Anwendung schon ziemlich chaotisch sein, wenn sie selbst im Produktivbetrieb so viele Varianten erzeugt.
Warum? Viele Systeme die über längere Zeit laufen werden ergänzt, angepasst, erweitert....
Da muss man dann eben auch die Daten korrigieren. Und das tu ich am liebsten so dass ich weiß was passiert. In die No-SQL Datenbank mit der ich mal gespiet habe, hatte ich keinen Einblick was da wirklich alles drin steckt und wie das aussieht.-
Tach!
Wenn du zig unterschiedliche Datenstände befürchtest, muss deine Anwendung schon ziemlich chaotisch sein, wenn sie selbst im Produktivbetrieb so viele Varianten erzeugt.
Warum? Viele Systeme die über längere Zeit laufen werden ergänzt, angepasst, erweitert....Ja, und wenn du dabei die Übersicht verlierst, weil du dein Datenmodell nicht gut genug dokumentiert (oder memoriert) hast, dann bezeichne ich das als Chaos.
dedlfix.
-
-
Moin dedlfix!
Danke für deinen Beitrag. Klingt auch alles ganz gut, hätte da nur eine kleine Anmerkung.
Ich lese in letzter Zeit auch immer mehr bezüglich NO-SQL. Die Quälende Frage die ich mir stelle ist, ob mein System mit No-SQL performanter wäre und ob ein Umbau sich lohnt. Oder generell die Frage ob ein Umstieg und somit ein verlassen des vertrauten SQL Stils überhaupt sinnvoll ist. Deswegen muss man beide Idee doch mit einander vergleichen.Nehmen wir mal an das Mongo wirklich schneller und performanter ist. Habe ich damit die gleichen Möglichkeiten Daten zu selektieren und um zu wandeln wie mit SQL? Oder muss man dann einige Routinen die SQL bietet mit einer Programmiersprache simulieren?
Gruß
YES, WE CAN!(Ja, wir Dose!)
T-Rex-
Tach!
Die Quälende Frage die ich mir stelle ist, ob mein System mit No-SQL performanter wäre und ob ein Umbau sich lohnt. Oder generell die Frage ob ein Umstieg und somit ein verlassen des vertrauten SQL Stils überhaupt sinnvoll ist. Deswegen muss man beide Idee doch mit einander vergleichen.
Ja, aber erst nachdem du die Möglichkeiten beider Systeme kennengelernt hast, kannst du gerecht entscheiden, wie du die Aufgabenstellung mit dem jeweiligen Unterbau bewerkstelligen würdest. Dann kannst du den Arbeitsaufwand und die Folgen einigermaßen realistisch einschätzen.
Nehmen wir mal an das Mongo wirklich schneller und performanter ist. Habe ich damit die gleichen Möglichkeiten Daten zu selektieren und um zu wandeln wie mit SQL? Oder muss man dann einige Routinen die SQL bietet mit einer Programmiersprache simulieren?
Das sind die Fragen, die du im Detail klären musst, nachdem du dir zumindest in den Grundzügen sicher im Umgang mit MongoDB bist. Ich würde kein laufendes System umbauen auf eine Technik, von der ich nicht einen gewissen grundlegenden Erfahrungsschatz aufgebaut habe.
dedlfix.
-
Doofer Kreislauf
(x)Kann man ein Projekt erstellen mit der Technologie XY. Keine Ahnung, ich kenne Technologie XY zu wenig. Lass uns ein Projekt suchen wo man Technologie XY umsetzen kann "goto (x)".
Gruß
Cyclohexanol sprengender
T-Rex-
Tach!
(x)Kann man ein Projekt erstellen mit der Technologie XY. Keine Ahnung, ich kenne Technologie XY zu wenig. Lass uns ein Projekt suchen wo man Technologie XY umsetzen kann "goto (x)".
Bei mir fängt das eher mit dem Studium der Dokumentation, bevorzugt einem Tutorial an. Damit bekomme ich genug Ahnung von der groben Wirkungsweise, um mich an ein Projekt zu setzen, bei dem ich dann zu den speziellen Anforderungen Lösungen suche.
dedlfix.
-
-
-
-
-
-
Tach!
Es ist super einfach ein Array (oder Objekt?) ab zu speichern und auch sehr einfach dieses Array wieder aus der Datenbank zu laden. Jedoch denke ich kommt das ganze relativ schnell an seine Grenzen.
Definiere Grenzen. Meinst du, die Freiheit bei der Gestaltung der Dokumente hat ihre Grenzen in der Praktikabilität beim täglichen Handling mit Wildwuchs-Daten?
Jetzt frage ich mich, wie bekommt man eine Durchschnittsbewertung der Kommentare hin? Gibts da ein AVG bei Mongo?
Das Verfahren zum nennt sich Map/Reduce. Map wendet eine Funktion auf alle Daten an, Reduce berechnet einen Wert aus einer Vielzahl von Daten. Da es keine feste Struktur in den Dokumenten geben muss, werden solche Aufgaben in der Regel an benutzerdefinierte Funktionen weitergegeben.
dedlfix.