Confirmado: Twitter se olvidará de MySQL. ¿La razón? La escalabilidad. ¿Qué significa esto? Que el manejador de bases de datos (DBM) relacionales MySQL no podrá (¿no puede más?) soportar la inmensa carga que suponen 50 millones de tweets al dÃa sin degradar la calidad de su servicio. Es por ello que el equipo técnico de Twitter cambirá MySQL por Cassandra: quizá el mayor representante open source del nuevo paradigma en DBM, las llamadas NoSQL.
Las transacciones de una base de datos relacional, como MySQL, deben cumplir con cuatro propiedades básicas, definidas por el gran Jim Gray como Atomicidad, Consistencia, Aislamiento y Durabilidad. Nombradas en la práctica como ACID (siglas en inglés), el cumplimiento de esas propiedades es una garantÃa de la correcta operación del DBM. Sin embargo, lograrlo es costoso, más aún cuando el sistema intenta escalar, y ya no digamos la velocidad a la que lo intenta: el sistema puede llegar a ser insostenible.
¿Por qué Cassandra? Básicamente, porque es descentralizado, tolerante a fallas, elástico (termino heradado de Amazon EC2; es la nueva manera de decir “escalable”), con alta disponibilidad y probado en el campo de batalla por Facebook (su gran impulsor a través de la Apache Software Foundation), Digg y (gradualmente) Twitter. Parte de su éxito se debe a que no intenta cumplir con todo rigor las propiedades ACID.
En 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. Cuando es interrogado sobre las principales razones del cambio, King responde (en relación con Cassandra):
- No hay puntos únicos de falla.
- Escrituras altamente escalables […]
- Una rica y productiva comunidad open source.
La teorÃa detrás de Cassandra (no debe sorprendernos), pertenece a Google. Hace unas semanas patentó dicho sistema, no sin controversia de por medio por la cantidad de proyectos y empresas que utilizan esos principios en sus propios sistemas. Como quiera que sea, NoSQL como nuevo paradigma para el tratamientro de gran cantidad de datos, llegó para quedarse (aunque también hay controversia sobre si son DBM, estrictamente hablando…).
VÃa: InformationWeek
Si se va a mejorar el servicio, bienvenido sea el cambio ;)
Me encanta todo este tema de las BBDD descentralizadas desde que descubrà que google funcionaba de esta forma (es que no me podÃa explicar como podia ir tan rápido…). Ya habÃa oido lo de casandra y google, lo que no sabÃa es que habÃan patentado la tecnologÃa del mismo. Me parece hasta lógico si ellos lo potenciaron, pero es una pequeña patada al software libre.
Un dia me pongo a investigar como programar con este sistema de BBDD, aunque supongo que a pequeña escala no debe ser muy útil…
Escalable y … ¿¡ tolerante a fallos !? … ¿ se puede decir que se sacrifica la INTEGRIDAD de los datos en pos de que todos quepan en ‘la caja’ ? … quizás lo haya entendido mal … he estado un tiempo trabajando con DB2 y la integridad de los datos es SacroSanta
Yo pienso exactamente igual, en la enseñanza y la practica se que se deben realizar las practicas del ACID asi es que no entiendo (o tal vez el tema lo explica mal) porque abandonan mysql aparentemente solo porque no quieren seguir estas practicas, en todo caso podrian simplemente no seguirlas. Creo que mas bien las razones del cambio deben ser diferentes a las aqui mencionadas.
Sera interesante ver los cambios -aunque es mas que probable que sea transparente para nosotros como usuarios- y como dicen “si el cambio es para mejorar pues venga
Si google lo usa e impulsa no es cualquier cosa -aunque ultimamente google ha estado fallando de lo lindo -wave y buzz no me dejaran mentir, ademas de google gear- pero este casandra parece indicado para el twiiter -digo, si fakebook lo usa, y no falla tanto por algo sera-
Me muero por ver que extingan a las ballenas blancas -o aparescan menos- en el twiiter
ya no quiero ver estos mensajes de bitelia den una occion donde dessingcribirme por fa les agradecere mucho
Estas confundiendo las cosas. La ventaja que siempre tuvo MySQL es que por defecto todas las tablas son MyISAM lo que quiere decir que no cumplen con el ACID y uno puede crear ciertas tablas como InnoDB si quiere trabajar con transacciones. Aunque escuche que en las ultimas versiones de MySQL están empezando a usar por defecto InnoDB, pero igual no tiene sentido cambiar el motor de la DB, con indicar que las tablas sean MyISAM basta y sobre.
@Felipe Calculo que se refieren que ante un eventual fallo en el query, se pueda perder un tweet pero no se caiga la base de datos.
Nadie sufre si se le muere un tweet, lo manda de nuevo y todos felices. Pero todos sufrimos al ver la Fail Whale por algún error del sistema.
@Emisho, no pude haberlo dicho mejor :-)
@Emisho arrrrggg la put***** ballena que mal me lo hace pasar XD
cambirá
tal cual lo dijo @Emisho, que se pierda un twitt no es la muerte de nadie, y nadie va a iniciar una demanda o similar. Es distinto si hablaramos de cuentas bancarias, en este caso la Integridad de los datos es primordial, y esencial el cumplimiento de las propiedades ACID
+100