En los últimos días, varias personas me han preguntado mi opinión sobre la última versión MySQL 5.6. Para aquellos que no han visto las noticias, Oracle anunció su primera versión importante de MySQL en dos años. Dado que NoSQL ha crecido rápidamente en mercados clave en los que MySQL ha sido históricamente fuerte, supongo que no es sorprendente que Oracle haya centrado mucha atención en abordar los puntos débiles que han hecho de NoSQL un gran éxito. Tomas Ulin, vicepresidente de ingeniería de MySQL, llega incluso a decir que "MySQL puede combinar lo mejor de ambos mundos" y que "ya no se necesitan dos bases de datos".
La visión de Tomas y MySQL del mundo de las bases de datos parece ser que no será diferente de lo que ha sido durante gran parte de los últimos 40 años - principalmente que la tecnología relacional puede hacerlo todo y es la tecnología adecuada para cada necesidad.
Nosotros no creemos eso. Creemos que avanzamos rápidamente hacia una era en la que los desarrolladores de aplicaciones dispondrán de múltiples tecnologías de bases de datos y elegirán la que mejor se adapte a sus necesidades y casos de uso particulares. Cada tecnología tendrá sus puntos fuertes y débiles inherentes y ofrecerá un conjunto muy diferente de ventajas y desventajas entre las que elegir. A veces, una tecnología relacional como MySQL será la más adecuada (no creemos que la tecnología relacional vaya a desaparecer). Otras veces, una base de datos de documentos como Couchbase será la más adecuada.
Por eso no creo que MySQL 5.6 afecte al rápido crecimiento de NoSQL. La razón por la que NoSQL está despegando no es porque tenga una o dos características novedosas. Es porque ha hecho un conjunto fundamentalmente diferente de opciones arquitectónicas y compensaciones que muchos desarrolladores de aplicaciones prefieren para los tipos de aplicaciones que están desarrollando hoy en día. Añadir una función a una base de datos relacional como respuesta a lo que la gente dice que le gusta de NoSQL no va a cambiar estas diferencias fundamentales.
Por ejemplo, la tecnología relacional es fundamentalmente una tecnología basada en esquemas de tablas, filas y columnas. Añadir una capacidad como el nuevo lenguaje de definición de datos en línea (DDL) en MySQL 5.6 para que sea más fácil y lleve menos tiempo cambiar el esquema no hace que una base de datos relacional carezca de esquema. Tampoco aborda el hecho de que muchos desarrolladores encuentran mucho más intuitivo y productivo trabajar con documentos (objetos) en una base de datos de documentos que con las tablas de una base de datos relacional. Por lo tanto, aunque esta característica puede ser útil para los desarrolladores que han elegido la tecnología relacional por sus ventajas fundamentales, no hará nada para frenar la ola de desarrolladores que se han pasado a las bases de datos de documentos (u otras) NoSQL por sus ventajas fundamentales.
Del mismo modo, con la nueva API memcached de MySQL 5.6, puede que sea más fácil para los desarrolladores acceder a los datos utilizando las APIs get y set clásicas, pero la implementación es sólo superficial. Los datos que se almacenan todavía se asignan a tablas y columnas en el nivel de almacenamiento. Los desarrolladores todavía tienen que definir sus esquemas de tablas antes de utilizar estas API, lo que significa que todavía no obtienen la flexibilidad de esquema que necesitan las aplicaciones web. Triturar datos que no están estructurados -y cuya estructura cambia constantemente- para que encajen en tablas y columnas es un enfoque forzado e ineficaz.
Como nota al margen, es curioso que el equipo de MySQL parezca no estar a la altura de otras partes de Oracle. Mientras que el equipo de MySQL parece estar convencido de que MySQL puede hacerlo todo, el equipo NoSQL de Oracle parece pensar de otra manera y está tratando de alcanzar a los líderes NoSQL como Couchbase, MongoDB y Cassandra con su propio producto NoSQL. Si la tecnología relacional es una tecnología de talla única, ¿por qué la propia Oracle está haciendo una inversión tan grande en el desarrollo de su propio producto NoSQL?
Lo que vemos es toda una nueva oleada de aplicaciones que tienen requisitos muy diferentes de los que tenían las aplicaciones hace tan solo unos años. La mayoría de las veces están basadas en la nube, necesitan dar soporte a un número enorme y dinámicamente cambiante de usuarios, necesitan almacenar enormes cantidades de datos y necesitan un modelo de datos altamente flexible que les permita ajustarse a los requisitos de captura de datos que cambian rápidamente y procesar gran cantidad de datos semiestructurados y no estructurados. Las decisiones arquitectónicas fundamentalmente diferentes integradas en las tecnologías NoSQL, junto con la fácil escalabilidad, el alto rendimiento constante y las ventajas del modelo de datos flexible (junto con todas las demás ventajas y desventajas) que ofrece NoSQL, están resultando ser la mejor opción para un número cada vez mayor de estas aplicaciones.
Eso no significa que MySQL (o las bases de datos relacionales) vayan a desaparecer o que no vayan a desempeñar un papel importante en la industria de las bases de datos en el futuro. Solo significa que los desarrolladores tendrán más opciones (algo siempre positivo) y que algunas tendencias muy potentes están muy bien alineadas con los puntos fuertes de la tecnología NoSQL.
En mi opinión, handlersocket (que permite el acceso al motor de almacenamiento sin capa SQL) era un puente perfecto de tipo NoSQL entre los dos mundos. Llenar un vacío de productos que quieren proporcionar una mayor tasa de acceso a los objetos, manteniendo las capacidades transaccionales del motor subyacente. El intento de Oracle de "NoSQL" es bastante pobre. Usted tiene que crear manualmente / configurar las asignaciones a los almacenes de objetos en una base de datos especial, y estas tablas especiales tienen que ser definidos de una manera específica. Eso es bastante restringido.
Con handlersocket, sólo tengo que abrir la base de datos / tabla de elección, y luego disparar. ¿El gran inconveniente? Handlersocket no compila con 5.6, y hasta que lo haga, no hay manera de aprovechar los beneficios de las mejoras que Oracle ha hecho a nivel de InnoDB.
Otro punto negativo es el rendimiento de la nueva interfaz memcache nosql. En mi equipo con 5.6, maneja 500.000 filas por segundo de lectura. Handlersocket con 5.5 en la misma caja, maneja 800,000 para el mismo perfil de datos. Desearía que Oracle hubiera tomado el Handlersocket y lo hubiera usado.