Das erste, was mir hier in den Sinn kommt, ist:Warum kostet Sie das Speichern einer Referenz das 5000-fache dessen, was das Speichern in einem Unterdokument kostet?
Okay, wenn ich mir Ihr Schema ansehe, glaube ich, dass die beste Methode die getrennte Sammlung von Wörtern ist, nicht von Paketen.
Die erste rote Flagge, die ich sah, war Ihre doppelte Verschachtelung hier:
packages : [{
package : {type: Schema.Types.ObjectId, ref: 'Packages'},
from : {type : Schema.Types.ObjectId, ref :'Languages'},
to : {type : Schema.Types.ObjectId, ref :'Languages'},
words : [{
word: {type: String},
progress: {type: Number,default : 0}
}]
}]
Die words Subdocument wird in der aktuellen Version von MongoDB sehr schwer zu bearbeiten sein, normalerweise treten bei 2-3 Ebenen Tiefe Probleme auf, insbesondere bei Positionsoperatoren.
In Anbetracht dessen, dass Sie immer mit dem höchstmöglichen Wert arbeiten sollten, den Sie hier erhalten können:
Sie müssen auch die Kosten für die Unterbringung dieses Dokuments berücksichtigen. Die Operatoren, die Sie benötigen, sind In-Memory-Operatoren wie $pull , $push , $addToSet usw., was bedeutet, dass Ihr gesamtes Dokument serialisiert und in die nativen C++-Strukturen von MongoDB geladen werden muss. Je nach Datenverkehr zu diesen Dokumenten ist dies eine äußerst aufwendige Aufgabe.
In Anbetracht Ihres Kommentars:
es setzt lediglich einen weiteren Nagel in den Sarg der Einbettung der Wörter in das Hauptbenutzerdokument. In Anbetracht dessen, was ich im vorherigen Absatz gesagt habe, funktioniert dies nicht gut mit den Kosten für die Verwendung von In-Memory-Operatoren für die words Array.
Dies funktioniert viel besser, wenn die Wörter aufgeteilt werden, $slice ist auch ein In-Memory-Operator und würde hier wahrscheinlich Leistungseinbußen erleiden.
Und das ist eine schnelle begründete Antwort. Ich bin mir sicher, dass ich noch mehr über meinen Grund erklären könnte, aber das sollte reichen.
