Cassandra DB: ¿Qué tienen Facebook, Twitter y Digg en común?
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.
entrada de Emilio Medina a las
4:40
2 comentarios
Enlaces a esta entrada
