Guide de modélisation des données MongoDB pour les applications de blog

Vous souhaitez donc créer votre propre système de gestion de contenu (CMS), également appelé blog dans certains cas ? Il s'agit d'un exemple classique pour apprendre à utiliser une base de données, qu'il s'agisse d'un système de gestion de base de données relationnelle (SGBDR) ou d'une base de données nosql, car il explore une quantité potentiellement importante de données ainsi que les relations entre ces données. L'exemple d'une application de blog convient également à d'autres besoins en matière de modélisation des données.

Dans cet article, nous allons examiner certaines recommandations et mises en garde concernant la conception de vos documents nosql dans MongoDB. Cependant, nous ne développerons pas réellement une application de blog, mais nous examinerons uniquement les aspects liés aux données.

Les composants d'une application de blogging

Avant de tenter de concevoir un modèle de document pour un blog, il est recommandé de prendre du recul et de réfléchir à tous les composants susceptibles d'être associés à des données.

Un blog type peut présenter les caractéristiques suivantes :

• De nombreux utilisateurs ou auteurs
• Plusieurs articles de blog pour un même auteur
• De nombreux commentaires pour chaque article de blog

Bien entendu, cette liste de fonctionnalités peut s'allonger et se complexifier en fonction des besoins de votre entreprise en matière de blog. Pour simplifier, nous modéliserons nos données en nous basant sur ce qui précède.

Ce que vous pouvez faire, mais ne devriez pas faire

Votre première réflexion en examinant les fonctionnalités ci-dessus pourrait être de traiter chaque élément de la liste à puces comme un document distinct. Il s'agit de l'approche généralement utilisée dans une base de données relationnelle telle que Postgres. Dans MongoDB, cela pourrait ressembler à ceci :

{
	"_id": "author-1",
	"name": "Nic Raboy",
	"description": "I'm some dude named Nic."
}

Ce qui précède pourrait être une représentation très succincte d'un auteur. Bien entendu, il existe de nombreux autres domaines, tels que l' email, etc., mais cela n'est pas vraiment pertinent dans le contexte présent.

Ensuite, nous pourrions obtenir les éléments suivants pour les articles de blog :

{
	"_id": "blog-1",
	"author_id": "author-1",
	"title": "MongoDB is Awesome!",
	"content": "This is some blog content..."
}

Tout comme le précédent, le document du blog pourrait comporter d'autres champs tels que tags et tout ce qui vous vient à l'esprit. Le point important ici est qu'il existe une référence d'id entre les deux documents. Nous y reviendrons dans un instant.

Le modèle de document final dans ce scénario serait axé sur les commentaires :

{
	"_id": "comment-1",
	"blog_id": "blog-1",
	"username": "Anonymous User",
	"content": "Hey great article, it really helped a lot!"
}

Une fois de plus, dans ce scénario, le document de commentaire présente une relation de référence basée sur une valeur d'id e entre le document de commentaire et le document de blog. Ceci est très courant dans une base de données relationnelle, et il est vrai que cela fonctionnerait également très bien dans MongoDB. Cependant, cela ne vous permettra pas de profiter pleinement de MongoDB.

Une des raisons pour lesquelles il n'est pas recommandé de procéder ainsi dans MongoDB est liée aux performances.

Pour joindre chacun de ces trois documents, il est recommandé d'utiliser une opération d'agrégation ( $lookup ) dans un pipeline d'agrégation. Ces opérations d'$lookup s ne sont pas peu coûteuses et peuvent avoir un impact négatif sur vos performances à mesure que votre base de données évolue, d'autant plus si vous avez plusieurs opérations d'$lookup s dans votre pipeline.

Il existe des méthodes plus efficaces pour accomplir cette tâche dans MongoDB.

Une approche plus efficace et mieux adaptée à MongoDB pour la modélisation des données

L'une des premières règles de MongoDB stipule que les données auxquelles on accède ensemble doivent être stockées ensemble. Le stockage de chaque fonctionnalité dans un document ou une collection distinct enfreint cette règle, car nous n'effectuons plus une seule opération de récupération pour les données présentées à l'utilisateur.

Reprenons le problème et modélisons les documents de notre blog de la manière suivante :

{
	"_id": "author-1",
	"name": "Nic Raboy",
	"description": "I'm some dude named Nic.",
	"posts": [
		{
			"title": "MongoDB is Awesome!",
			"content": "This is some blog content...",
			"comments": [
				{
					"username": "Anonymous User",
					"content": "Hey great article, it really helped a lot!"
				}
			]
		}
	]
}

Par conséquent, l'une des principales règles de MongoDB est respectée dans le modèle ci-dessus. Nous disposons d'un document unique qui utilise l'imbrication pour stocker tous les articles de blog et tous les commentaires avec leur auteur.

Bien que cela puisse fonctionner, il n'est probablement pas judicieux de modéliser les documents de votre application de blog de cette manière.

MongoDB impose des limites de taille pour les documents, et lorsque ces derniers contiennent des tableaux illimités, vous courez le risque de dépasser ces limites. Sans compter que vous pourriez rencontrer des problèmes de performances à mesure que les tableaux s'agrandissent. Dans ce cas, nous pourrions avoir un nombre illimité d'articles de blog et un nombre illimité de commentaires par article. La situation risque de devenir compliquée à un moment donné.

Dans cet exemple, il serait peut-être plus efficace de combiner les deux stratégies.

Veuillez noter que les auteurs, les articles de blog et les commentaires peuvent être associés à un nombre illimité de champs. Dans cet exemple, nous avons opté pour la simplicité. Dans cette optique, nous sommes conscients que les données les plus fréquemment consultées seront celles du blog lui-même. Veuillez considérer le nouveau design :

{
	"_id": "blog-1",
	"author": {
		"_id": "author-1",
		"name": "Nic Raboy",
	},
	"title": "MongoDB is Awesome!",
	"content": "This is some blog content...",
	"comments": [
		{
			"username": "Anonymous User",
			"content": "Hey great article, it really helped a lot!"
		}
	]
}

Le deuxième document dont nous disposons dans cet exemple serait toujours le document original contenant les informations sur l'auteur :

{
	"_id": "author-1",
	"name": "Nic Raboy",
	"description": "I'm some dude named Nic."
}

Nous sommes conscients que certaines informations relatives à l'auteur doivent être incluses lors de l'affichage d'un article de blog, mais nous n'avons pas nécessairement besoin de toutes les informations. Nous pouvons intégrer les informations relatives à l'auteur qui sont nécessaires, ainsi que l'_id, dans l'article de blog. Si l'utilisateur souhaite en savoir plus sur l'auteur, il peut approfondir ses recherches dans votre application. L'opération d' $lookup ion n'est pas effectuée à chaque fois, ce qui améliore les performances.

Nous sommes actuellement confrontés au problème du nombre potentiellement infini de commentaires pour un article de blog donné, actuellement joint sous forme de tableau.

Il existe plusieurs approches pour gérer cette situation et c'est à vous qu'il revient de prendre la décision finale :

• Vous pouvez adopter une approche naïve et les conserver sous forme de tableau, ce qui n'est probablement pas une bonne idée.
• Vous pouvez rétablir l'affichage des commentaires selon la configuration initiale, à savoir un commentaire par document, en utilisant un identifiant de référence vers l'article du blog et en recourant aux opérations $lookup pour les inclure.
• Vous pouvez mettre en place une stratégie d'archivage consistant à stocker un nombre fixe de commentaires dans un tableau au sein de l'article de blog, tout en créant un document distinct pour chacun d'entre eux, ce qui vous permettra de ne rechercher des commentaires supplémentaires qu'en cas de nécessité.
• Vous pouvez explorer le modèle de regroupement, qui regroupe les commentaires dans des « groupes » d'environ 100 commentaires par document, et interroger autant de groupes de commentaires que nécessaire à la fois. Le regroupement permet de contourner la limite de taille des documents et facilite également la pagination. Vous pouvez également améliorer les performances de cette approche en créant un index sur l'blog_id e afin de récupérer rapidement les commentaires pour un article de blog particulier. Vous trouverez plus d'informations sur l'indexation dans la documentation MongoDB.
• Mélangez, assortissez et plus encore...

Dans le cas du modèle de regroupement, vos documents de commentaires pourraient ressembler à ce qui suit :

{
	"_id": "comment-bucket-1",
	"blog_id": "blog-1",
	"comments": [
		{
			"username": "Anonymous User",
			"content": "Hey great article, it really helped a lot!"
		},
		// More comments here...
	],
	"comment_count": 57
}

Dans ce scénario, lorsque de nouveaux commentaires sont créés, vous recherchez un compartiment qui n'est pas plein. Vous ajoutez le nouveau commentaire au tableau et augmentez la valeur du compteur. Bien que cette stratégie repose davantage sur la logique au niveau de l'application pour gérer les compartiments, elle permet d'obtenir de meilleures performances. Si votre blog dispose d'un mécanisme de défilement infini, c'est encore mieux, car vous pouvez alors mieux paginer à l'aide des compartiments.

Bien que cela dépasse le cadre de cet article, si vous souhaitez avoir un aperçu de la procédure à suivre pour ajouter un nouveau commentaire, vous devez filtrer la collection de buckets de commentaires (voir l'exemple de requête ci-dessous) pour trouver les buckets qui correspondent à l'blog_id et dont l'comment_count est inférieur à la valeur que vous avez choisie.

Pour la correspondance, vous utiliseriez l'opérateur $push dans vos critères de mise à jour et l'opérateur $inc pour augmenter la valeur du nombre de commentaires. Tout cela peut être effectué en une seule opération, et si vous utilisez l'indicateur « upsert », vous pouvez créer un nouveau compartiment de commentaires s'il n'en existe pas déjà un qui correspond à vos critères.

Exemple de requête de mise à jour : 

db.commentBuckets.updateOne(
  { blog_id: "blog-1", comment_count: { $lt: 100 } },
  { $push: { comments: newComment }, $inc: { comment_count: 1 } },
  { upsert: true }
)

Conclusion

Même s'il serait formidable de recommander de stocker toutes les informations relatives à votre blog dans un seul document imbriqué, ce ne serait probablement pas une bonne idée. Tout comme il ne serait probablement pas judicieux de mettre en œuvre un modèle de données qui fonctionne bien avec une base de données relationnelle, mais pas nécessairement avec une base de données documentaire telle que MongoDB.

Avec MongoDB, il est recommandé de réduire autant que possible les relations référencées afin d'obtenir les meilleures performances possibles.

Veuillez garder à l'esprit les points suivants lors de la mise à l'échelle :

• Si vous prévoyez de nombreux commentaires, envisagez d'utiliser le modèle « bucket » ou une combinaison de celui-ci avec un intégration partielle dans le document du blog.
• Quels sont vos besoins en matière de pagination ?
• Indexez vos collections en fonction de la manière dont vous prévoyez d'effectuer des requêtes dans votre application.

Pour récapituler, réfléchissez à la manière dont vous présenterez les données du blog dans votre interface utilisateur. Avez-vous réellement besoin de toutes les informations relatives à l'auteur avec la demande ou certaines d'entre elles suffisent-elles ? Souhaitez-vous réellement charger un million de commentaires avec votre article de blog ou est-il préférable d'en charger seulement quelques-uns ? En y réfléchissant bien, vous seriez surpris du nombre d'opérations de jointure dont vous n'avez pas besoin.

Si vous débutez avec MongoDB, je vous recommande de suivre le cours Introduction à MongoDB en Python.