lunes, 29 de noviembre de 2010

MongoDB: Consejos sobre diseño de esquemas

El diseño de esquemas es una de las tareas más exigentes para nuevos usuarios de MongoDB. A menudo hay más de un modelo de datos viable, dependiendo de las necesidades de la aplicación, y los sacrificios han de ser medidos. Obtener un buen modelo de datos viene con la experiencia, y desde luego algo de experiencia con MongoDB es siempre útil. Pero si estás empezando, he aquí algunas ideas útiles a tener en mente.

Entender las características de MongoDB
Entender el conjunto de características de MongoDB es el primer paso para decidir qué patrones de modelo de datos tienen sentido. Por instancia, la habilidad de indexar claves de array y documentos internos, hacen viable el modelo de riqueza de documento. Si estás teniendo problemas modelando datos, primero asegúrate que entiendes las características de las bases de datos. E incluso si eres un veternao con MongoDB, asegúrate de mantener las últimas actualizaciones. Los operadores $slice y $or, recientemente añadidos, por ejemplo, te permiten mucha más flexibilidad en algunos casos.

Uso de documentos ricos
Parte de la belleza de MongoDB es su capacidad para almacenar estructuras de documentos ricos. Esto permite a los desarrolladores respresentar sus entidades de modelo de datos más holísticamente que lo que podrían hacer con una base de datos relacional. Mientras que en una base de datos relacional, una entidad producto puede ser dividida en docenas de tablas, el mismo producto puede guardarse en un documento simple en MongoDB. Que MongoDB pueda actuar en documentos ricos, usando la notación punto del lenguaje de consulta y una lista creciente de operadores de consulta y actualización, es la razón más convincente para considerar las estructuras ricas de documentos en tus esquemas.

Normalizar cuando sea necesario
Con todo lo dicho, no hay nada malo al migrar hacia una representación más normalizada. Algunos desrrolladores sienten que MongoDB no debería ser usado para almacenar relaciones entre colecciones, pero esto no podría estar más lejos de la verdad. Es una práctica común usar múltiples colecciones cuando las entidades involucradas necesitan la máxima cantidad de flexibilidad. Por instancia, si se representan productos y reseñas, recomendamos normalmente tener una colección separada para cada una. Las reseñas necesitan ser actualizadas y consultadas en una variedad de formas, y usualmente tienen en sí mismas una estructura de documento rica, conteniendo votos y otras bondades, información de perfil de usuario, etc. Podría preocuparte que normalizar algo como esto sin joins es ineficiente, así que será necesaria más de una consulta para visualizar una página de productos y sus reseña. Pero MongoDB es muy rápido; un pequeño benchmarking muestra que múltiples consultas no serán un problema para mayor parte de los casos.

Hay mucho más sobre el diseño de esquemas. La siguiente presentación aporta más información: