数据库设计 - mongodb文章和评论放在同一条数据里效率怎样？

Question

将评论和文章放在一起，这里我有一个疑问，当评论数量很大以后，会不会导致在查询文章列表页的时候效率低下？
如果将comments剥离到另一个collection里，这样是不是能缓解只显示文章列表的情况下的压力

{
	"_id" : ObjectId(),
	"author" : "",
	"comment_num" : "",
	"comments" : [
		{
			"text" : "",
			"created" : ISODate(),
			"author" : ""
		},
	],
	"created" : ISODate(),
	"text" : "",
	"title" : ""
}

Answer 1

@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.

1. trouver
   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.
2. insérer
   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.
3. taille
   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

1. Échelle des données, tant que les données fréquemment consultées sont en mémoire, il n'y a aucun problème pour y accéder. L'utilisation insuffisante de la mémoire mentionnée dans le premier find ci-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.
2. Compatible avec le modèle d'accès. L'écriture de commentaires est trop petite par rapport à la lecture d'articles et de commentaires. Les données de Twitter sont que le tweet moyen est de 5 000 /s et le délai de lecture est de 300 000 /s. Tant que la demande de lecture peut être satisfaite en mémoire. L'utilisation de MongoDB élimine le besoin de mise en cache supplémentaire. Peu importe si l'interview est vraiment longue ou s'il y a trop d'articles, c'est facile à dire. Ce jour-là, le partitionnement de MongoDB sera utile.
3. Facile à développer Le coût du produit n'est pas seulement le coût du matériel et du réseau de la machine, mais plus important encore, le coût de développement des programmeurs et le salaire est si élevé... Par conséquent, il est également très important de l'écrire aussi rapidement, facilement et pas sujet aux erreurs, n'est-ce pas ? Cela explique pourquoi la flexibilité du modèle de document MongoDB est largement saluée.

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...

Answer 2

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é.