viernes, 27 de noviembre de 2009

Cassandra DB: ¿Qué tienen Facebook, Twitter y Digg en común?

Cassandra DB: ¿Qué tienen Facebook, Twitter y Digg en común?
Conferencia Rails 2009: Pablo Delgado

Probablemente a la charla a la que le he sacado mayor partido ha sido a la de Pablo Delgado sobre Cassandra, el motor de bases de datos key-value desarrollado por dos ingenieros de Facebook para gestionar su ingente cantidad de datos repartidos entre 140 servidores.

De entre la gran cantidad de cosas que ofrece podemos resaltar que almacena los registros de forma continua y ordenados en column families, de forma que se consigue aunar las ventajas de acceso del almacenamiento por filas con el de columnas.

Este modelo de datos te permite definir supercolumns, es decir, columnas de columnas, para guardar datos ordenados y simplificar búsquedas muy comunes, con un precio, eso sí, el de tener que saber a priori cual es esa búsqueda para poder almacenar los datos ordenados en base a las keys que nos interesen.

El balanceo entre consistencia y latencia es configurable según nos interese más integridad en nuestros datos o alto rendimiento en las peticiones, ¿qué quieres potenciar, rápidez o seguridad?

Pero lo que más me ha impresionado es su alta escalabilidad y la gestión distribuida de los datos entre servidores. Cassandra permite añadir nodos a la base de datos de forma horizontal, es decir, lo añado y se acopla, sin más, se añade un nodo al cluster y ya se encarga el sistema de replicar los datos y mantener la consistencia. Si pasa lo contrario, que quitamos o perdemos un nodo de un cluster también se recompone automáticamente para sostener la caída de ese servidor.

Consistent Hashing, así gestiona el uso de nodos para grabar u obtener datos y seleccionar el nodo que almacenará la información en primer lugar, para luego replicar los datos al resto de servidores. La idea consite en que se sitúan todos los nodos en el perímetro de una circunferencia en la que la posición la define un valor entre 0 y 1, y a partir del valor devuelto por una función que calcula valores en este rango, y que puede ser aleatoria o no, se decide que nodo va a atender la lectura o escritura solicitados. Una vez escrito el registro, el nodo se sincroniza con el siguiente, y éste a su vez con el siguiente, así hasta que todos han sido actualizados.

Si nos obsesiona la pérdida de datos en las escrituras podemos definir factores de replicación que indican el número de nodos que utilizaremos para grabar claves replicadas concurrentemente, esto nos permite sostener la caída de algún nodo que se ha modificado pero que no ha tenido tiempo de sincronizar sus actualizaciones con el siguiente, ya que existen otros que también almacenaron el dato que se evaporó con el servidor caído.

En esta línea también soporta autoreparado de datos inconsistentes tras una consulta. Esto es, devuelvo lo que me piden y aviso al resto para que me sincronicen, si el dato estaba mal se corrige, con lo que los datos más consultados siempre son consistentes.

En resumen, una herramienta poderosísima y OpenSource, no cabe duda de que hay que probarla.

2 comentarios:

Oliver Franco dijo...

Muy interesante este tema, puede resultar toda una revolución de la percepción actual de las BBDD relacionales. He visto que existe un movimiento denominado NoSQL que está ganando cada vez más adeptos.

Buena entrada Emilio!!

Emilio Medina dijo...

Mi impresión y la de la gente que ya las utiliza es que no van a reemplazar a las relacionales, al menos no lo van a hacer en determinado tipo de proyectos en los que las búsquedas masivas y no definidas con anterioridad son una constante. Como todo creo que solucionan problemas que surgen con las relacionales como la replicación de datos en varios servidores pero no las sustituyen, ¡al menos por ahora!