Todos aman a Cassandra

Sus ojos te embrujarán

Sus ojos te embrujarán

Cassandra es el sistema de gestión de bases de datos distribuidas al que, parece ser, todos le tiran los tejos y con el que todos quieren tener un romance. La era de los sistemas de datos basados en SQL (como OracleSQL Server o MySQLparece que va caminando inexorablemente hacia su extinción, aunque esta afirmación no soy capaz de creérmela ni yo mismo. Sinceramente no pienso que las plataformas SQL relacionales vayan a desaparecer, pero sí estoy convencido de que los grandes generadores de tráfico de datos las dejarán atrás en un futuro próximo. 

Una base de datos distribuida es, en realidad, un conjunto de bases de datos relacionadas de manera lógica y repartidas en diferentes ubicaciones geográficas del planeta. Por supuesto, todas ellas están conectadas entre sí mediante redes de comunicaciones y comparten información general de los datos que albergan, aunque no todas guarden la misma información. La ventaja de estos procedimientos es que permiten diversificar el flujo de transacciones entre los diferentes nodos, liberando de cargas innecesarias al resto. 

Imaginemos, por poner un ejemplo, que disponemos de una base de datos relacional SQL clásica en la que existen diversas tablas con la información de alumnos y profesores. Si realizamos una consulta para extraer los datos de un alumno, la base de datos contestará sin ningún problema, aunque sólo haya necesitado acceder a la tabla de alumnos. Si lo que deseamos es averiguar qué profesor es el tutor de determinado alumno, la base de datos nuevamente responderá correctamente, aunque en este caso habrá de acceder a dos tablas relacionadas. En este segundo caso hemos aprovechado la capacidad del gestor de datos al 100%, sin embargo, en el primero de los casos, una base de datos que tiene dos tablas sólo ha necesitado abrir una de ellas, ergo estamos desperdiciando tiempo y recursos

Imaginemos ahora que montamos la misma estructura sobre un sistema de bases de datos distribuidas. Dividimos los datos en dos partes lógicas, esto es, alumnos y profesores. Cada parte se corresponderá con una base de datos independiente y alojada en un servidor dedicado. Nosotros estamos conectados directamente al nodo de alumnos, por ser el que más utilizamos, por lo que todas nuestras consultas se considerarán locales y sólo trabajará esa base de datos, sin necesidad de recurrir a la otra. Si en un momento dado necesitamos información sobre profesores, el propio nodo local de alumnos iniciará una transacción global para recuperar la información. 

En entornos de datos en los que las transacciones pueden ser, tranquilamente, varios billones al día, se hace necesaria la implementación de un sistema distribuido, porque resultaría una auténtica locura cargar a una sola base de datos con todo ese trabajo, aunque estuviera duplicada en varios servidores que se replicaran automáticamente. Digamos que es una forma de distribuir el trabajo; en lugar de hacerlo todo yo, yo me encargo de esto y tú de aquello, y cuando nos haga falta nos juntamos.

Y parece que Cassandra es la niña bonita con la que todos quieren bailar. Cassandra nació en las entrañas de Facebook, y fue creada precisamente para intentar solucionar los problemas de eficiencia de una red social que crecía de forma imparable y que cada vez necesitaba más recursos. Precisamente, el punto débil de las bases de datos relacionales es el consumo de recursos, y los principales interesados en reinventar y revolucionar son los grandes jugadores de Internet. 

Google ya había hecho algo parecido antes, un proyecto denominado BigTable que llevó a cabo para sus propias necesidades. Sin embargo, la empresa de la gran G cada vez se parece más a un monopolio de “lo gratis”, y, a pesar de hacer públicos muchos pormenores de su sistema, por motivos de competitividad mantiene en celoso secreto los detalles más importantes. La baza de Facebook fue liberar el código de Cassandra (en 2008) y ofrecerlo a la comunidad internauta para su uso y abuso. 

El proyecto Cassandra lo mantiene hoy día la Fundación Apache, y parece que resuelve a las mil maravillas los problemas de prestaciones y, sobre todo, de escalabilidad de anteriores sistemas. La característica más importante de este proyecto es que fue diseñado desde un principio para escalar de una manera natural y prácticamente automática. Hemos de pensar que empresas como Google o Facebook necesitan añadir cada cierto tiempo nuevas máquinas y nuevos servidores en tanto en cuanto crece la demanda de sus servicios. Cassandra permite escalar casi por si sola con el único hecho de agregar mas máquinas a un cluster. Es uno de los primeros sistemas de esta magnitud que escala de manera lineal, conforme se le agregan mas máquinas, y de una forma muy sencilla. La Fundación Apache asegura que ya existen instalaciones de hasta 150 máquinas en paralelo y 100 TB de datos en producción. 

Las bases de datos tradicionales tienen un tanto a su favor, y es que su estructura hace que los datos sean consistentes, es decir, cualquier usuario que acceda en cualquier momento dispondrá de la misma información. Cassandra funciona, por defecto, mediante un sistema distribuido de “modelo eventualmente consistente”, esto es, los cambios se van propagando poco a poco entre todos los nodos del cluster; si se produce una consulta, al usuario se le ofrece lo que haya en ese momento, mientras llegan las últimas actualizaciones. 

Este sistema es, por tanto, ideal para redes sociales como Facebook o motores de búsqueda como Google, ya que no importa si algunos usuarios reciben una actualización un poco después que otros, porque lo importante es que todos “eventualmente” tengan todas las actualizaciones. Obviamente este modelo no podría aplicarse a otros entornos, como por ejemplo el de las aplicaciones bancarias y financieras, ya que en estos casos todas las transacciones deben confirmarse y, además, han de ser consistentes al 100% en todo momento. 

A día de hoy, no sólo Facebook utiliza su Cassandra, empresas como Digg, Cisco, IBM, Cloudkick u Ooyala se sirven de ella para sus proyectos (muchos migraron de pataleta cuando Oracle adquirió MySQL). Incluso Twitter aseguró su intención de migrar a Cassandra en breve, pero de esto ya hace tiempo y parece que todavía el cambio no se ha hecho efectivo, porque la web del pajarito sigue fallando más que una escopeta de feria; no en vano toda su infraestructura se apoya sobre una base de datos MySQL, o sea que, para el meneo que tiene Twitter, sería como tirar de Access 97. 

¿Qué tendrá Cassandra que todos la aman?

Escribe tu comentario

eBook ‘retroPLOF!’

retroPLOF!

Especifica tu dirección de correo electrónico y pulsa 'Comprar ahora'. Puedes pagar con tu cuenta de PayPal o con cualquier tarjeta bancaria.

E-mail envío eBook:

Sigue teknoPLOF! vía…
 
RSS
Twitter
Facebook
Google
 
Ready Set Click!

Utilizamos cookies propias y de terceros para mejorar la experiencia de navegación. Más información.

ACEPTAR
Aviso de cookies