Bases de datos no-relacionales un vistazo no técnico

| Publicado por
#Aplicaciones en la nube

El Modelo relacional

El modelo relacional de guardar datos a estado desde hace mas de 40 años, por supuesto Wikipedia tiene un gran articulo Bases Relacionales , dándole una vista mas técnica.

Un ejemplo sencillo es un blog. Tienes una tabla para todos tus posts, cada post en esa tabla tiene una columna y en cada columna tiene algo como un ID numérico y el texto del post.

Cuando quieres leer un post de tu blog, la URL en la barra de direcciones dice algo a efecto de interpretarse como "dame el post #1". Cualquiera que sea el software de blog que estés usando este hace una petición a la base de datos diciendo "selecciona todo de la tabla post donde el ID del post es 1". La base de datos devuelve el post y el software renderisa el html en tu navegador, este es el ejemplo mas simple de interacción con la base de datos.

El Modelo relacional típico entra en juego cuando visitas un blog que tiene comentarios. Ahora no solo tienes una tabla para los posts, pero ahora también tienes una tabla para comentarios, esa tabla de comentarios también tiene una columna "ID" y una columna llamada "cuerpo" o algo por el estilo guardando el contenido o texto de los comentarios. Sin embargo esta tabla también tiene una columna llamada "post_id", en la cual se guarda el id del post al que este comentario pertenece o se relaciona.

Una ves mas el software del blog hace una petición a la base de datos, ahora pidiendo dos cosas "selecciona todo de la tabla de posts donde el ID es 1" y la segunda petición "selecciona todo de la tabla de comentarios donde el post_id es 1", esta segunda petición devolverá una lista de comentarios que tu software de blog convertirá en html y lo adjuntara a tus posts en el blog, en forma de sección de comentarios.

Problemas con el modelo Relacional

Por el propósito de este simple ejemplo, espero que no aya sido difícil de entenderlo. Pero talves te estas preguntando, "De verdad eso tiene sentido, almacenar los posts del blog aqui y los comentarios por aya?. Ellos son claramente relacionados. Cuando vas a estar examinando un comentario de un post sin estar esperando también el post?"

Muy bien. Este es un gran ejemplo de cuando una base de datos "no - relacional" o "NoSQL" podría dar mucho sentido.

El modelo no-relacional

Quedémonos con el mismo ejemplo de los posts y comentarios del blog, pero pensemos como "modelar" estos en una manera no-relacional.

El modelo de datos no-relacional se vería semejante a una hoja de papel. En efecto el concepto de única identidad (entity) y todos los datos pertinentes a esa única identidad es conocido en Mongo como "Documento" (Document), por eso esta es una manera decente de representarlo.

La manera en que el software de tu blog interactua con el post es teóricamente mas simple en una base de datos no-relacional. La petición entra, el software del blog pide a la base de datos Mongo diciendo "Por favor devuélveme este post especifico y todo lo relacionado a el ". En este caso toda una lista de comentarios. Pero esto no es todo.
Desde que no tenemos que estar tan obligados a determinar o definir como los datos deben de ir estructurados (Schema less).

Como seria si quisiéramos encasillar esos posts arbitrariamente con un numero de categorías?

No hay ningún problema solo basta con pegar esas categorías al documento del post y cuando el software del blog diga "Dame todo relacionado al post #1", las categorías, los comentarios y cualquier otros datos asociados vendrán en la respuesta.

Esta gran cantidad de flexibilidad es lo que hace a Mongo un sistema de almacenamiento muy popular, con un crecimiento muy acelerado.

Compañías tecnológicas que formulan o plantean ideas que cambian de semana a semana o de día a día, no necesitan volver a re estructurar todo el sistema.

Problemas con el modelo no-relacional

Es obvio que para este ejemplo la base de datos no-relacional es la mejor opción, pero al igual que cualquier otra herramienta útil tiene sus limitaciones.

Las cuales a experiencia personal son bastante pocas. Pero básicamente no es recomendable utilizar no-relacionales en proyectos altamente transaccionales.

Aunque esto es algo que se puede trabajar... Documentos incrustados y Arrays reducen la necesidad de usar joins. no mas joins ni transacciones de multi documentos.

En Rubik Utilizamos para todos nuestros proyectos de Aplicaciones en la nube la base de datos Mongo db que es :

  1. Escalable alto desempeño basada en documentos
  2. Construida para velocidad
  3. Queries basadas en documentos para mayor legibilidad
  4. Soporte total Index para alto desempeño
  5. Fácil Replicacion
  6. Auto Sharding para una fácil escalabilidad

Mongo db es grandioso para:

  1. Como reemplazo de RDBMS para Aplicaciones Web
  2. Administradores de contenido (CMS) semi-estructurados
  3. Real-Time analitycs y loggin de alta velocidad
  4. Chaching y Alta Escalabilidad
  5. Web 2.0 | Media | SAAS (software as a service) | Gaming | Healthcare | Finance | Telecom
Tweetea este articulo