将评论和文章放在一起，这里我有一个疑问，当评论数量很大以后，会不会导致在查询文章列表页的时候效率低下？
如果将comments剥离到另一个collection里，这样是不是能缓解只显示文章列表的情况下的压力
{
"_id" : ObjectId(),
"author" : "",
"comment_num" : "",
"comments" : [
{
"text" : "",
"created" : ISODate(),
"author" : ""
},
],
"created" : ISODate(),
"text" : "",
"title" : ""
}
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
@halty fait valoir un bon point, je ne suis pas entièrement d'accord avec lui. S'il n'y a pas beaucoup de commentaires, le design réalisé est convenable, et ce qui a été dit ci-dessus est très bien. Mais s’il y a trop de commentaires, des problèmes surviennent. Les plus importants sont deux points de départ fondamentaux : 1. Le disque dur est trop lent ; 2. Tant que les données sont en mémoire, il n'y a aucun problème.
Lorsque les données sont extrêmement volumineuses, beaucoup de données doivent être lues sur le disque, car le fichier mappé en mémoire sera stocké dans la mémoire, mais nous n'en avons besoin que d'une petite partie. Le principal problème est que le système d'exploitation peut paginer. d'autres données sur le disque dur. Juste pour lister les articles, la mémoire n’est pas utilisée efficacement.
Sur un fichier disque, si un document continue de s'allonger de plus en plus longtemps, ce n'est pas une bonne chose. Parce que si de nouvelles données sont ajoutées, par exemple un nouveau commentaire, le document devient plus grand et ne peut pas tenir à l'emplacement d'origine, il faut donc trouver un nouvel emplacement et les trous précédents seront réutilisés. Mais le problème est que lorsque l'emplacement du document change, tous les index qui y sont associés doivent changer. Si vous disposez également d'un index sur le tableau, tel que le nom de l'utilisateur qui a publié le commentaire, l'index mis à jour sera lié linéairement à la longueur du tableau.
La personne ci-dessus a fait valoir un bon point sur ce point. Limite supérieure de 16 Mo.
Pour résumer, lorsqu'il y a trop de commentaires, cela affectera les performances.
Résumé, la conception du schéma doit être envisagée
findci-dessus n'est en fait pas un gros problème. Parce que les commentaires sur les articles populaires sont toujours lus par de nombreuses personnes, il est bon de les conserver en mémoire. Si le document continue de s'allonger, MongoDB allouera automatiquement plus d'espace disque lors de son allocation.Cela dit, je pense que la plupart de ces applications n'auront pas plus d'une centaine de commentaires... A ce moment, un seul document en profitera. Des centaines de commentaires ne poseront pas de problème, et le problème du. le sujet n'est pas un problème. J'espère que la candidature de l'auteur pourra dépasser ce nombre...
Tout d'abord, assurez-vous que lorsque le nombre de commentaires est important, cela n'entraînera pas d'inefficacité lors de l'interrogation de la page de liste d'articles. Vous pouvez spécifier que le document dans le jeu de résultats de la requête ne renvoie qu'une partie des données du champ (il convient de noter que si vous mettez à jour puis enregistrez un tel document qui ne contient qu'une partie des données du champ, une erreur peut se produire). recommandé et peut être fait facilement. Bon pour économiser la bande passante du réseau.
De plus, MongoDB a actuellement une limite sur la taille d'un seul document. S'il y a trop de commentaires, il peut dépasser la limite de taille par défaut du document. À ce stade, le commentaire doit être supprimé.