Mostrando entradas con la etiqueta NoSQL. Mostrar todas las entradas
Mostrando entradas con la etiqueta NoSQL. Mostrar todas las entradas

jueves, 16 de junio de 2011

Entonces... ¿Hadoop no es nada?

Efectivamente, podríamos decir que Hadoop, en sí, no es nada. No es nada al menos en el sentido en el que , equivocadamente, mucha gente piensa.

Hay una creencia bastante extendida de que Hadoop es una base de datos distribuida o una base de datos NoSQL (ver post Bases de datos NoSQL... ). No, no es eso. Veamos lo que sí es.

Hay infinidad de documentación sobre Hadoop en Internet, así que tampoco pretendo entrar demasiado en detalle, además, necesitaría más tiempo y más de un post. No es el objetivo.

Para empezar, podemos echar un vistazo a la página web de Hadoop (http://hadoop.apache.org/), donde ya nos deja claras las cosas desde el principio:
"La librería de software Apache Hadoop, es un framework que permite el procesamiento distribuido de grandes cantidades de datos a través de clusters de ordenadores, usando un modelo simple de programación"
Librería, Framework,...Vaya, que decepción, así que ¿para usarlo hay que programar?. Pues si, en efecto. Es lo mismo que si instalamos en nuestro ordenador el ".Net Framework 4.0". Nos da la herramienta, pero la casa la tenemos que construir nosotros.

El proyecto Apache Hadoop, consta de tres subproyectos: Hadoop Common, Hadoop HDFS y Hadoop MapReduce, que combinados de forma conjunta, nos proporcionan las herramientas necesarias para construir un sistema que, como dice el enunciado, nos permita procesar grandes cantidades de datos, en un modelo distribuido, con alta disponibilidad, usando un hardware barato y con un alto rendimiento. La verdad es que dicho así, suena muy bien.

Ya veremos más adelante lo que son Common, HDFS y MapReduce. De momento, vamos a centrarnos en las cinco características, que nos han llamado la atención:

Procesamiento de grandes cantidades de datos
Hadoop sirve para procesar GRANDES cantidades de datos, y digo GRANDES con mayúsculas, porque estoy hablando (es un decir) de muchos miles de millones de datos. Si no es el caso, pensemos en otra solución (aunque puedes seguir leyendo el post hasta el final).

Modelo distribuido
El que sea un modelo distribuido, no es solo una ventaja, es también una necesidad. Excepto si es para desarrollar, no sirve de nada montar un sistema basado en Hadoop con una sola máquina. Se puede hacer, pero como digo, solo para desarrollar o "cacharrear" con ello. De hecho, necesitaríamos al menos dos. (Cloudera proporciona una distribución bastante estable y sencilla, que permite simular un cluster en una sola máquina y se instala en unos pocos minutos).

Hasta aquí, lo que parecían ventajas, alguien lo puede ver como inconvenientes. Pero bueno, sigamos...

Alta disponibilidad
Esto está muy bien. Si se rompe una máquina, el sistema sigue funcionando. No perdemos los datos y el sistema se recompone para repartir la carga entre los nodos restantes. Evidentemente, cuantos más nodos tenga nuestro cluster, más protegidos estaremos frente al fallo de alguno de ellos.

Que el sistema siga funcionando pese a la caída de un nodo, no es nada especial, pero el que el sistema redistribuya la carga, si es una importante ventaja.

Hardware barato
Este es otro punto interesante. No necesitamos grandes máquinas, prácticamente cualquier PC con disco duro, procesador y memoria, nos sirve para incorporarlo al cluster, además no tienen por que ser todos los nodos iguales. Cada nodo soportará una carga proporcional a los recursos de los que dispone.

Para que no todo sean ventajas, hay que decir que en el apartado de networking, si es preciso gastarse unos euros. Montar un cluster de un par de docenas de nodos, con PC's de 300€, está muy bien, pero si los unimos con un switch de 10MB, por muchos nodos que añadamos, el rendimiento no mejorará.


Alto rendimiento
En este caso, la potencia no nos la proporciona Hadoop sino la acumulación de nodos al cluster, cuantos más nodos, más rendimiento. Obvio ¿no?.

Dado que podemos utilizar un hardware barato, incrementar la potencia de nuestro cluster, no requerirá una fuerte inversión, además, el escalado horizontal es prácticamente ilimitado.

Ya ha quedado claro al principio, que Hadoop es una herramienta, o más bien un conjunto de ellas:

Hadoop Commons: Son un conjunto de librerías y utilidades sobre las que se soportan el resto de subproyectos. Dan soporte para interactuar con el sistema de archivos distribuidos, gestionar el control de acceso a los nodos, colas de trabajos, etc..

HDFS (Hadoop Distributed File System): Es el sistema de almacenamiento distribuido en el que se soportan las implementaciones de Hadoop. Consta de un nodo primario o "NameNode" que  controla los "DataNodes", que son cada uno de los nodos donde finalmente se almacenan los datos.


MapReduce: Es en si el framework que nos permite desarrollar las aplicaciones que son capaces de procesar en paralelo los datos suministrados.

Los trabajos MapReduce se basan en la separación de los datos de entrada (tareas Map), que son enviados como entrada a las tareas de agregación o combinado (tareas Reduce). Que lío ¿no?.

La verdad es que puede parecer complicado pero en realidad es más simple de lo que parece. Pongamos el ejemplo tonto, que no tiene utilidad práctica, pero si didáctica:

Supongamos que tenemos un fichero de texto con varias líneas y queremos contar las palabras distintas que hay en el texto y saber cuantas veces aparece cada una de ellas.

El primer grupo de tareas Map, recibiría cada una de las líneas del fichero y se encargaría de separar cada línea en sus diferentes palabras. Estas palabras se pasarían a las tareas Reduce, que se encargarían de contar las apariciones de cada palabra, así en diferentes niveles de agrupación (tareas Reduce encadenadas), hasta conseguir el resultado final.

En realidad se trata de ir separando los datos hasta el nivel de granularidad adecuado y después agruparlos para conseguir la segmentación deseada.

¿El truco? tareas sencillas que realizan solo una parte del proceso. Si tenemos muchas de estas y trabajando todas a la vez, tenemos un resultado espectacular.

Y esto, a mi ¿para que me sirve?. Esta es la pregunta del millón.

Lo primero que hay que tener claro es que Hadoop no es la panacea para resolver los problemas de almacenamiento, disponibilidad, sustitución de bases de datos, etc.. Hadoop es bueno, pero solo para resolver unas problemáticas muy concretas.

Quizá, para no perder el tiempo, lo primero que se debería hacer es conocer "Que NO es Hadoop". Para empezar, recomiendo la propia Wiki de Hadoop.

Hadoop es una herramienta excepcional, pero solo si se utiliza para el propósito adecuado.

Aunque pueda parecer a simple vista algo muy complicado de poner en marcha, en realidad no lo es tanto. La instalación de los componentes es relativamente sencilla (Proveedores como Amazon, tienen disponibles nodos preinstalados listos para usar). En realidad, solo nos tenemos que preocupar de desarrollar nuestros programas MapReduce y para ello podemos utilizar varios lenguajes como Java, C++, Python, etc., así que alguno de ellos nos resultará más próximo y será más fácil comenzar.

sábado, 12 de marzo de 2011

Bases de datos NoSQL, una consecuencia más que una evolución

Desde hace ya unos años, las bases de datos NoSQL se han convertido en una realidad y una herramienta imprescindible para abordar ciertos tipos de problemáticas.

El que sea un modelo utilizado por muchas de las empresas de más éxito en Internet como Google, Twitter, Facebook, LinkedIn, Amazon, etc., le ha dado un aura de moda y algunas empresas se plantean su uso dejándose llevar por la novedad más que por la necesidad.

Tal está siendo el éxito que está teniendo este movimiento, que algunos se apresuran a augurar el fin de las bases de datos relacionales; posiblemente sea el mismo colectivo que pronosticó el inminente fin del Cobol hace 15 años.

El nacimiento
El término NoSQL (  Not only SQL) fue acuñado a finales de los 90 para referirse a las bases de datos distribuidas Open Source no relacionales.

Aunque no es el único ni quizá el más importante, el más conocido y llamativo es que para acceder a los datos, no se utiliza SQL sino que cada una de ellas aporta un API propietario para acceder a los datos, aunque algunas de ellas implementan un lenguaje próximo al SQL.

Con la explosión de Internet, sobre todo la web, en los 90, los requerimientos para gestionar grandes volúmenes de información, se multiplican de forma exponencial, ahora los usuarios de un sistema se miden en millones, el almacenamiento se mide en petabytes, etc. Los sistemas tradicionales no son operativos en este contexto, el concepto “distribuido” cobra un nuevo sentido.

Aunque si somos estrictos, dado que las bases de datos NoSQL serían Open Source, deberíamos excluir las comerciales, pero llevan en el mercado ya varios años soluciones “parecidas”, con diferentes grados de éxito, como podrían ser Lotus-IBM Domino, Tamino de Software AG, etc., pero digo parecidas porque, entre otras cosas, no son soluciones válidas para un modelo en Internet a gran escala.

El teorema CAP
El teorema de Brewer o CAP, dice que dado un sistema distribuido, no es posible asegurar las siguientes premisas de forma simultánea, sino solamente dos de ellas:
-          Consistencia (Consistency): Todos los nodos ven los mismos datos al mismo tiempo.
-          Disponibilidad (Availability): El fallo de uno o más nodos, no impide a los demás seguir funcionando.
-          Tolerancia al particionamiento (Partition Tolerance): El sistema continúa funcionando a pesar de pérdidas en los mensajes.

En el caso de los RDBMS, se le da más importancia a la [C] Consistencia y a la [A] Disponibilidad, que a la [P]Tolerancia al Particionamiento, mientras que en las B.D. NoSQL se da más importancia a la [P]Tolerancia al Particionamiento y en algunas ocasiones a la [A]Disponibilidad.

En este contexto, aparece el concepto BASE (Basically Available, Soft-state, Eventually consistent), como contraposición al modelo tradicional  ACID (Atomicity, Consistency, Isolation y Durability). Ahora las prioridades son otras.

Tipos de bases de datos NoSQL
Una clasificación de estas bases de datos, podría ser:
-          Clave-Valor, como por ejemplo: Dynamo (Amazon), Redis, MemcacheBD, Riak, Tokyo Cabinet o Voldemort (LinkedIn)
-          Orientadas a documentos, como por ejemplo: MongoDB o CouchDB
-          Orientadas a columnas, como por ejemplo: BigTable (Google), HBase (Hadoop), Cassandra (Facebook, Twitter) o Hypertable
-          En grafo, como por ejemplo: InfoGrid o Neo4j
-          Orientadas a objetos, como por ejemplo: db4o, Objectivity/DB o Versant

Muchas de estas bases de datos son variaciones o combinaciones de otras anteriores, dando mayor importancia a una u otra característica para obtener una solución más efectiva del problema que pretenden resolver. Un ejemplo claro de esto es Cassandra, desarrollada inicialmente por Facebook en 2008 y que la describen como un modelo de datos BigTable corriendo sobre una infraestructura de tipo Dynamo.

¿Hacia donde vamos?
Como ya decía al principio, este movimiento no implica el fin del modelo relacional ni mucho menos, de hecho, el uso de los RDBMS, sigue siendo la opción idónea para abordar muchos de los modelos de negocio.

Con la evolución y la expansión del Cloud Computing, sobre todo en su vertiente SaaS, muchos de los sistemas que soporten el negocio de las empresas en la nube, requerirán del uso de estas bases de datos NoSQL.

Los sistemas OLTP seguirán decantándose por los modelos relacionales, mientras que los OLAP, se decantarán en muchos casos por las NoSQL. Seguramente, el modelo que triunfará, será un modelo mixto.

Cuando tenemos que procesar diariamente miles de millones de peticiones, tenemos que tener en cuenta, que no todos los RDBMS son capaces de soportarlo, que el almacenamiento cobra una especial relevancia, que el escalado horizontal no siempre está disponible y que el escalado vertical de los sistemas, tiene un límite, además de un coste elevado.

Por lo general, las implementaciones de los sistemas basados en bases de datos NoSQL, permiten el uso de “Commodity Hardware” (hardware simple y barato) y un escalado horizontal prácticamente sin límites.