Desde que Twitter mencionó el nombre de la sacerdotisa que predijo la caida de Troya, todas las miradas apuntaron a una nueva tecnología. Se presentaba como el futuro de las bases de datos, solucionaría el problema de FAIL WHALE y de camino aprenderíamos cosas nuevas y divertidas, cuando se les pasó la borrachera decidieron utilizarlo sólo para las futuras herramientas de analytics que preparan, así que por el momento seguimos con nuestras herramientas de toda la vida, MySQL y las bases de datos relacionales la solución standard para el almacenamiento y recuperación de datos.

¿Donde está el problema entonces?

Las bases de datos relaciones se fundamentan en los principios ACID; Atomicity, Consistency, Isolation y Durability. En la entrada de la wikipedia explican estos conceptos con exquisita claridad, el quiz llega cuando las aplicaciones web actuales con encajan en esos esquemas. Tienen nuevas necesidades de las bases de datos, imagina el procesador de un Eurofighter y de un microondas, el tiempo de respuesta no es tan crítico en el segundo ¿verdad? además no es necesario que funcione a 0.2 atmosferas o -50ºC. Aquí pasa lo mismo, las nuevas estructuras de computación distribuida obligan a reconsiderar algunas de las herramientas al subirnos a la nube.

¿Por qué Cassandra?

Básicamente, porque es descentralizado, tolerante a fallas, elástico/escalable via Amazon EC2, con alta disponibilidad y probado en el campo de batalla por Facebook (su gran impulsor), Digg y Twitter

Nuevos paradigmas de base de datos

Cassandra se basa en nuevo paradigma conocido como NoSQL (Not only SQL) del que podremos encontrar más información en el blog de Heroku, en este blog Adam Wiggins nos da algunos ejemplos para usar NoSQL:

  • Grandes cantidades de datos (como estadísticas del tiempo o bussiness analytics) que trabajan mejor en sistemas distribuidos como Hadoop.
  • Contenidos binarios (como MP3 o PDFs) que pueden servirse directamente por el navegador, como Amazon S3.
  • Datos temporales (como sesiones web, variables o estadísticas) de rápido acceso y bajo coste como Memcache
  • Si necesitas ser capaz de replicar tus datos en multiples localizaciones (sincronizar base de datos entre un smartphone/facebook/spotify) te gustará CouchDB.
  • Aplicaciones de alta disponibilidad, donde minimizar el tiempo de caida es crítico, gracias al cluster automatizado y la configuración reduntante de datastores como Cassandra y Riak.

    • En otra entrevista realizada por el blog MyNoSQL a Ryan KIng (@rk), éste menciona detalles interesantísimos sobre el proceso de migración que están viviendo. King cuenta minuciosamente sobre las posibles soluciones iniciales, las pruebas a pasar por cada una de ellas y hasta bosqueja el plan de migración.

    Futuro

    Cassandra pertenece a Google (¿ya tardaba no?) por la patente MapReduce por lo que dudo mucho que Apple quiera ni mirarlo, por otro lado GYM (Google, Yahoo, Microsoft) y otros como Facebook o Amazon llevan tiempo implementando estas soluciones, existen proyectos muy interesantes como BigTable (recomiendo leer el PDF) . Sea como sea, el paradigma NoSQL es una buena elección para el tratamientro de gran cantidad de datos, desde mi opinión aun le queda mejorar su implementación y madurar aunque ya os digo que vino para quedarse. Sólo hay que mirar en el último Structure 2010 donde una de las empresas más destacadas Riptano se dedican precisamente a implementar Cassandra, aquí os dejo una entrevista a su CEO.

    Fuentes

    Olvidate de ACID y piensa en datos [video]
    Análisis de características ACID vs BASE vs CAP
    Favoritos NoSQL de Ángel “Java” López
    Bitelia via Google Reader como siempre y más

    También te puede interesar:

    This is some text prior to the author information. You can change this text from the admin section of WP-Gravatar  I´m a spanish entrepreneur focused in cloud computing and video surveillance sollutions, presently working on www.vidium.es