[Erledigt] Entscheidungshilfe bei Aufbau von MongoDB

[Gast]

Hey Leute,

arbeite derzeit viel mit MongoDB... stoße allerdings immer auf Punkte an denen ich mich entscheiden muss, wie ich nun am schlausten etwas in die Datenbank eintrage.

Erkläre euch mal meinen derzeitigen Stand.

Es gibt mehrere Collections, wie Users und Sites.

Es ist nun möglich, dass ein User einen Beitrag zu...
...einem anderen User macht.
...zu einer Seite macht.
...einfach für sich macht.

Zudem können Beiträge noch Kommentiert werden usw.

So ähnlich wie einfache Posts bei Facebook, bei denen es ja auch möglich ist, auf verschiedene Pinnwände etwas zu schreiben.

Nun kommen bei mir die Fragen auf:

1. Trage ich diese Beiträge immer bei dem User ein, der sie auch geschrieben hat?

2. Trage ich diese Beiträge dort ein, bei dem der Beitrag geschrieben wurde? Sprich, ein Beitrag von einem User kann an 3 verschiedenen Orten liegen.

3. Trage ich alle Beiträge in eine eigene Collection ein, und lese einfach immer die richtigen mittels ID aus.

4. Trage ich die Beiträge sowohl beim User der sie schreibt, wie auch beim Ziel (anderer User o. Seite) ein, und habe somit doppelten Content, muss aber weniger verknüpfen?

Wie löst Ihr solche Probleme?

Mir gefallen ja die ersten 3 gut... allerdings haben alle Vor- und Nachteile.

Was meint Ihr?

[rkr]

3.

Sonst würde ein User mit vielen Kommentaren schnell erheblich viel Resourcen beim auslesen verbrauchen - obwohl man dessen Beiträge vielleicht gar nicht verarbeiten möchte.

[Arne Drews]

ergänzend zu rkr: Normalisierung


EDIT:
Sorry, rkr hat mich darauf hingewiesen, daß es sich ja um eine NoSQL-Datenbank (MongoDB) handelt, das hatte ich überlesen!
Dann hat Normalisierung natürlich keine Relevanz!

[Gast]

Ah, sind ja schon Antworten da!

Es gibt auch Normalisierungen bei NoSQL, diese sind aber etwas offener.

Werde denke ich auch den 3. Weg nehmen.

Bin aber natürlich auch auf mehr Meinungen oder vll sogar Ideen gespannt.

[rkr]

Was meinst du denn mit "Beim User speichern"? Ich habe das so verstanden, dass du die Kommentare in das User-Dokument schreiben willst.

[Gast]

Ja, das wäre eine der Möglichkeiten.

Einfach in das jeweilige User-Dokument ein neues Array z.B. Posts... und dort dann alle Beiträge eintragen.

Allerdings sind wir ja anscheinend beide mehr der Meinung, dass es sinnvoller wäre, für alle Beiträge eine eigene Collection anzulegen. Deshalb ja Punkt 3.

[rkr]

Es kommt immer drauf an. Kommentare würde ich definitiv nicht an ein Userobjekt hängen. Ich würde die Kommentare zusammenmit der ID des Erstellers in eine eigene Collection packen. Dann kannst du auch sowas wie Varnish einsetzen. Varnish wuerde dann (also Beispiel) via ESI die einzelnen Kommentare einzeln laden und cachen. Das Userobjekt selbst weiss gar nicht, dass es Kommentare gibt. Zudem kannst du bei 10.000 Kommentaren nicht einfach so einen Kommentar hinnerhalt eines Objektes hinzufügen oder dir Kommentar#100-110 holen, ohne die alle Kommentare zu holen.

[Gast]

Also mom^^

Wir reden hier von:

• Beiträgen (Posts)
• Kommentaren dazu
• User die zu beiden gehören

Ich hätte jetzt die Kommentare in ein Array in den jeweiligen Beitrag rein. Denn dann hat man alles auf einmal... oder ist das etwa nicht so gut?

Wie ich dann die Usernamen mit den Beiträgen verbinde... muss ich mich auch noch mal einlesen.
Hätte Anfangs "quick & dirty" mehrere Abfragen gemacht.

Varnish hab ich auch noch nie gehört...
EDIT: Ah ok, ein Cache-System.

Oje^^

[erc]

Dann kannst du auch sowas wie Varnish einsetzen. Varnish wuerde dann (also Beispiel) via ESI die einzelnen Kommentare einzeln laden und cachen.

Was hat die Datenbanksturktur mit einem Caching-Proxy zu tun? Außer vielleicht je verhunzter die Stuktur, um so größer der Geschwindigkeitszuwachs.

Ich hätte jetzt die Kommentare in ein Array in den jeweiligen Beitrag rein. Denn dann hat man alles auf einmal... oder ist das etwa nicht so gut?
Wie ich dann die Usernamen mit den Beiträgen verbinde... muss ich mich auch noch mal einlesen.

http://docs.mongodb.org/ecosystem/us...ring-comments/

[rkr]

Was hat die Datenbanksturktur mit einem Caching-Proxy zu tun? Außer vielleicht je verhunzter die Stuktur, um so größer der Geschwindigkeitszuwachs.

Weil du dann für jedes "Dokument" eine von MongoDB generierte ID erhälst, die du via ESI referenzieren kannst. Wenn deine Kommentar-Dokumente nur Unterdokumente eines Objekts sind, dann musst du dir ID selbst erzeugen oder hast sowas wie "der dritte Kommentar" - das kann dann zu seltsamen Ergebnissen führen, wenn du auch Kommentar-Dokumente löschen kannst.

[Gast]

Also habe mich jetzt mal beim Link von "erc" eingelesen.

Also werde ich eine Collection für User, eine für Posts und eine für Kommentare machen.

Allerdings ist das ja auch etwas verzwickt. Das heißt ja, dass ein Post der Mittelpunkt von allem ist.

Denn im Dokument vom Post, muss einmal ein Referenzobjekt vom User sein, aber viele Referenzobjekte von den ganzen Kommentaren.

Das heißt, dass also "indirekt" doch die Kommentare in den Posts gespeichert werden.

Ist es dann vielleicht nicht doch schneller und performanter, keine Referenzobjekte zu verwenden, sondern einmal die ID des Posts auszulesen und danach denn einfach alle Kommentare auszugeben... anstatt alles über Referenzobjekte laufen zu lassen?

[rkr]

Nein: http://docs.mongodb.org/manual/refer...ent-references

[Gast]

Hm.. werde es mal so versuchen.

Posts und Kommentare fasse ich zusammen in eine Collection... ist ja quasi das selbe.

Also erstelle ich nun in den Post-Dokumenten ein Array mit jeweils ein Referenzobjekt für ein Kommentar.

In den Kommentaren und Posts selbst sind Referenzobjekte für die Userdaten.

Und wenn man ein Kommentar löschen will, muss man sämtliche Referenzobjekte mit löschen...

Finde die ganze Sache etwas komisch^^

Aber wenn das das schnellste und flexibelste ist, nun gut!

Vielen Dank

[erc]

Weil du dann für jedes "Dokument" eine von MongoDB generierte ID erhälst, die du via ESI referenzieren kannst. Wenn deine Kommentar-Dokumente nur Unterdokumente eines Objekts sind, dann musst du dir ID selbst erzeugen oder hast sowas wie "der dritte Kommentar" - das kann dann zu seltsamen Ergebnissen führen, wenn du auch Kommentar-Dokumente löschen kannst.

Versteh ich nicht. Ich cache doch nicht die einzeln Kommentare sondern eine Liste mit Kommentaren. Da interessiert mich doch das Kommentar ansich nicht, sondern maximal was für ein Ausschnitt ich aus der Liste darstellen will.

Aber wenn das das schnellste und flexibelste ist, nun gut!

So relational wie das klingt kann das nicht das schnellste und flexibelste sein Ich muss aber dazu sagen ich habe keine Ahnung von NoSQL, ich hab zwar schon ein paar Konzepte gesehen (auch MongoDB), ein wenig rumgespielt, mir die Highlights angeschaut, ein paar use cases durchgelesen/angeschaut, aber die NoSQL-Denke habe ich nicht. Ich kann mir aber nicht vorstellen das Relationen zwischen den Dokumenten die Stärke von MongoDB ist. Die Stärke von NoSQL liegt doch eigentlich darin das die Daten schon in der Form vorliegen wie sie gebraucht werden!?

[akretschmer]

Die Stärke von NoSQL liegt doch eigentlich darin das die Daten schon in der Form vorliegen wie sie gebraucht werden!?

Das ist auch mein Wissens-Stand hier. Und ich in gespannt, wohin das gehen wird. Ich denke nicht, daß NoSQL mittel- oder langfristig relationale DB's ersetzen wird. Da sehe ich eher Chancen in Systemen, die beide Welten sinnvoll vereinen.

http://info.enterprisedb.com/rs/ente...n_Postgres.pdf