De acuerdo al pionero de bases de datos, Michael Stonebraker, Facebook opera una gigantesca implementación de MySQL, equivalente, según sus palabras, “a un destino peor que la muerte“, y la única manera de salir de este problema es “reescribirlo todo de nuevo“. Cabe decirse que no es un error necesariamente de Facebook. Stonebraker dice que el predicamento de la red social es comín a todos los inicios en la web que empiezan casi de cero y que crecen a proporciones épicas.
Durante una entrevista esta semana, Stonebraker explicó que Facebook ha dividido la base de datos MySQL en 4000 fragmentos, para poder manejar la cantidad masiva de datos y que está actualmente corriendo 9000 instancias (en memoria caché), para poder lidiar con el número de transacciones que la base de datos debe servir. Y aunque hay que corroborar estos números con Facebook, es evidente que no hay misterios en la historia de Facebook con MySQL.
Las estadísticas del 2008 indican que el sitio tenía 1800 servidores dedicados a MySQL y 805 servidores dedicados a transacciones vía caché de memoria y aunque muchos fragmentos e instancias de memoria caché pueden correr en un solo servidor, Facebook incluso mantiene un MySQL en la página de Facebook dedicada a actualizar los lectores para poder escalar la base de datos dentro del sitio.
Está ampliamente aceptado que MySQL no fue construído para lidiar con aplicaciones web que tengan una cantidad masiva de transacciones. Stonebraker dice que el problema de MySQL y otras bases de datos SQL es que consumen muchos recursos y que muy pocos de ellos son utilizados para el servicio de los datos. MySQL puede ser la herramienta adecuada para un conjunto pequeño de datos, pero se vuelve muy pesada cuando empiezan a crecer masivamente las transacciones dentro de la misma.
Esto es realmente un problema con compañías como Facebook, que tienen una cantidas gigantesca de datos de los usuarios e incluso, cuando uno da “click” sobre el icono de “me gusta“, la actualización del estado, o el unirse a un nuevo grupo implica una transacción que la base de datos MySQL debe procesar.
Pero en opinión de Stonebraker, “este viejo SQL” -como él le llama- “es bueno para nada“, y debería irse “a la casa del software en retiro“. Después de todo, como él explica, SQL fue creado hace décadas, mucho antes que la web, los dispositivos móviles, sensores, etc., que han cambiado cómo son accedidas frecuentemente las bases de datos.
Pero hay que reconocer que productos como MySQL son de código abierto y gratuitos. Esto significa, a decir de Stonebraker, que cuando se empieza una página web con necesidades de bases de datos, MySQL es la elección natural. Pero cuando las necesidades crecer, como en el caso de Facebook, y en donde no se tiene tiempo de hacer reingeniería de la base de datos, entonces se recurre a los “curitas” para resolver los problemas que van ocurriendo, pero nunca llegan a solucionar las dificultades porque están usando una estrategia inadecuada de manejo de datos.
Hay, desde luego, muchos intentos de solucionar los problemas de desempeño y escalabilidad de MySQL, incluyendo el movimiento “NoSQL“, que surgió ya hace algunos años. Sin embargo, se descubrió que aunque NoSQL podía ser más rápido y mejor escalable, esto ocurría a expensas de la consistencia ACID (“Atomicity, Consistency, Isolation, Durability”, por sus siglas en inglés, un modo relativamente complicado de decir que las transacciones son ejecutadas con precisión, lo cual es una situación muy importante en algunos nichos, por ejemplo el comercio electrónico, el cual debe confiar plenamente en la precisión con las que se ejecutan las transacciones).
Stonebraker piensa que sacrificar el ACID es una “idea terrible“, y hace notar que las bases de datos NoSQL terminan siendo marginalmente más rápidas porque requieren de escribir cierta consistencia y otras funciones en la lógica de la aplicación de negocios. Y añade que NoSQL es una opción interesante para guardar y procesar datos poco estructurados o sin una estructura clara tales como los documentos, los cuales no son necesariamente “bien portados” para las bases de datos relacionales. De hecho Facebook utiliza en algunas partes un sistema similar, aunque mucho de lo que se hace en su núcleo es MySQL.
Stonebraker tiene por suerte, su propia respuesta a los problemas del “viejo SQL” y al NoSQL. A eso le llama el NewSQL (un término acuñado por el analista del Grupo 451, Matthew Aslett), lo que es decir, un SQL escalable. Empujado por compañías como Xeround, Clustrix, NimbusDB, GenieDB y la propia de Stonebraker, VoltDB, el producto NewSQL mantiene las propiedades ACID y elimina la mayoría de las otras funciones que alentan el desempeño de las bases SQL tradicionales. VoltDB es una base de datos de procesamiento de transacciones en línea (OLTP, por sus siglas en inglés), y utiliza un número de métodos para mejorar la velocidad, incluyendo correr todo el tiempo en memoria en lugar de usar el disco.
Sería fácil acusar a Stonebraker de hacerse publicidad a sí mismo y a su idea del NewSQL, pero quienes están en esta iniciativa han empezado a ver más interés en inversionistas y clientes en estos últimos años. No hay evidentemente garantía de que Facebook arregle pronto sus problemas con sus bases de datos, pero para aquellos que empiezan en este negocio de las bases de datos SQL por Internet, bien podrían echarle un vistazo a NewSQL, en donde se eliminan los problemas de sus predecesores.
Fuente: Gigaom