NoSQL (MongoDB) darauf ausgelegt, vieles doppelt zu speichern? Richtige Wahl?

[Gast]

Hey Leute,

als ich von NoSQL Datenbanken, bzw. auch von MongoDB gehört habe, war ich begeistert.

Klang im ersten Moment alles ganz einfach und bietet gute Vorteile (Natürlich auf Anwendungszwecke bezogen).

Aber nun bei einem Projekt, bei dem ich wirklich mal MongoDB verwende, stoße ich immer auf schwierige Entscheidungen, bzw. auf Stellen, an denen ich das System für mich in Frage stelle, da ich vieles doppelt speichern müsste.

Kleines Beispiel:

Ich kann auf meiner Website Beiträge (Posts) erstellen (Wie bei jedem beliebigen Netzwerk auch). An diese Beiträge kann ich auch Bilder anhängen. Die Beiträge sollen zudem mit Hashtags markiert sein.

Z.B. in MySQL halte ich nun alles in einzelnen Tabellen und kann mir bei bedarf alles zusammen joinen. Wenn ich also ein Bild über ein bestimmtes Hashtags suche, dann frage ich dieses über Hashtags > Posts > Images ab. Eine simple Abfrage.

Jetzt zu NoSQL-Datenbank bzw. MongoDB.

Hier habe ich die Möglichkeit alles in einem Dokument zu speichern. Nur will ich ja Hashtags nicht doppelt und dreifach in verschiedenen Post-Dokumenten haben, also lagere ich diese in eine eigene Collection aus. Die Bilder möchte ich auch einzeln z.B. in einer Galerie verwenden, also lagere ich diese auch aus. Somit habe ich 3 Collections.

Posts, Images, Hashtags

Das Post-Dokument hat dann Referenz-Objekte zu seinen Images und Hashtags.

So, nun wird es knifflig und ich frage mich, wie die optimale Lösung ist.

Ich möchte nun alle Posts anhand eines Hashtags ermitteln. Also frage ich einen Hashtag ab, erstelle mir anhand des Ergebnisses ein Referenzobjekt und frage wiederum damit die Posts ab. Somit eine Abfrage für Hashtag und eine für die Posts.

Jetzt möchte ich aber alle Bilder haben, die eben meinen gesuchten Hashtag haben. Somit müsste ich jetzt den Hashtag abfragen, daraus ein Referenz-Objekt erstellen, dann alle Posts abfragen und mit dem Image-Referenz-Objekten dann meine Images abfragen. Bei einer Zahl von 1000 Posts, sind das ja schon viele tausende Abfragen.

Die zweite Möglichkeit wäre dann, alles doppelt und dreifach zu speichern. Also setzte ich die Hashtag-Referenzen nicht nur in Post rein, sondern auch in die Images die dazu gehören. Somit erstelle ich aber viele Daten.

Welche Methoden sind nun für solche Datenbanken vorgesehen? Geht man den Weg der mehrfachen Abfragen oder den des mehrfachen Speicherns?

Die Frage die mir dann wiederum dabei aufkommt... Wenn ich auf solche Probleme stoße, ist dann NoSQL noch die richtige Wahl für mich? Wenn man sich umhört, dann ist ja Twitter z.B. auch auf dieses Datenbank-System umgestiegen... Die mussten theoretisch (ganz vereinfacht und vorsichtig gesagt) auch eine Lösung dafür finden... oder?

Ich erhoffe mir jetzt hierdurch keine direkte Antwort, dass ich jetzt diese oder jene Datenbank nehmen soll. Nur mal grobe Meinungen ob ihr auch auf solche Situationen gestoßen seid, wie ihr diese gelöst habt oder ob ihr irgendwo Erfahrung habt.

Vielen Dank.

[akretschmer]

Schon mal einen Blick auf PostgreSQL gworfen? Da kannst auch JSON-Objekte speichern, in aktuellen Tests ist PG sogar schneller als Mongo. Und Du hast noch immer eine relationale DB.

[ChristianK]

Haben diese Tests auch Quellen oder muss ich die Glaskugel ausgraben?

[akretschmer]

http://www.enterprisedb.com/postgres...eloper-reality

[rkr]

Naja, wenn es darum geht, MongoDB für etwas zu verwenden, wofür man sonst aus Sicht der zu verwaltenden Daten eher ein RDBMS verwendet hätte, dann ist PostgreSQL sicher die bessere Wahl - zumindest eine gute Alternative. Wenn man allerdings mit massiven Massen an Daten zu kämpfen hat (pinterest, facebook, google, twitter etc) dann wird man zu viele Probleme mit einem RDBMS bekommen.

1000 Datensätze? Bleib bei einem RDBMS. Es geht bei MongoDB eher ums MapReduce, als um Normalisierung von Daten.

[rudygotya]

Hier habe ich die Möglichkeit alles in einem Dokument zu speichern. Nur will ich ja Hashtags nicht doppelt und dreifach in verschiedenen Post-Dokumenten haben, also lagere ich diese in eine eigene Collection aus.

Nö, das musst du nicht aufteilen. Die Hashtags und deren Bilder sind ja quasi Eigenschaften des Postings => Die verwendeten Hashtags + Bilder würde ich direkt im Posts-Dokument speichern. Über mapReduce kannste dir alle verwendeten Hashtags/Bilder in eine eigene Collection schieben. http://docs.mongodb.org/manual/core/map-reduce/

Alternativ:
http://docs.mongodb.org/manual/core/...tion-pipeline/

[rkr]

Wenn es unbedingt NoSQL sein soll, dann solltest du vielleicht auch einen Blick auf Riak werfen. Riak ist verglichen mit MongoDB sehr ähnlich, bietet aber Links, die man mit Linkwalking ähnlich wie ein Join (hat eigentlich nicht viel mit einem Join am Hut, fühlt sich aber in vielen Fällen sehr ähnlich an) in eine Ergebnismenge importieren kann. Genau wie MongoDB macht Riak erst so richtig Sinn, wenn man seine Datenmenge über mehrere Knoten verteilen muss.

https://docs.basho.com/riak/2.1.1/th...isons/mongodb/

[ChristianK]

http://www.enterprisedb.com/postgres...eloper-reality

Ich bezweifle, dass ein Test mit 50 Millionen Einträgen als relevant für eine NoSQL-Datenbank gilt. Wäre einmal interessant das Verhältnis zu sehen, wenn man daraus 500 Millionen macht.

[akretschmer]

Schön Deine Neugier geweckt zu haben, Du wirst sicherlich berichten, oder?

[ChristianK]

Nö, ich verschandle doch nicht mein OS mit Postgres


Achtung: Kann Spuren von Sarkasmus und Ironie enthalten

[rkr]

Ich bezweifle, dass ein Test mit 50 Millionen Einträgen als relevant für eine NoSQL-Datenbank gilt. Wäre einmal interessant das Verhältnis zu sehen, wenn man daraus 500 Millionen macht.

Das ist völlig egal und immer abhängig von CPU und RAM.

[ChristianK]

Demnach sollte SQLite und PG auch genau gleich schnell sein? Der Algorithmus bzw. der zugrunde liegende Code spielt ganz klar eine Rolle.

[rkr]

Demnach sollte SQLite und PG auch genau gleich schnell sein?

Das habe ich so nicht gesagt. Es gibt da dieses CAP-Theorem. Da kannst du jeweils immer eine Kante nehmen und einem DMBS zuordnen.

Ein RDBMS ist für Umgebungen gut, wo du eine starke Maschine hast. Das RDBMS hat mehr Potential, wenn du der einen Maschine mehr Potential verschaffst. Oder einfacher ausgedrückt: Je schneller die eine Maschine ist, desto besser arbeitet dein RDBMS. Klar kannst du die Daten auch durch Replikation und Clustering über mehrere Knoten verteilen. Doch je mehr Knoten du hast, desto schmerzhafter wird jeder Schreibzugriff. Irgendwas leidet immer.

Bei NoSQL-Datenbanken wie MongoDB, CouchDB, Riak oder Redis ist es ziemlich egal wie schnell die einzelne Maschine ist, da das Konzept dieser Datenbanken vorsieht, auf einer Vielzahl von Maschinen zu laufen, die jederzeit ausfallen oder im Verbund neu angemeldet werden können. Dafür können diese Datenbanken auch nichts mit Konsistenz anfangen (bzw. sie betrachten Konsistenz mehr als Zufall denn als Zwang). MapReduce berechnet die Daten im Voraus - komplexe Abfragen, die die CPU belasten, sind hier nicht notwendig (MongoDB kann aber AdHoc-Abfragen ausführen; Riak macht das via Solr/Lucene).

So etwas wie eine Fotodatenbank wie Fotolia würde ich niemals mit einem RDBMS umsetzen. Hier steht klar im Fokus, dass die Fotos schnell über eine Vielzahl von Rechenzentren erreichbar sein müssen. Da ist es Schnuppe, ob irgendeine Maschine gerade mit neuen Fotos nicht ganz hinterher kommt. Auch ist es unwichtig, ob ein Löschvorgang eines Fotos sofort alle Knoten erreicht. Selbst, wenn dies Stunden brauchen würde, wäre das noch akzeptabel. Wenn ich dagegen ein Foto bei Fotolia kaufen möchte, dann sollte dieser Vorgang in jedem Fall erfolgreich protokolliert werden. Wenn ein Kunde Geld für etwas ausgibt und der digitale Beleg für diesen Vorgang verloren geht, dann ist das sehr ärgerlich. Für einen derartigen Vorgang würde ich dann schon eher ein RDBMS einsetzen.

Ich möchte zuguterletzt noch zu bedenken geben, dass einige NoSQL-Datenbanken auch genutzt werden (sollen) um Blobs über eine beliebige Anzahl an Knoten zu verteilen.

Der Algorithmus bzw. der zugrunde liegende Code spielt ganz klar eine Rolle.

Wenn du eine neue CPU in einen Rechner packst, die doppelt so viele Daten pro Sekunde verarbeiten kann, wird deine Datenbank sehr wahrscheinlich davon profitieren. Ebenso von mehr Arbeitsspeicher oder von einer schnelleren SSD.

[erc]

PS: was für eine Aussagekraft hat ein Benchmark der single threaded Befehle an Datenbanken sendet die auf multi concurrency optimiert sind? Mit genügend kreativität schreib ich auch ein Benchmark in dem sqlite schneller ist als postgres...