Mongodb Schema pour Posts and Shares

Question

Je suis nouveau sur mongodb NoSQL et je suis bloqué au point où je suis incapable de prendre la décision de modéliser le schéma qui pourrait le mieux servir mon but.

Je dois concevoir un schéma de manière à ce que mon résultat final soit Posts et Partages classés par temps. Pour cela, je considérais deux options:

---

Option 1: Different Collection pour postes et Partager comme:

Schéma de collection Post:

var postSchema = mongoose.Schema({ 
    postText: String, 
    postedBy: String, 
    privacy: Number, 
    updatedOn: { type: Date, default: Date.now }   
}, { collection: 'posts' }); 

Schéma pour Partager Collection

var shareSchema = mongoose.Schema({ 
    dis_Id: { type: mongoose.Schema.Types.ObjectId }, // Id of post that is shared 
    shareBy: { type: mongoose.Schema.Types.ObjectId }, 
    shareText: String, 
    share_privacy: Number, 
    shareOn: { type: Date, default: Date.now } 
}, { collection: 'shares' }); 

---

Option 2: Intégrer Quote-part dans les messages se

Nouveau schéma pour post

var postSchema = mongoose.Schema({ 
    postText: String, 
    postedBy: String, 
    updatedOn: { type: Date, default: Date.now }, 
    privacy: Number, 
    share: { 
    shareBy: { type: mongoose.Schema.Types.ObjectId }, 
    shareText: String, 
    share_privacy: Number, 
    shareOn: { type: Date } 
    }  
}, { collection: 'posts' }); 

---

Maintenant que cela pourrait être un meilleur choix? L'option 1 pose un problème d'interrogation car il n'y a pas de jointure dans mongodb et l'option 2 entraîne la réplication des mêmes données et peut atteindre plusieurs milliards pour des centaines de milliers d'utilisateurs.

Answer 1

Ok. Je suggère l'approche suivante:

1. Puisque vous avez déjà le nom d'utilisateur, vous pouvez récupérer la liste des poste correspondant à cet identifiant dans un ordre à l'aide sort triée. En cours d'itération sur chaque publication, vous pouvez récupérer les partages dans l'ordre trié en utilisant le même type que celui utilisé ci-dessus.

La clé ici est de comprendre les index que vous allez définir. Je suggère que vous devriez avoir les index suivants.

post_schema: index composé sur {nom d'utilisateur, updatedOn}

share_schema: indice composé sur {dis_Id, partageAu}.

Si les index composés ne sont pas utilisés, votre application ne sera pas mise à l'échelle pour un grand nombre d'enregistrements.

Answer 2

Eh bien, il est facile de travailler avec des documents incorporés car vous obtenez toutes les données requises ensemble, donc l'option 2 est bonne dans ce cas. Mais si vous êtes préoccupé par la taille des documents augmentant de plus de 16 Mo alors allez avec l'option 1. Dans ce cas, n'utilisez pas la requête agrégée pour joindre deux collections, car cela prendra du temps, il faudra d'abord effectuer toutes les opérations. sauter l'opération. Au lieu de cela, vous devriez interroger chaque collection individuellement et créer une réponse complète vous-même avec une certaine logique personnalisée.