MongoDB

Bases de Datos Documentales - MongoDB

La madurez lograda por las bases de datos relacionales, ha propiciado que durante varias décadas esta sea considerada como la única opción para implementar la persistencia de los datos en una aplicación; luego, el problema era determinar cual motor usar Oracle, SQL Server, DB2,  MySQL, etc. Ya, desde hace un tiempo esto ha empezado a cambiar. 

¿Por qué una Base de datos Documental?

Hoy en día nos enfrentamos a problemas en los cuales, nos vemos algo limitados al tratar de modelarlos utilizando un enfoque relacional, un ejemplo de ello es cuando tenemos la necesidad de extender dinámicamente la información a almacenar, en alguna de nuestras entidades de negocio, un problema común para aplicaciones tipo SaaS; en estas aplicaciones normalmente ocurre, que diferentes clientes pueden requerir almacenar cierta información propia de su negocio que no es aplicable para todos los demás.

Trabajando  con una base de datos relacional, lo que deberíamos hacer es utilizar alguna una técnica de arquitectura de datos para manejar varios clientes (Multi-Tenant), sin embargo, este tipo de soluciones por lo general, implican una complejidad mayor en implementación y mantenimiento, sin mencionar que pueden violarse algunos de los principios teorícos de este tipo de bases de datos, como en el caso de las técnicas Private Table y Universal Table, que suelen ser de las primeras a considerar.

Este problema se puede modelar de forma nativa, en una base de datos documental. Para entender el por qué, explicaremos algunos los conceptos fundamentales de este enfoque.

Documento

Es el concepto central de estas bases de datos, su homólogo en el paradigma relacional sería un registro, tupla o fila. La diferencia radica en que los documentos están, conformados por un arreglo de pares clave-valor o campo-valor, lo que permite flexibilidad, para que documentos del mismo “tipo”, puedan tener diferentes estructuras; por ejemplo es válido tener tres documentos que representan tres personas diferentes almacenadas de la siguiente forma:

·         Persona1

o   Tipo Documento = “CC”

o   Numero Documento = “55665”

o   nombre  = “Juan”

o   apellido = “Pérez”

·         Persona 2

o   identificación = “CC_77877”

o   nombre Completo = “Luis Martínez”

·         Persona3

o   Tipo Documento = “CC”

o   Numero Documento = “8564332”

o   nombre  = “Marcela”

o   apellido = “Gómez”

o   teléfono  = 324 4563

Como se puede observar, el problema de extender la información de una entidad, es manejado naturalmente bajo este concepto, dado que cada documento contiene tanto sus datos como su definición. En una base de datos relacional, posiblemente deberíamos contemplar, agregar nuevas tablas o utilizar algunas columnas de más, para poder manejar aquellos campos que salen del modelo base.

Colección

Una colección agrupa un conjunto de documentos, en el mundo relacional lo más parecido sería una tabla que almacena un conjunto de registros, la diferencia radica, en que una colección  no define una estructura fija en los documentos, por lo que sería válido, aun que no necesariamente correcto, tener una base de datos conformada por una única colección de documentos donde se encuentren todas las entidades del dominio.

La flexibilidad tiene un costo

Es importante tener en cuenta que, será responsabilidad de la aplicación, garantizar la integridad referencial de los datos, ya que estos motores normalmente no manejan este  tipo de restricciones que son manejadas muy bien  por un motor de base de datos relacional.

Otro punto importante a tener en cuenta durante el diseño y construcción de la aplicación es, que la atomicidad de las operaciones de escritura, que en motores como MongoDB, (uno de los más populares en el ámbito documental), son manejadas a nivel de documento, esto quiere decir que en un eventual rollback solo podrá devolver al estado anterior del documento afectado, por el contrario, en un motor relacional una transacción de escritura puede involucrar varios registros de diferentes tablas.

Finalmente, algo que no se puede pasar por alto es, que el concepto u operación de JOIN no es aplicable en las BD documentales, es fundamental tener esto claro al momento de definir las estructuras de los documentos y sus relaciones, donde es importante conocer las estrategias de modelado de documentos (relaciones por referencia o documentos embebidos).