Cuando hablé de PACELC surgió un término curioso: NewSQL. A diferencia de NoSQL este movimiento no viene a eliminar el uso de SQL de los Sistemas Gestores de Base de Datos (SGDB) sino más bien a completarlo. ¿Sabes en qué consiste?
NewSQL es un término acuñado en un paper de the 451 Group para incluir a todas las bases de datos que tras las promesas (a veces incumplidas) con NoSQL de agregar una alta escalabilidad a los SGBD, no solo prometen esto sino también mantener las garantías ACID.
Hemos visto la aparición de ofertas de bases de datos que hemos denominado 'NewSQL' con compañías prometiendo entregar la escalabilidad y flexibilidad prometida por NoSQL mientras retienen el soporte de consultas SQL y/o ACID (atomicidad, consistencia, aislamiento y durabilidad) o mejorar el rendimiento para cargas de trabajo adecuadas en la medida en que la escalabilidad avanzada prometida por algunas bases de datos NoSQL se vuelva irrelevante.
A lo largo del documento se hace hincapié en los problemas de escalabilidad de MySQL y cómo muchos grandes actores decidieron migrar a bases de datos NoSQL, algunos sin mucho éxito como el caso de Twitter:
Por supuesto, no todas las aplicaciones MySQL son adecuadas para ser cambiadas a una base de datos NoSQL y vale la pena señalar que como Facebook, muchos grandes usuarios NoSQL también continúan usando MySQL, incluido Twitter, quien se echó atrás en una migración planeada de su tabla de estado central a Apache Cassandra en 2010. Twitter continúa usando MySQL pero está adoptando Apache Cassandra para nuevos proyectos.
Los movimientos para intentar mantener la compatibilidad y agregar los nuevos requisitos para crecimiento sin necesidad de cambiar el SGBD movieron a muchas compañías a mostrar sus opciones. Repasaremos algunas de las mencionadas en el documento de the 451 Group y agregaremos otras surgidas más recientemente. También he eliminado algunas menciones como ScaleDB o GenieDB porque parece que sus soluciones no atrajeron a mucho público y dejaron de existir.
Tokutek Percona XtraDB
Tokutek Percona XtraDB Cluster es el nombre de la solución propuesta por la compañía Tokutek para escalar MySQL permitiendo a los usuarios de MySQL no cambiar su código y aprovechar la escalabilidad y alta disponibilidad proporcionada por esta base de datos.
En Capterra la puntuación de esta base de datos es bastante alta y tan solo se indican como notas negativas la dificultad de resolver algunos problemas cuando surgen y la latencia cuando se trabaja con un alto volumen de datos. Esto es determinado por la elección en PACELC de EC.
MariaDB Xpand
El creador de MySQL, Michael "Monty" Widenius, actual CTO de MariaDB Corporation AB, impulsó desde esta nueva compañía su fork de MySQL (MariaDB) y soluciones alrededor. El desarrollo ClustrixDB para obtener una base de datos distribuida pasó a llamarse MariaDB Xpand y al igual que el caso anterior propone un incremento en escalabilidad manteniendo las garantías de MySQL.
Al igual que el caso anterior y debido a priorizar la consistencia podemos encontrarnos latencias cuando empleemos las transacciones ya que estas serán transacciones distribuidas sobre los datos distribuidos entre los nodos del clúster, en PACELC la elección tomada sería PC+EC.
VoltDB
A diferencia de los casos anteriores y como vimos en el artículo sobre PACELC, la base de datos VoltDB ofrece las garantías de las bases de datos tradicionales empleando una distribución horizontal pero en este caso no emplea el protocolo de conexión de MySQL ni guarda compatibilidad con MySQL. En caso de seleccionar esta base de datos para desarrollar nuestra solución, tendríamos que acomodar el software para emplear el conector adecuado (o driver) y revisar las consultas que lanzamos contra la base de datos.
Recuerdo una empresa de videojuegos llamada Eonblast que en 2012 migró a VoltDB proporcionando una de las librerías para conectar con VoltDB desde Erlang. Desgraciadamente es otra empresa que echó el cierre.
Galera Cluster
Esta solución es la más nombrada recientemente, puede ser por tratarse de una solución de código abierto y gratuita. A efectos de funcionamiento es igual al resto, permiten una distribución de la información en diferentes nodos. No obstante, en este caso la forma de distribuir la información es diferente porque replica el contenido completo entre todos los nodos disponibles.
A efectos prácticos, emplear MySQL o Galera no se diferencia nada más que en el carácter de alta disponibilidad. MySQL per se no dispone de alta disponibilidad, si el clúster se apaga, perdemos los datos, no obstante con Galera, si un servidor de MySQL se apaga, podemos acceder a los datos mediante otro de los servidores sin problema gracias a su replicación maestro-maestro.
Esta solución en verdad no viene a solventar el problema de la escalabilidad e incluso agrega mayor latencia. Solo sería recomendable emplear esta solución si disponemos de una base de datos distribuida geográficamente que necesitemos mantener replicada y no con un alto volumen ni de escrituras ni de datos en general.
Conclusiones
MySQL se convirtió en la piedra angular del desarrollo de páginas web con PHP y a día de hoy sigue siendo muy utilizado en toda clase de empresas pero cuando la empresa crece nos encontramos con problemas. Hemos repasado algunas formas de hacer escalar la base de datos para mantener un mejor rendimiento a través de la distribución horizontal o distribución segmentada e incluso otra opción a la que muchos recurrieron como VoltDB.
Sí, hemos visto solo soluciones basadas en MySQL por lo que si somos usuarios de PostgreSQL, ¿qué otras opciones tenemos? Lo vemos en un siguiente artículo, comenta si quieres que revisemos otras bases de datos de tipo SQL que estés utilizando y quieras conocer su potencial de escalabilidad.
¿Y tú? ¿Has tenido que escalar tu base de datos? ¿Empleas o empleabas MySQL? ¿Tuviste que volver de una NoSQL de nuevo a una base de datos SQL? ¡Déjanos tu comentario!
