Con esta entrada voy a empezar una nueva serie dedicada a MongoDB a lo largo de la cuál trataremos los siguientes conceptos:

  1. Introducción a MongoDB ¿Qué es? ¿En qué situaciones es recomendable usar MongoDB y en cuáles no?
  2. Instalación de un ‘clúster’ en modo single node.
  3. Instalación de un ‘Sharded clúster’
  4. Monitorización de MongoDB con PRTG.
  5. Operaciones habituales con MongoDB.
  6. Optimización de la configuración
  7. Operaciones MapReduce en MongoDB

Vamos a empezar por el principio, ver qué es y para qué sirve.

¿Qué es MongoDB?

MongoDB es un sistema de base de datos multiplataforma orientado a documentos, de esquema libre (NoSQL). Resumiendo mucho lo que significa NoSQL, podemos decir que que cada entrada o registro puede tener un esquema de datos diferente, con atributos o “columnas” que no tienen por qué repetirse de un registro a otro. Está desarrollado en C++ de modo que es bastante rápido a la hora de ejecutar sus tareas. Además, está licenciado como GNU AGPL 3.0, de modo que se trata de un software de licencia libre. Funciona en sistemas operativos Windows, Linux, OS X y Solaris.

Lanzado al público en 2009, MongoDB es una estrella en ascenso en el mundo NoSQL. Fue diseñada como una base de datos escalable -el nombre de Mongo viene de “Humongous” – con rendimiento y facilidad de acceso a los datos como objetivos centrales de diseño. Es una base de datos de documentos que permite que los datos persistan en un estado anidado, y lo que es más importante, pueden consultarse de forma ad hoc.

Vamos a ver algunos conceptos clave de MongoDB.

Registros, documentos, tablas y colecciones

En MongoDB, cada registro o conjunto de datos se denomina documento. Los documentos se pueden agrupar en colecciones, las cuales se podría decir que son el equivalente a las tablas en una base de datos relacional (sólo que las colecciones pueden almacenar documentos con muy diferentes formatos, en lugar de estar sometidos a un esquema fijo). Se pueden crear índices para algunos atributos de los documentos, de modo que MongoDB mantendrá una estructura interna eficiente para el acceso a la información por los contenidos de estos atributos.

Escalabilidad

Como ya hemos dicho, MongoDB está pensado para cosas tanto grandes como pequeñas, pero cuando hablamos de escalabilidad es evidente que estamos hablando de cosas grandes. El límite teórico de tamaño de base de datos en MongoDB es de 128TB (sin usar journaling) pero aunque tengamos capacidad de almacenamiento suficiente para albergar bases de datos de este tamaño, seguiremos teniendo un problema con el número de peticiones que un único servidor pueda servir (tanto en peticiones de lectura como de escritura). Por eso, MongoDB se pensó como un sistema escalable ( en teoría de la computación se define la escalabilidad como capacidad de un sistema para crecer sin aumentar su complejidad ni disminuir su rendimiento). Para segurar la escalabilidad MongoDB ofrece dos mecanismos básicos, los ReplicaSet (RS) y el particionado (o Sharding). Vamos a ver una breve introducción a los dos conceptos.

ReplicaSet

Un réplica set está formado por varios nodos. Cada nodo se trata de una instancia diferente de MongoDB que generalmente se ejecutan en servidores separados para aumentar la tolerancia a fallos del sistema. Cada nodo del replica set contiene la misma información, y cada RS tiene, como mímimo, un nodo primario (PRIMARY) y puede tener entre 0 y 49 nodos secundarios (el límite de nodos por RS esta en 50, incluido el nodo primario).
El funcionamiento de las conexiones desde el punto de vista de las aplicaciones clientes es el siguiente. El cliente se conecta al clúster a través de un driver, y obtiene toda la información necesaria del clúster. El driver se encarga por sí mismo de balancear las lecturas entre los nodos del clúster, y de dirigir las escrituras al nodo primario. El nodo primario replica los datos que recibe en todos los nodos secundarios. Cada RS puede tener nodos en estado HIDDEN, que serán ignorados por el driver tanto para las escrituras como para las lecturas. El uso típico de los nodos HIDDEN puede ser para realizar trabajos en paralelo a los sistemas de producción sin interferir en el rendimiento de los mismos, por ejemplo, para realizar los backups, o para procesos ETL en sistemas de BI.

Particionado

El particionado consiste en implementar varios RS, cada uno de ellos con una partición diferente de las colecciones particionadas, convirtiendo MongoDB en realidad en un sistema distribuido (SD), con los problemas típicos de los SD (necesitamos un sistema para administrar la información propia del clústed particionado, es decir, qué nodo es el primario en cada partición, donde tengo que escribir un documento en concreto, cómo ejecutamos consultas cuyos datos están particionados, …). Para solucionar estos problemas se introducen dos conceptos.

  1. configServer : Se trata de otro RS (y por lo tanto un conjunto de nodos replicados entre sí) que contiene todos los datos de configuración del cluster.
  2. mongos (o queryRouter): Se trata de una instancia diferente que en realidad no contiene datos ni información alguna. Sencillamente se conecta a los servidores de configuración (al replica set configServer), obtiene la información necesaria para encaminar las consultas que se realizan desde los clientes a través de los diferentes nodos.

Con toda esta información, podemos dibujar un esquema típico de arquitectura de MongoDB como queda reflejado en la siguiente figura.

ShardedClusterSample.png

Sí, lo sé, 12 servidores. Son muchos servidores para un simple sharded clúster ¿no? Ya os he dicho que MongoDB está pensado para cosas grandes. Para realizar las instalaciones usaremos puertos diferentes en menos servidores, para simplificar las cosas.

¿En qué situaciones es recomendable usar MongoDB y en cuáles no?

A pesar de que MongoDB está pensado para cosas grandes, en realidad se puede usar en cualquier aplicación que necesite almacenar datos semi estructurados, y ese es el caso de las típicas aplicaciones CRUD o de muchos de los desarrollos web actuales.

Eso sí, aunque las colecciones de MongoDB no necesitan definir une esquema, es importante que diseñemos nuestra aplicación para seguir uno. Tendremos que pensar si necesitamos normalizar los datos, denormalizarlos o utilizar una aproximación híbrida. Estas decisiones pueden afectar al rendimiento de nuestra aplicación. En definitiva el esquema lo definen las consultas que vayamos a realizar con más frecuencia.

Como ya hemos visto MongoDB será especialmente útil en aquellos entornos en los que la escalabilidad sea un requisito. Con sus opciones de replicación y sharding, que son muy sencillas de configurar, podemos conseguir un sistema que escale horizontalmente sin demasiados problemas.

En cambio, hay situaciones en las que no es recomendable usar MongoDB. MongoDB carece de transacciones. El concepto de operación atómica sólo se asegura a nivel de documento, por lo tanto, si las transacciones son algo indispensable en nuestro desarrollo, deberemos pensar en otro sistema.

Otra carencia que tiene MongoDB son los joins. Si queremos consultar datos relacionados entre sí en diferentes colecciones no tendremos más remedio que realizar más de una consulta (tantas como joins queramos anidar).

 

Hemos visto una introducción rápida a qué es MongoDB y cuándo usarlo. Para más información, os recomiendo que consultéis la web que más información contiene sobre MongoDB, que como no, es su propia página de documentación. Además, MongoDB ofrece en la web MongoDB University cursos gratuitos sumamente completos, desde un nivel de iniciación hasta los niveles más avanzados, tanto para programadores como para administradores.

Seguiremos en la siguiente entrada viendo cómo realizar la instalación de una única instancia.

Saludos

 

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s