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
3. Configurar los proxies (o añadir software específico) para almacenar los logs en la base de datos de MongoDB
4. Modificar la arquitectura de la aplicación que genera informes a partir de bases de datos MySQL para utilizar en su lugar MongoDB

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)

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

Después de mucho leer descripciones, comparativas, blogs de expertos que se han enfrentado a situaciones similares a la mía y que describen su experiencia llega un momento en que hay que decir ¡BASTA! y, con las ideas cada vez más claras en mi cabecita tomar una decisión sobre qué solución implementar. El tiempo dirá si la decisión es correcta o no. En cualquier caso habremos aprendido mucho por el camino.

Dado que mi experiencia con NoSQL hasta el momento es nula lo que aquí se describe no es el consejo de un consultor informático experto en estas lides, si no más bien como un resumen de todo el proceso de estudio, reflexión y elección de un camino a seguir. Con suerte a alguien le ahorrará unas cuantas días de trabajo :-).

Descripción del tipo de datos y el problema

Como dije en el artículo anterior va a ser el tipo de datos que manejemos, su estructura y la naturaleza del problema la que nos van a dirigir hacia uno u otro tipo de solución NoSQL.

La cuestión es que queremos gestionar los logs de acceso a Internet de salida por los proxys de la empresa para varias decenas de miles de usuarios. La salida se hace a través de varios proxys HTTP distintos y los usuarios se tienen que autentificar para utilizarlo. Ahora mismo en una base de datos MySQL (particionada verticalmente por mes) almacenamos los siguientes datos:

• Para cada acceso FTP: la IP interna desde la que se accede, fecha, hora, dominio, URI, tamaño y proxy
• Para cada acceso: la IP interna, el id de usuario, la fecha y hora de acceso, el método HTTP utilizado, el protocolo, el dominio, la URI, el código de retorno HTTP, el tamaño de la transferencia, el proxy desde el que se accede, la tasa de transferencia y un campo de categoría (que entiendo que es una categoría asignada automáticamente a la URL de acceso usando algún tipo de filtro externo)

A partir de estos datos se generan

• Estadísticas diarias del número de accesos por dominio de Internet
• Estadísticas mensuales por categoría de página, dominio de Internet y usuario del número de accesos y el volumen de datos transferidos

Con lo cual vemos lo siguiente:

• el tipo de datos está estructurado en registros, sin relación entre ellos (cada uno de estos cuatro elementos se almacenan en tablas distintas)
• cada acceso se almacena en una tabla a modo de log que crece indefinidamente
• los accesos a la base de datos son de escritura en su gran mayoría
• cada acceso implica una modificación en los valores estadísticos, que se llevan por día para cada dominio de Internet y por mes para cada dominio de Internet, categoría de página y usuario.

Las consultas podríamos definirlas de antemano, ya que las estadísticas son generadas por alguna aplicación y para obtener resultados muy concretos. Podríamos definir un listado de informes a obtener o, tal y como yo prefiero, utilizar una solución NoSQL que nos permite lanzar queries a la base de datos con más flexibilidad.

Viendo esto ya podemos sacar algunas conclusiones que nos permitirán descartar algunas opciones

• Los datos son registros con varios campos, con lo que necesitaremos una base orientada a documentos o tabular (múltiples columnas para un registro)
• No necesitamos transacciones (los datos se van a ir añadiendo uno detrás de otro, de forma aislada)
• Sí necesitamos realizar funciones MapReduce. Cada acceso genera un valor que tendrá que ser tratado para obtener estadísticas resumen por dominio, categoría y usuario. Y en el tiempo se obtendrán resúmenes estadísticas por día y mes.
• Como requisitos añadidos tenemos que la solución:
  • ha de ser Open Source
  • lista para entornos de producción (estable)
  • con soporte profesional

No está mal.

Lecturas recomendadas antes de tomar una decisión

Para empezar de lo leído destacaría los siguientes enlaces:

• Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Membase vs Neo4j comparison del blog de Kristóf Kovács
• La serie de artículos sobre el tema del blog de Monitis
  • Picking the Right NoSQL Database Tool del blog de Monitis
  • NoSQL Databases – A Look at Apache Cassandra
  • The NoSQL Databases – A Look at HBase
  • A Look at Some NoSQL Databases – MongoDB, Redis and Basho Riak
  • An Overview of Riak: an Open Source NoSQL Database
  • Picking the Right NoSQL Database, Part 4 – CouchDB and Membase
• Consistency Models in Non-Relational Databases de Guy Harrison. Una muy buena explicación del Teorema CAP, del concepto Consistencia eventual y de cómo estos problemas de consistencia son tratados en sistemas distribuídos.

Naturalmente la Wikipedia (en inglés) es tu amiga. Las descripciones para estos productos (algunas editadas y mejoradas por mí durante este estudio) están llenas de referencias muy útiles

El apéndice del libro de O’Reilly Cassandra, The Definite Guide incluye también una muy buena descripción del panorama NoSQL.

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 (4 de 4)

¡¡¡¡AAAaaaarghh!!!! ¡Hay demasiadas opciones!

Bueno, bueno, bueno ….

Llevo unas cuantas horas (mas bien días) leyendo sobre el tema y lo primero que llama la atención es la cantidad de opciones distintas de sistemas de administración de bases de datos NoSQL que hay disponibles en el mundo Open Source. Si citamos las más conocidas tenemos: MongoDB, CouchDB, Cassandra, Membase, Redis, Riak, Neo4J, FlockDB y HBase, entre otras.

Lo primero que recomendaría sería dar una lectura rápida al artículo NoSQL de la wikipedia en inglés (con aportaciones del menda lerenda ;-)) y el primer artículo de la serie Picking the Right NoSQL Database Tool.

Un resumen rápido sería que según la manera de almacenar los datos las bases de datos NoSQL se dividen en …

Orientadas a documentos

Como MongoDB y CouchDB. Almacenan los datos en formatos estructurados (registros) como JSON.

Ejemplo de documento en JSON

Clave-Valor

Como Cassandra, Membase, Redis o Riak. Almacenan los datos en pares clave-valor (un valor podría ser un objeto)

de Grafos

Como Neo4J y FlockDB. Almacenan los elementos y las relaciones entre ellos con un estilo de grafo (para redes sociales, redes de transporte, mapas de carreteras, topologías de red, por ejemplo)

Tabulares

Como Cassandra o HBase. Almacenan los datos en filas, con varias columnas que corresponden a una clave, con un resultado similar a una tabla

Preguntas que debemos hacernos

Al final la elección de una u otra opción va a depender fundamentalmente del tipo de datos que manejemos y de la naturaleza del problema que queramos solucionar. No hay una base de datos NoSQL “tope de gama”, ni una o dos soluciones que podamos emplear siempre. Según la naturaleza de lo que queramos soluciones usaremos una u otra, o incluso varias simultáneamente.

Y desde luego, una solución NoSQL no sustituye a una base de datos relacional, la complementa. A menos, claro, que estemos usando una base SQL para el problema equivocado.

Deberíamos poder responder a las siguientes preguntas antes de elegir una opción:

• ¿Qué tipos de datos manejamos? ¿Arrays asociativos, pares de clave-valor, datos estructurados (XML o similar)?
• ¿Necesitamos transacciones?
• ¿Necesitamos usar MapReduce?

Y al revisar las distintas opciones:

• ¿La última versión está considerada estable?
• ¿Tiene soporte comercial?
• ¿Cuál es la curva de aprendizaje? ¿Dispone de documentación y/o de una comunidad activa?

Enlaces interesantes

• Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Membase vs Neo4j comparison del blog de Kristóf Kovács
• Picking the Right NoSQL Database Tool del blog de Monitis
• Consistency Models in Non-Relational Databases de Guy Harrison. Una muy buena explicación del Teorema CAP, del concepto Consistencia eventual y de cómo estos problemas de consistencia son tratados en sistemas distribuídos.

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 (3 de 4)
• Buscando una solución NoSQL para el análisis de logs (4 de 4)

Introducción y planteamiento inicial

En la empresilla familiar en la que trabajo me han encargado hacer un estudio sobre las tecnologías NoSQL y su posible utilidad para nosotros.

En un resumen rápido de 30 segundos podemos decir que los servidores de bases de datos NoSQL son utilizados cuando trabajamos con datos que no requieren tener una estructura que siga un modelo relacional “clásico”. Puede haber una estructura, pero está es mínima y en general lo que nos preocupa es la capacidad de almacenado y recuperación de una cantidad masiva de datos, y no tanto el establecimiento de relaciones entre distintos elementos.

Por ejemplo, queremos almacenar millones de pares clave-valor en uno o varios arrays asociativos enooormes o queremos almacenar millones de registros de datos. Ésto es particularmente útil para hacer análisis estadísticos o almacenar listados de elementos de longitud creciente (pensemos en los post de una cuenta en Twitter o en un registro de los accesos a Internet de los usuarios).

Los casos de uso que tenemos ahora en los que podríamos aplicar este tipo de soluciones serían los dos siguientes:

Análisis de logs de acceso a Internet

Ahora mismo el almacenado de los logs de acceso se hace en tablas MySQL. Estamos hablando de varias decenas de miles de usuarios con acceso a Internet y unos logs que registran cada URL y el tamaño de la descarga. Como se generan varias Gigabytes diarios lo que se hace es almacenar los logs en distintas tablas particionándolas verticalmente por mes (una tabla para Enero, otra para Febrero, etc …)

Análisis de logs de servidores Unix repartidos geográficamente

Usados para la comunicación con las oficinas comerciales, estaríamos hablando de los logs de los distintos servicios (FTP, SSH, Apache, MySQL, servicios de transferencia de archivos desarrollados por la empresa …) de unos 1000 servidores Linux

Centrándonos en el problema

Para el resto del análisis vamos a centrarnos en el primero de los problemas, el almacenamiento y análisis eficiente de los logs de las comunicaciones hechas por los empleados (varias decenas de miles) con acceso a Internet.

Lo que está claro por el momento es que en el momento en el que se decide particionar las tablas por meses (decisión que se ha tomado por cuestiones de volumen) se nos complican bastante las consultas ya que si queremos obtener estadísticas de uso de más de un mes tendremos que acceder a varios tablas.

El problema al que nos enfrentamos es cómo sustituir MySQL, solución aparentemente poco apropiada para este caso, por una alternativa NoSQL, que entendemos que nos dará mayor rendimiento para realizar estadísticas e informes basadas en los análisis de logs, con registros que incluirán datos como:

• Fecha y hora de acceso
• Usuario que accede
• URL visitada
• Tamaño en bytes de la descarga realizada

Las preguntas que queremos responder son del siguiente tipo:

• ¿Cuáles son las páginas más visitadas?
• ¿Y las más visitadas por mes? ¿La última semana? ¿Por departamento?
• ¿Qué usuarios pasan más tiempo en Internet?
• ¿Cuáles son los 100 usuarios cuyo volumen de tráfico es mayor?
• ¿Cuál es la media diario del volumen de tráfico desde la red de la empresa hacia Internet?

Ver también

El resto de esta serie de artículos

• 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)
• Buscando una solución NoSQL para el análisis de logs (4 de 4)

Hace unas semanas me tocó hacer varios scripts en Python (pronunciado Paaaaiiiton !! :-)). Total, que buscando alguna documentación para aprender a programar en este lenguaje encontré estos dos documentos en PDF, que recomiendo:

• Guía de aprendizaje de Python, traducción al español de casi todos los capítulos del tutorial incluido en la documentación oficial
• Python para todos, un libro en PDF de descarga libre y aparentemente bastante completo

Me he leído el primero y es una manera sencilla y clara de introducirse en Python. Faltan los capítulos 10 y 11 de la documentación original en inglés (“brief tour of the Standard Library”), a la que es recomendable echarle un vistazo ya que son librerías que se acaban usando.

Para trabajar con XML aquí hay una relación de las librerías disponibles en Python. La más recomendada es lxml, una librería compatible con ElementTree (ElementTree es una API fácil y “modelllna” para trabajar con ficheros XML). Lxml es una librería que usa las librerías del sistema libxml2 y libxslt.

En resumen, que en mi opinión Python es un lenguaje de script completo, sencillo y muy elegante, más simple y facil de usar que Perl, por ejemplo.

Es un lenguaje orientado a objetos, con muchos módulos para diferentes tareas y que lo convierte en una alternativa muy interesante. De hecho para hacer scripts para mí ahora sería la primera opción, está en cualquier sistema Unix (al igual que Perl, cualquier sistema Unix incluye un intérprete de Python) y es fácil y muy potente.

Vamos, que antes estaba enamorado de Perl y desde hace unas semanas le pongo los cuernos a la menor oportunidad :-)