Compresión en una conexión JDBC

base de dades
Esta semana hemos tenido una situación un poco peculiar. Una aplicación Java que conecta con una base de datos iba lenta en ciertos momentos. No era un problema de CPU en el cliente ni en el servidor de base de datos, ni tampoco era un problema de disco ni de red, todo iba como siempre.

El problema

Algunos de los listados de información que Java obtenía de la base de datos vía JDBC eran grandes (del orden de MB) y la respuesta tardaba en llegar por falta de un mayor ancho de banda.

¡Que lo haga la base de datos!

Cuando trabajaba en un grup de “consultoría” en la Universitat de València, teníamos una expresión que resumía parte del trabajo de esta semana: “¡Que lo haga Oracle!“.

base-de-datos-1

Una de las preocupaciones que siempre tiene (o debería tener) un programador es el rendimiento de lo que está creando. Al menos es una de las cosas que a mi me interesan (podéis consultar la entrada anterior del blog en que se hablaba de la creación de una cache en WordPress para agilizar la carga de marcas en un mapa de GoogleMaps). En esta ocasión hemos reingeniado parte de una aplicación Java que ejecutaba una serie de tareas (batch) y realizaba numerosas inserciones en base de datos, de forma que ahora se hace todo desde base de datos. Así nos ahorramos las conexiones-desconexiones de la base de datos y las esperas y conversiones de datos que supone ejecutar código Java (o PHP) y después SQL, para volver a ejecutar Java y volver a ejecutar SQL, etc.

La solución nos ha dado el resultado siguiente:

  • Una tarea que podía costar un cuarto de hora en Java-SQL no llega ni al minuto cuando es plenamente ejecutada por la base de datos.
  • El hecho de trabajarlo todo desde la base de datos nos ha facilitado tratar todo el proceso como a una transacción única de base de datos: se realiza completa o se anula también completamente, como si el usuario no hubiese empezado el proceso.

Però atención, también tiene algunos inconvenientes:

  • El redo log de la base de datos ha de ser suficientmente grande para todas les operaciones que pensemos ejecutar como una única transacción.
  • Se complica la posibilidad de mostrarle al usuario una barra de progreso que responda al progreso real de la tarea, aunque en este caso no era importante.
  • Esta solució, evidentemente, no será válida para sistemas en los que la carga de la base de datos por parte de un usuario durante tiempos importantes (por ejemplo un minuto) pueda ser un problema.
  • Las consultas SQL serán más complejas e incluso pueden hacer falta triggers o funciones PL-SQL.

La moda de los CMS y demás sistemas de programación “preconstruidos” hacen pensar a mucha gente que no hace falta saber SQL para programar. Está claro que eso puede ser cierto para proyectos sencillos y que no van a crecer en el futuro, pero cuando el rendimiento importa todos los detalles son cruciales.