¿Funciones de BD más lentas que SQL embebidos en JAVA?

[Und3rSpy]

Saludos amigos del foro...
 
¿Que tal son para Java y base de datos PostgreSQL, bueno yo recien estoy comenzando...
 
Se supone que el trabajar con funciones almacenadas en la base de datos y views es mas rápido el proceso de búsqueda que
el utilizar las instrucciones SQL dentro del codigo de programación en este caso JAVA... pero, que curioso, al hacer una
consulta en una tabla de PostgreSQL de 30.000 registros usando una función interna de la BD se demora alrededor de unos 15 a 20 segundos,
pero si lo hago usando SQL embebido en el codigo JAVA solo se demora unos 2 a 3 segundos.
 
No se si tiene que ver con la manera en se se llama a la funcion; he usado dos modos el select * from "esquema"."nombre de funcion"(parámetros)
y tambien uso la clase CallabledStatement. pero con ambos se demoran lo mismo de 15 a 20 segundos o mas incluso, pero cuando dentro del
codigo uso el select campo1, campo2,... from tabla1, tabla2,... where condición1, condición2, order by etc solo demora 2 o tres segundos
 
no he usado los inner join, outter join etc que se supone la consulta se la hace mas rápida aun,
 
Alguien tiene idea acerca de esta particularidad que me ayude, he buscado información en la web pero no he encontrado nada al respecto
 
y me preocupa mucho ya que estoy desarrollando una aplicacion en la que se trabaja con tablas de hasta casi 1 millón de registros...
porque digo que me preocupa, ya que aparentemente puedo hacer que el proceso de busqueda se mas rapida de una forma que otra, pues debido
a que se supone que la mejor forma de programar es usando funciones de BD y es poco recomendable usar SQL embebidas, ademas tambien por
asuntos de seguridad en el acceso a datos...
 

les agradezco su ayuda 

[jdoblesm]

Buenos días amigo,

En la buena teoría, si la consulta se ejecuta desde el motor de base de datos (por ejemplo un SP) se ejecuta mejor y más rápido, además que consume menos recursos a nivel de aplicación.

Sólo tengo una pregunta en cuanto a la consulta de los 2-3 segundos: estás corriendo exactamente la misma consulta en los dos escenarios??

Y por supuesto, entre más específica sea la consulta, pues le es más fácil al motor devolver datos 

Pura vida!

[Und3rSpy]

saludos... gracias por tu comentario...

Sólo tengo una pregunta en cuanto a la consulta de los 2-3 segundos: estás corriendo exactamente la misma consulta en los dos escenarios??

pues si es la misma consulta una se haya en una función de BD PostgreSQL y la otra directamente en el codigo de JAVA...

como ya mencione anteriormente utilizo dos maneras para llamar la función pero el tiempo de respuesta es el mismod de 15 segundos o mas, sin embargo la instruccion SQL que utilizo en
el Codigo JAVA es mucho más rápido de 2 a tres segundos.

Cuando comencé a desarrollar la aplicación solo utilizaba codigo embebido en java pero cuando implementé las funciones la ejecución de la aplicación se alertagó más, incluso hay veces que
despues de reiniciar el sistema a la primera ejecución de la aplicación java se demora más de lo normal de alli en adelante las ejecuciones son mas rapidas...

[jdoblesm]

Entiendo, pero para la consulta de PostgreSQL estás usando un procedimiento almacenado??

[Und3rSpy]

Sí, utilizo procedimientos almacenados, o en PostgreSQL Funciones.

Cuando ejecuto mi aplicación JAVA se ponen muy lentos. Lo que hago es deshabilitar las llamadas a las funciones PostgreSQL desde JAVA, e inserto los SQL de las funciones directamente al
código JAVA y ejecuto entonces el tiempo de respuesta se reduce drásticamente, es decir la ejecución es mucho mas rápida...

Ahora bien se supone que no debe ser asi, porque como ya mencionaste las llamadas de consultas al motor de base de datos son rápidas

[jdoblesm]

Mmm es que tendria que ver como haces el llamado a la función postgresql 

[Und3rSpy]

Lo explico arriba al principio del post
 
ejemplo:  Para llamar a una función o procedimiento almacenado en PostgreSQL lo hago de 2 maneras
 
1:   CallabledStatement funcion = new CallabledStatement();
      funcion = conexion.prepareCall({call "esquema".nombreFuncion(?,?)});
      funcion.setString(1, parametro1);
      funcion.setInteger(2, parametro2);
      ResultSet resultSet = funcion.executeQuery();
 
la otra manera:

2:   Statement declaracion = conexion.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE,ResultSet.CONCUR_UPDATABLE);
      ResultSet resultSet = declaracion.executeQuery( select * from nombreFuncion( '001' , 5) );
 
cualquiera de las dos formas de llamar a la funcion de BD a una tabla de 30.000 registros, el tiempo de respuesta es el mismo de 15 segundos o mas...
sin embargo si yo en el codigo JAVA hago esto:   

      SQL = "select * from facturas, detalleFacturas, productos, bodegas where facturas.periodo = '001' and facturas.documento = 5 and facturas.producto = productos.codigo
                        and facturas.bodega = bodegas.codigo order by facturas.documento";
 
      Statement declaracion = conexion.createStatement(ResultSet.TYPE_SCROLL_SENSITIVE,ResultSet.CONCUR_UPDATABLE);
      ResultSet resultSet = declaracion.executeQuery( SQL );
 
el tiempo de respuesta se reduce a solo 2 o tres segundos en la misma tabla de 30.000 registros.

             

[jdoblesm]

Men mira, puedes hacer una prueba,

Bueno la sintaxis TRANSACT para ejecutar un SP es:
EXEC "Nombre del SP ?,?" donde "?" son los parámetros.

En la 2da manera usas el select puro y se lo pasas al string SQL, entonces por qué no le pasas el comando EXEC como string tambien?, igualmente le puedes concatenar los parámetros al string .

Haz la prueba y me cuentas como te fue

Pura vida!

[Und3rSpy]

Ya encontré el problema por el cual se daba esta situacion 
 
Pues resulta que en una de esas que hice un insert de alrededor de 100.000 registros, al hacer la consulta con el
SELECT puro insertado en el codigo JAVA se puso muy lento... entonces fue cuando pense que quizas se necesitaba
hacer un vacuum y reindexar las tablas de las bases de datos...
 
cuando lo hice el tiempo de respuesta de la consulta volvio a la normalidad,
 
Me puse a pensar un poco al respecto    y fue cuando me di cuenta que siempre por defecto en el modulo de configuración del
gestor de la base de datos Postgres hay un parámetro se llama "autovacuum" lo revise y estaba en ON y pense que cada vez que se hacía una transacción
en la base de datos este hacía automaticamente el VACUUM por lo que se relentizaba en las consultas y demas procesos.
 
Lo puse en OFF y ¡VOLIE! el tiempo de respuesta al llamar a los stored procedure redujo ostenciblemente aunque no al mismo nivel que
hacer el SQL dentro del codigo de JAVA...
 
muestro los datos que me arrojo como resultado
 
   consulta a una tabla de 600.000 registros para mostrar 100.000 en pantalla con el parámetro AUTOVACUUM en OFF
 
- con stored procedure 5.30 segundos
- con SQL insertado en codigo JAVA  3.70
 
    antes con una tabla de solo 30.000 registros para mostrar 12.000 en pantalla con  con el AUTOVACUUN en ON
 
- con stored procedure 15 segundos o mas
- con SQL insertado 2 segundos o 3.
 
este parametro viene por defecto en ON por lo que uno tiene que desactivar manualmente cuando se instala el servidor de base de datos.
 
como podrán ver aun asi el SQL embebido en JAVA sigue siendo lijeramente más rápido que el stored procedure pero al menos
con el tipo de consultas y transacciones que necesito hacer me parece que el tiempo de respuesta es razonable como para implementarlo
en mi aplicación JAVA...
 
cualquier comentario al respecto les agradezco.    

[jdoblesm]

Jejejeje, ah esta bueno el toque 

También puedes probar con lo que te comenté, que en el string SQL pongas la ejecución del SP para ver que tal 

Pero si ya te funciona bien no hay problema!

Pura vida!