Terminando de definir las necesidades

Como vimos en el el artículo anterior tenemos claro que necesitamos:

• Una base orientada a documentos o tabular (múltiples columnas para un registro)
• Con capacidad para realizar funciones MapReduce
• Open Source
• Estable
• con soporte profesional

Y que NO necesitamos transacciones.

Habría que añadir también que tampoco necesitamos:

• replicación maestro-maestro (los proxies en distintas zonas geográficas gestionan los accesos de distintos usuarios)
• soporte para múltiples versiones
• consistencia real de los datos (no trabajamos con datos críticos ni datos que vayan a sufrir modificaciones)

Comparando las bases de datos NoSQL que hemos estudiado

Si descartamos las bases de datos que mantienen los datos en memoria, las que gestinan pares de clave-valor y grafos de las que hemos comentado nos quedamos con las siguientes opciones: MongoDB, CouchDB, Cassandra, HBase y Riak.

A lo indicado en la sección “Lecturas recomendadas antes de tomar una decisión” del artículo anterior, yo añado las siguientes reflexiones de mi cosecha sobre cada uno de los productos citados:

MongoDB

Puntos a favor:

• Es una base orientada a documentos, por tanto muy flexible a la hora de estructurar los datos (usa JSON)
• Tiene un lenguaje de queries dinámicas
• Tiene soporte profesional por parte de la empresa que desarrolló el producto, 10gen
• Tiene una amplia comunidad y son muy activos (están presentes en conferencias, yo mismo he visto un puesto suyo en el FOSDEM en Bruselas este año)
• Tiene soporte de MapReduce
• Es un producto maduro
• Tiene muy buena documentación en su web
• Drivers nativos para múltiples lenguajes propios de 10gen

Puntos en contra:

• Aunque no es complicado ponerlo a andar tampoco es un producto sencillo. Una instalación de MongoDB cuenta con varios tipos de servicios: los servidores de datos, los servidores de configuración, los servidores que enrutan las peticiones de los clientes y un servidor para MapReduce
• La replicación es sólo maestro-esclavo

CouchDB

Puntos a favor:

• Es una base orientada a documentos, muy flexible a la hora de estructurar los datos
• Sistema de versiones concurrente (una modificación de un dato no bloquea lecturas)
• Tiene replicación maestro-maestro

Puntos en contra:

• Los datos no se modifican, se añade una nueva versión, con lo que ocupan mucho y es necesario lanzar procesos batch de compactación
• Está un poco “verde”. La última versión es la 1.2.0 y tiene cambios que la hacen incompatible con la anterior
• Para explotar los datos hay que definir vistas, con lo que las consultas han de estar definidas de antemano (la explotación de los datos es poco flexible)

Riak

Puntos a favor:

• Es una base híbrida, almacena documentos y pares clave-valor
• No hay controlador central y por tanto no hay un único punto de fallo
• Tiene soporte para MapReduce
• Tiene soporte de transacciones

Puntos en contra:

• Tiene dos versiones, una open source y otra de pago con replicación multi-sitio

Cassandra

Puntos a favor:

• Es un proyecto Apache, considerado de máxima importancia.
• Es una base tabular (puede almacenar varias columnas por clave) lo que la hace flexible y válida para nuestro caso
• Pensado para situaciones en las que hay más escrituras que lecturas. Escala muy bien en estos casos (ideal para análisis de logs)
• Pensado para replicar datos entre múltiples centros de datos
• Proporciona integración con Hadoop para MapReduce
• El nivel de consistencia es configurable
• No hay controlador central y por tanto no hay un único punto de fallo
• Tiene soporte para transacciones (con ZooKeeper)

Puntos en contra:

• Quizás demasiado complejo

HBase

Puntos a favor:

• Es un proyecto Apache (subproyecto de Hadoop)
• Similar a Cassandra (puede almacenar varias columnas por clave)
• Proporciona integración con Hadoop para MapReduce

Puntos en contra:

• Demasiado complejo

“And the Winner is” ….. ¡MongoDB!

Después de todo lo leído me decanto por MongoDB, fundamentalmente porque:

• cumple todos los requisitos que indicamos al principio: orientada a documentos, con MapReduce, Open Source, estable y con soporte
• el soporte lo da la misma empresa que desarrolló el producto, 10gen, con lo cual está claro que lo conocen
• tiene una web muy cuidada y con amplia documentación
• son muy activos, están presentes en múltiples conferencias y charlas (como se puede ver en el artículo eventos de su web)
• comparativamente no parece un producto demasiado complejo

Como va a ser el primer despliegue de una base de datos NoSQL en la empresa y realizada por alguien sin experiencia previa, considero la existencia de documentación y guías completas vital.

En particular y para el uso que le vamos a dar destacaría los siguientes artículos de su web

• MongoDB is Fantastic for Logging
• Using MongoDB for Real-time Analytics

Sin olvidar echar un vistazo a la lista de presentaciones que tienen disponibles.

Y a partir de aquí ….

Una vez escogida el sistema de gestión NoSQL a partir de aquí lo que tendremos que hacer es

1. Instalar y configurar MongoDB
2. Diseñar el esquema de la base de datos para la gestión de logs de acceso a Internet
3. Desarrollar código que nos permita usar la base de datos desde MongoDB o MySQL de forma transparente a las aplicaciones
4. Realizar unos cuantos tests de rendimiento para verificar que MongoDB no sólo es más flexible que MySQL, si no que también una mejor idea desde un punto de vista de rendimiento

Hay otras alternativas que parecen igualmente interesantes y válidas como Cassandra o Riak, y que podrían quedar para un estudio posterior.

Ver también

El resto de esta serie de artículos

• Buscando una solución NoSQL para el análisis de logs (1 de 4)
• Buscando una solución NoSQL para el análisis de logs (2 de 4)
• Buscando una solución NoSQL para el análisis de logs (3 de 4)