Guía de modelado de datos de MongoDB para aplicaciones de blogs

¿Quieres crear tu propio sistema de gestión de contenidos (CMS), también conocido como blog? Este es un ejemplo clásico a la hora de aprender a utilizar una base de datos, ya sea un sistema de gestión de bases de datos relacionales (RDBMS) o una base de datos nosql, ya que explora una cantidad potencialmente grande de datos, así como las relaciones entre ellos. El ejemplo de una aplicación de blogs también se adapta bien a otras necesidades de modelado de datos.

En este artículo, vamos a explorar algunas cosas que debes y no debes hacer a la hora de diseñar tus documentos nosql en MongoDB. Sin embargo, en realidad no desarrollaremos una aplicación de blogs, solo analizaremos las cosas desde una perspectiva de datos.

Los componentes de una aplicación para blogs

Antes de intentar diseñar un modelo de documento para un blog, es buena idea dar un paso atrás y pensar en todos los componentes que pueden tener datos asociados.

Un blog típico puede tener las siguientes características:

• Muchos usuarios o autores
• Muchas entradas de blog para un mismo autor
• Muchos comentarios para cualquier entrada del blog.

Por supuesto, esa lista de características puede ser más extensa y compleja dependiendo de las necesidades de tu negocio en un blog. Para simplificar, modelaremos nuestros datos basándonos en lo anterior.

Lo que puedes hacer, pero no debes hacer

Lo primero que se te ocurrirá al ver las características anteriores será tratar cada elemento de la lista como un documento independiente. Este es el enfoque típico que se utilizaría en una base de datos relacional como Postgres. En MongoDB, podría tener un aspecto similar al siguiente:

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

Lo anterior podría ser una representación muy simplificada de un autor. Por supuesto, podrías tener muchos otros campos, como email y demás, pero eso no es realmente importante aquí.

Entonces, podríamos tener lo siguiente para las entradas del blog:

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

Al igual que el anterior, el documento del blog podría tener otros campos como tags y cualquier otro que se te ocurra. Lo importante aquí es que hay una referencia « id » entre los dos documentos. Pero hablaremos de eso más adelante.

El modelo de documento final en este escenario giraría en torno a los comentarios:

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

Una vez más, el documento de comentarios de este escenario tiene una relación de referencia basada en un valor de tipo « id » entre el documento de comentarios y el documento del blog. Todo esto es muy común en una base de datos relacional, y lo cierto es que también funcionaría bien en MongoDB. Sin embargo, esto no te proporcionará la mejor experiencia con MongoDB.

Una de las razones por las que no conviene hacer esto en MongoDB es el rendimiento.

Para unir cada uno de estos tres documentos, debes utilizar una operación de concatenación ( $lookup ) dentro de una canalización de agregación. Estas operaciones $lookup no son baratas y podrían afectar negativamente a tu rendimiento a medida que tu base de datos crece, sobre todo si tienes más de una operación $lookup en tu canalización.

Hay mejores formas de hacer el trabajo en MongoDB.

Un enfoque mejor y más compatible con MongoDB para el modelado de datos

Una de las primeras reglas de MongoDB es que los datos a los que se accede juntos deben almacenarse juntos. Almacenar cada característica en un documento o colección separados incumple esa regla, ya que ya no realizamos una única operación de recuperación para los datos que se presentan al usuario.

Intentemos de nuevo resolver el problema, modelando los documentos para nuestro blog de la siguiente manera:

{
	"_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!"
				}
			]
		}
	]
}

Muy bien, entonces una de las reglas principales de MongoDB se cumple en el modelo anterior. Tenemos un único documento que utiliza el anidamiento para almacenar todas las entradas del blog y todos los comentarios con el autor.

Aunque podría funcionar, probablemente no sea una buena idea modelar los documentos de tu aplicación de blogs de esa manera.

MongoDB tiene límites de tamaño para los documentos, y cuando tienes arreglos ilimitados en esos documentos, corres el riesgo de superar esos límites. Por no mencionar que podrías tener problemas de rendimiento a medida que los arreglos se hacen más grandes. En este caso, podríamos tener un número ilimitado de entradas en el blog y un número ilimitado de comentarios por entrada. En algún momento se va a complicar la cosa.

Lo que podría funcionar mejor en este ejemplo es una combinación de las dos estrategias.

Recuerda que los autores, las entradas del blog y los comentarios pueden tener asociados cualquier número de campos. En este ejemplo, lo hemos mantenido al mínimo. Teniendo esto en cuenta, sabemos que los datos a los que más se accederá serán los del propio blog. Fíjate en el nuevo diseño:

{
	"_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!"
		}
	]
}

El segundo documento que tenemos en este ejemplo seguiría siendo el documento original con la información del autor:

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

Sabemos que parte de la información sobre el autor debe incluirse al mostrar un artículo del blog, pero no necesariamente necesitamos toda la información. Podemos incluir la información del autor que se necesita junto con el enlace _id dentro de la entrada del blog, y si el usuario necesita obtener más información sobre el autor, puede profundizar en tu aplicación. La operación « $lookup » no se realiza en todas las ocasiones, lo que mejora el rendimiento.

Ahora, tenemos el problema de la cantidad potencialmente infinita de comentarios para cualquier artículo de blog dado que actualmente se adjunta como un arreglo.

Hay varias formas de abordar esta cuestión y, en última instancia, la decisión depende de ti:

• Puedes optar por el enfoque ingenuo y guardarlos como un arreglo, lo que probablemente no sea una buena idea.
• Puedes volver a colocar los comentarios en el diseño original de un comentario por documento, todos con un identificador de referencia al artículo del blog y utilizando operaciones $lookup para incluirlos.
• Puedes utilizar una estrategia de archivo, almacenando un número fijo de comentarios en un arreglo dentro del artículo del blog y creando al mismo tiempo un documento de comentarios independiente para cada uno, lo que te permitirá consultar los comentarios adicionales solo si es necesario.
• Puedes explorar el patrón de agrupación, agrupando los comentarios en «grupos» de unos 100 comentarios por documento, consultando tantos grupos de comentarios como necesites a la vez. El agrupamiento evita el límite de tamaño del documento y también ayuda con la paginación. También puedes mejorar el rendimiento de este enfoque creando un índice en la tabla de comentarios ( blog_id ) para recuperar rápidamente los comentarios de cualquier artículo del blog en particular. Puedes encontrar más información sobre la indexación en la documentación de MongoDB.
• Mezcla, combina y mucho más...

En el caso del patrón de agrupación, tus documentos de comentarios podrían tener el siguiente aspecto:

{
	"_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
}

En este escenario, a medida que se crean nuevos comentarios, se busca un depósito que no esté lleno. Añades el nuevo comentario al arreglo y aumentas el valor del recuento. Aunque esta estrategia depende más de la lógica a nivel de aplicación para mantener los buckets, ofrece un mejor rendimiento. Si tu blog cuenta con un mecanismo de desplazamiento infinito, aún mejor, ya que así podrás paginar mejor utilizando los buckets.

Aunque esto queda fuera del alcance de este artículo en particular, si deseas saber qué se necesita para añadir un nuevo comentario, debes filtrar la colección de cubos de comentarios (véase la consulta de ejemplo más abajo) para encontrar los cubos que coincidan con blog_id y que tengan un comment_count inferior al valor elegido.

Para la coincidencia, utilizarías el operador « $push » en tus criterios de actualización y el operador « $inc » para aumentar el valor del recuento de comentarios. Todo esto se puede hacer en una sola operación y, si utilizas el indicador « upsert », puedes crear un nuevo grupo de comentarios si aún no existe ninguno que coincida con tus criterios.

Ejemplo de consulta de actualización: 

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

Conclusión

Por mucho que sería estupendo decir que debes almacenar todo lo relacionado con tu blog en un único documento anidado, probablemente no sería una buena idea. Al igual que probablemente no sería una buena idea implementar un modelo de datos que funcione bien con una base de datos relacional, pero no necesariamente con una base de datos de documentos como MongoDB.

Con MongoDB, es recomendable reducir al máximo las relaciones referenciadas para obtener el mejor rendimiento posible.

Ten en cuenta lo siguiente a medida que escalas:

• Si esperas recibir muchos comentarios, considera utilizar el patrón de cubo o alguna combinación del mismo junto con la incrustación parcial en el documento del blog.
• ¿Cuáles son tus necesidades de paginación?
• Indexa tus colecciones en función de cómo pienses realizar las consultas en tu aplicación.

Para reiterar, piensa en cómo presentarás los datos del blog en tu interfaz. ¿Realmente necesitas toda la información del autor con la solicitud o basta con parte de ella? ¿De verdad quieres cargar un millón de comentarios en tu artículo del blog o te basta con cargar unos pocos? Si lo piensas bien, te sorprendería saber cuántas operaciones de unión no necesitas.

Si eres nuevo en MongoDB, te recomiendo que eches un vistazo al curso Introducción a MongoDB en Python.