Compressió en una connexió JDBC

base de dades

Aquesta setmana hem tingut una situació un poc peculiar. Una aplicació Java que connecta amb una base de dades anava lenta en certs moments. No era un problema de CPU al client ni al servidor de base de dades, ni tampoc era un problema de disc ni de xarxa, tot anava com sempre.

El problema

Alguns dels llistats d’informació que Java obtenia de la base de dades via JDBC eren grans (de l’ordre de MB) i la resposta es retardava per no tindre un major ample de banda.

Que ho faça la base de dades!

Quan treballava a un grup de “consultoria” de la Universitat de València, teníem una expressió que resumia part del treball d’aquesta setmana: “Que ho faça Oracle!“.

base-de-datos-1

Una de les preocupacions que sempre té (o hauria de tindre) un programador és el rendiment del que està creant. Almenys és una de les coses que a mi m’interessen (podeu consultar l’entrada anterior del blog on es parlava de la creació d’una cache a WordPress per a agilitzar la càrrega de marques a un mapa de GoogleMaps). En aquesta ocasió hem reenginyat part d’una aplicació Java que executava una sèrie de tasques (batch) i realitzava nombroses insercions en base de dades, de forma que ara es fa tot des de base de dades. Així ens estalviem les connexions-desconnexions de la base de dades i les esperes i conversions de dades que suposa executar codi Java (o PHP) i després SQL, per a tornar a executar Java i tornar a executar SQL, etc.

La solució ens ha donat el resultat següent:

  • Una tasca que podia costar un quart d’hora en Java-SQL no arriba ni al minut quan és plenament executada per la base de dades.
  • El fet de treballar-ho tot des de la base de dades ens ha facilitat tractar tot el procés com a una transacció única de base de dades: es realitza completa o s’anul·la també completament, com si l’usuari no haguera començat el procés.

Però atenció, també té alguns inconvenients:

  • El redo log de la base de dades ha de ser suficientment gran per a totes les operacions que pensem executar com a una única transacció.
  • Es complica la possibilitat de mostrar-li a l’usuari una barra de progrés que responga al progrés real de la tasca, tot i que en el nostre cas no era important.
  • Aquesta solució, evidentment, no serà vàlida per a sistemes on la càrrega de la base de dades durant un temps important (per exemple un minut) per part d’un usuari puga suposar un problema.
  • Les consultes SQL són més complexes i inclús poden ser necessaris triggers o funcions PL-SQL.

La moda dels CMS i demés sistemes de programació “preconstruïts” fan pensar a molta gent que no cal saber SQL per a programar. Està clar que això pot ser cert per a projectes senzills i que no han de créixer en el futur, però quan el rendiment importa tots els detalls són crucials.