Introducción a bases de datos NoSQL (Not Only SQL)

2
27642

Introducción a bases de datos NoSQL (Not Only SQL) en Java.

Tutorial inspirado en el Speech de Spring Data de Coustin Leau @costinl en el SpringIO 2011

Introducción

A parte de las clásicas bases de datos SQL (RDBMS), aparecen y van tomando fuerza nuevos tipos de bases de datos.

Su mayor ventaja es que están preparados para ser muy rápidos. Mucho.

Según su tipo, cada una sigue una estrategia completamente diferente para persistir la información.

Cabe destacar que normalmente no sustituyen a la base de datos clásica SQL, sino que surgen por otra necesidad. Una necesidad de rendimiento extremo. Si se utilizan de una manera única, o se combinan con una base de datos SQL es una decisión de arquitectura del sistema.

Algunas de ellas pueden ser accedidas mediante SQL, pero normalmente no será así, puesto que cada una tendrá una API exclusiva.

Existen proyectos como Spring Data que pretenden abstraernos de dicha complejidad. Siendo posible cambiar de un tipo de base de datos a otra de una manera directa, según nos convenga.

Servidores SQL tradicionales

Como hemos visto en el tutorial de introducción a bases de datos SQL, las bases de datos SQL disponen la información representándola a modo de filas y columnas dentro de tablas. También relacionan la información mediante claves ajenas y son capaces de indexarla con índices y algunas características más.

Hasta no hace mucho, si un periódico, por ejemplo, tenía 1000 visitantes por segundo y su infraestructura no soportaba ese tráfico, se optaba por arquitecturas en las que cada X minutos, en vez de atender a las peticiones, se generaba un fichero html y éste era el que se despachaba mediante servidores apache básicos. Los cuales no tenían que acceder a bases de datos ni consumir tiempo de procesador ni memoria como lo haría un servidor web como Tomcat, PHP o .Net.

Hoy en día, empresas como Twitter, Facebook y similares tienen un tráfico millones de veces superior, tenemos aplicaciones RIA que son accedidas simultáneamente por infinidad de clientes de todo tipo, así que la tecnología existente se quedaba un poco corta. No porque no fuese capaz de hacerlo, sino porque lo hacía muy lentamente.

Las bases de datos NoSQL rompen con la barrera del rendimiento, según su tipo, su estrategia de ejecución es distinta, pero algunas de ellas como Redis funcionarán según nos interese en memoria, llevando un registro en el disco y periódicos snapshots de la información, o directamente en disco. En el caso de Redis podemos llegar a configurar qué parte de la memoria queremos que utilice, pudiendo incluso apagar el consumo de la misma para el proceso de datos.

Una comparación desafortunada podría ser que las bases de datos NoSQL son como un MemCaché para nuestra aplicación.

Algunas arquitecturas colocan una aplicación-bd(nosql)-bd(sql) de forma que la información es accedida increíblemente rápido.

Otro problema de los servidores tradicionales son el los límites de espacio y proceso que tienen, en el caso de NoSQL, según su tipo, el límite es el propio sistema operativo.

4 vertientes (por ahora)

Fuentes de Datos

Clave-Valor

Mapeo de Columnas

Documentos

Grafos

Redis HBase MongoDB Neo4j

¿Cómo funcionan?

Aunque variará según su tipo, podemos decir que el razonamiento general es que NO vamos a guardar la información en tablas y columnas.

La información se va a guardar de «otro» modo:

El caso de las de tipo Clave-Valor (tomemos Redis)

Dispondremos de un api que permita hacer PUT y GET, y la información estará condensada en una super lista en la que podemos tener índices (índices no de la manera que los entendemos en sql tradicional), y estos índices nos permitirán buscar entre nuestra información.

Esto permite variar la estructura de la información que guardo sin perder la agrupación de la misma, por ejemplo imaginemos que guardamos a un usuario y sus datos. Usaríamos su DNI como clave y el resto de sus datos como valores. En unos meses tenemos que cambiar la estructura de esos datos almacenados. Simplemente variaremos la información que guardamos en los nuevos usuarios, y podemos hacer un pequeño script que actualice los existentes, o simplemente tener en cuenta dichos cambios en el momento de la lectura. Pero como el rendimiento es tan extremadamente rápido nos será transparente.

El caso de las de tipo Orientado a Columnas (tomemos HBase)

Se almacena una clave y a esta de le asocia una supercolumna con nuestra información.

En el caso de las de tipo Documentos (tomemos MongoDB)

La información se almacena (explicado a grosso-modo) teniendo en cuenta la misma, mas una meta información que la encapsula y categoriza.

Suele utilizarse JSON o BSON como solución simple de almacenaje

Existe un tutorial muy bueno para empezar a trastear: MongoDB, primeros pasos»

En el caso de las de tipo Grafos (tomemos Neo4j)

La información se almacena partiéndola en trozos más básicos y estableciendo relaciones.

Este tipo de base de datos es capaz de obtener rendimientos altísimos en consultas sobre información relacionada, como los contactos de un usuario de linked-in o facebook, o los propios mensajes en twitter (como las búsquedas de retwitts o menciones).

En un modelo convencional SQL estas relaciones implicarían una grandísima cantidad de Joins que, según el volumen y la infraestructura, simplemente son inviables en términos de tiempo de espera.

El mundo actual

En un mundo en el que con el Cloud parecía que se iba a poder crecer horizontalmente tanto como se quisiera, que una pyme iba a poder convertirse en google según lo necesitara, a golpe de talonario según el consumo de espacio-memoria-tiempodecpu, aparece un rayo de luz para demostrarnos cómo, por software, podemos crecer verticalmente mucho más, cómo podemos pasar de atender cientos de conexiones a miles o millones.

Un ejemplo extremo de esto es Hadoop, que nos presentó también en el SpringIO 2011, Miguel Ángel Pastor Olivar – @miguelinlas3.

Hadoop NO es una base de datos NoSQL, pero es un buen ejemplo de uso de una. Hadoop utiliza la base de datos NoSQL HBase, que es de tipo «orientado a columnas».

Es un sistema para almacenar información y explotarla de manera brutal, pensado para manejar Petabytes y lo más sorprendente, hacerlo de forma distribuida, en hardware de consumo y siendo escalable dinámicamente añadiendo nodos en caliente.

No se me ocurre mejor demostración del rendimiento de las bases de datos NoSQL

¿Qué no debemos esperar de NoSQL por el momento?

Hay cientos de aplicaciones funcionando con bases de datos NoSQL, por ejemplo todas las de la plataforma GAE (Google App Engine). Pienso que podemos ver las bases de datos NoSQL como una caché persistente cojugable con bases de datos SQL tradicionales, según la topología lo exiga.

Como hemos visto las bases de datos NoSQL responden a unas necesidades de rendimiento concretas, aunque algunas son tan ligeras y livianas que pueden llegar a convertirse en algo de uso habitual.

Proyectos como Spring Data, aunque no sea la mejor comparación, parece que van a convertirse en nuestros «Hibernates» para NoSQL.

Si los chicos de Spring lo hacen bien, y parece que así está siendo, podremos tener una aplicación funcionando con un tipo de NoSQL y cambiarlo por otro según lo requiramos. Siempre que no nos salgamos de su Spring Data Object Mapper.

Tengo la sensación que este tipo de base de datos terminará reemplazando en parte a las convencionales, por ejemplo en el caso de las de tipo clave-valor para aplicaciones simples, todo dependerá de lo fácil que sean las apis y lo integradas que estén desde nuestro lenguaje de programación.

¿De dónde sale tanto rendimiento?

En una base de datos relacional, realizar una consulta implica: convertir, preparar, optimizar, procesar, leer del disco, ejecutar… hasta 9 pasos para traerse una simple query.

En NoSQL se evita hacer todo esto, puesto que cada runtime (según el tipo) se encarga de que mediante el api accedamos directamente a los datos.

Accediendo al más bajo nivel y teniendo lo que nos interesa en la memoria y no en el disco obtenemos tasas de rendimiento muy elevadas, sobre todo en volúmenes de datos grandes.

Lanzo una pregunta para dar una vuelta de tuerca más a este tema del rendimiento…

¿Qué será de nosotros con una base de datos NoSQL, por ejemplo Redis en discos de estado sólido? :O

Espero que os sea de utilidad a los que empezáis.

2 Comentarios

  1. Me ha gustado el articulo, hubiera estado bien que hablaras sobre el teorema de Brewer, necesario para saber cual bd es la mejor para las necesidades del proyecto.

    Gracias Jaime

Dejar respuesta

Please enter your comment!
Please enter your name here