La première chose qui me vient à l'esprit ici est :pourquoi le stockage d'une référence vous coûte-t-il 5 000 fois ce qu'il en coûte de stocker dans un sous-document ?
D'accord, en regardant votre schéma, je pense que la meilleure méthode est la collecte séparée pour les mots, pas les packages.
Le premier drapeau rouge que j'ai vu est votre double imbrication ici :
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}
}]
}]
Les words le sous-document sera très difficile à utiliser dans la version actuelle de MongoDB, normalement 2-3 niveaux profonds commencent à avoir des problèmes, en particulier avec les opérateurs positionnels.
Considérant maintenant que vous devez toujours travailler à partir de la valeur la plus élevée possible que vous pouvez obtenir ici :
Vous devez également prendre en considération le coût du logement de ce document. Les opérateurs dont vous avez besoin seront ceux en mémoire tels que $pull , $push , $addToSet etc, ce qui signifie que votre document entier devra être sérialisé et chargé dans les structures C++ natives de MongoDB. Ce sera une tâche extrêmement consommatrice en fonction du trafic vers ces documents.
Vu votre commentaire :
il met simplement un autre clou dans le cercueil de l'intégration des mots dans le document principal de l'utilisateur. Compte tenu de ce que j'ai dit dans le paragraphe précédent, cela ne fonctionnera pas bien avec le coût d'utilisation des opérateurs en mémoire sur les words tableau.
Cela fonctionnera beaucoup mieux si les mots sont séparés, $slice est également un opérateur en mémoire et subirait probablement une diminution des performances ici.
Et c'est une réponse rapide et motivée. Je suis sûr que je pourrais expliquer davantage ma raison, mais cela devrait suffire.
