¿Las bases de datos relacionales tienen futuro?

Estoy sintiendo que estamos ad porta de grandes cambios. Algunas de mis publicaciones anteriores en este blog van en este sentido: fin de la moda SOA y fin de la era "ServerSide Enterprise Java es el único tema de interés". Este blog es para describir porque creo que las bases de datos SQL no van a estar ajenas a los vientos de cambio.


El ultimo gran cambio TI que nos ha tocado vivir, es evidentemente la web. Creo que este cambio fue bastante benéficioso para los grandes proveedores de bases de datos SQL, los cuales ni se queda sufrieron el impacto económico de las soluciones Open-Source como MySql y Posgres.

Las ventas no han bajado, pero ya no se usa sus motores como antes. En mi caso, no he programado un solo store-procedure o trigger desde el año 1997. Incluso, en uno de mis últimos proyectos JEE, ni se queda he ejecutado un comando SQL DDL (los comandos tipo create table, create sequence, etc): se creo el modelo con clases Java anotadas con JPA y TopLink se encargo de todo el resto. Tuve que ejecutar comandos DML (select, insert, delete, update) para hacer una carga inicial masiva dejando en pruebas unitarias las cargas de tablas de parámetros chicas. Entonces las aplicaciones que me ha tocado ver ya no dependen de un lenguaje de store-procedure como el PL-SQL de Oracle, T-SQL de Sybase, SQL-Server y "ni se queda conozco su nombre" en caso de DB2 (empecé a usar DB2 desde la época web, por eso no se como soporta los store-procedure).

Eso tiene un impacto radical para los proveedores de BD porque las aplicaciones de negocio ya no dependen de sus productos y es mucho más fácil para el cliente negociar rebajas sobre las licencias. Antes de la web, había que re-escribir una aplicación desde cero para mover de Sybase a Oracle. Ahora, el costo de migrar de un motor a otro es una fracción del costo de desarrollo de la aplicación y puede financiarse con ahorros en costos de licencias.

Cabe notar que mi experiencia es principalmente el mundo Java y JEE y que en el mundo .Net pasa algo un poco distinto. Si el cliente ya decidió amarrarse con .Net y MS, el argumento de poder migrar de SQL-Server ya no es tan valido. Entonces, es normal encontrarse con aplicaciones relativamente recientes hechas principalmente con T-SQL, lo que a mi me resulta curioso y me hace recordar los viejos tiempos de Sybase.

En resumen, en la época web la capa de negocio se fue del motor (donde estaba en store-procedure y trigger) hacia el servidor de aplicación y eso reduce la dependencia hacia el fabricante del motor, pero no ha puesto en duda el lenguaje SQL y todo lo relacionado, como el modelo relacional y el comportamiento ACID de las transacciones. Creo que eso esta por cambiar.

Un impacto sobre las aplicaciones TI que viene pronto es el crecimiento en volumen de datos y volumen de transacción a procesar. Eso se da por varias razones:

• necesidad de procesar mucho más eventos de negocio. Por ejemplo un lector RFID genera 300 eventos por segundo: si un supermercado tiene 20 cajas con 2 lectores cada una, son 120.000 eventos por segundo en un solo supermercado. Y todos estos eventos deben ser filtrados y correlacionados entre si para generar otros eventos de negocio: este tipo de procesamiento se llama CEP. Para lograr eso, hay una nueva clase de arquitectura llamada EDA que es mucho más distribuida que la actualmente acceptada basada en capas

• para aplicaciones web más común, las RIA aumentan drasticamente los HTTP hits Antiguamente, solamente una porción de una recarga de pagina usaba la base de datos y además había un tiempo de pensamiento del usuario antes de cargar otra pagina. Ahora, las paginas hacen auto refresh parciales y muy frecuentes, que requieren ir a la BD el 90% de su tiempo de ejecución.
  

Como respuesta a estas necesidades se observa que:

• algunos cuestionan la arquitectura en 3 capas,
• se elimina el uso del protocolo XA (2PC o Two Phase Commit).
• se distribuye masivamente los datos en modalidad "share nothing",
• una consecuencia de los 2 puntos anteriores, es que las transacciones cubren solamente actualizaciones a datos que están físicamente cercanos.
  
• se usa caches distribuidos y grillas (como el producto Coherence comprado hace poco por Oracle) que evitan hacer hit a las bd,
• se cuestiona el almacenamiento tradicional basado en filas y se propone almacenar basado en columnas.

Como ejemplo, la base de datos de Google App Engine soporta estos conceptos y no es relacional. ¿Tremendo cambio de paradigma no?

Entonces, desde la época web, los grandes proveedores de BD ya no dictan el mercado y nuevos actores pueden entrar como es el caso de Google con su GAE. Además, el aumento en el volumen esperado de transacciones obliga a revisar el modelo actual de las aplicaciones. Hay que esperar cambios en SQL y el modelo relacional.

¡Era tiempo! El estándar SQL debe tener 20 años sin actualización relevante.