Newsgroup: it.comp.java
Titolo: Tempi di esecuzione query.

Salve a tutti,
avrei una domanda da porvi...
Ho scritto alcune classi Java che eseguono query su un certo numero di
tabelle, al fine di fornire ad un utente un sistema di ricerca di coppie
codice-descrizione. Il caso d'uso tipico prevede che l'utente inserisca una
porzione della descrizione e che il sottosistema ritorni, paginandoli, un
elenco di codici la cui descrizione corrisponde al criterio desiderato.
Il mio dubbio riguarda la velocità di esecuzione, perchè i tempi di risposta
non mi soddisfano. La tabella contiene oltre mezzo milione di record, e
ciascun record è composto da oltre 100 colonne. Ovviamente, nella query di
ricerca, seleziono solo quelle che mi interessano. Vorrei sapere da chi ha
avuto a che fare con tabelle di queste dimensioni quali possono essere dei
tempi di risposta "ragionevoli", considerando che la ricerca avviene via
web.
Grazie in anticipo a tutti,
Scorpio.

Il tempo "ragionevole" dipende molto dall'utente. Se e' un applicativo che
viene utilizzato "alla desktop", quindi un vero e proprio applicatiov web
utilizzato in LAN piuttosto che via web allora ti direi che due-tre secondi,
tra la submit e la presentazione dei risultati, sono il tempo "limite" che
la mia esperienza mi suggerisce. E soprattutto il tempo limite prima che
l'utente *riclicchi* il fottuto pulsantino :)
Ci dovrebbero essere degli studi in proposito, comunque.
-- 
---
Francesco Galli / Cinghiale Mannaro
Personal: 
http://cinghialemannaro.splinder.com
TMS project: 
http://tms.inera.it

 la mia esperienza mi suggerisce.
Ti ringrazio per la risposta. Il fatto č che, per alcune tipologie di
ricerca, il tempo di risposta č intorno ai 20 secondi. Il che č davvero
tanto,
ma purtroppo non ho la piů pallida idea di come si possa ulteriormente
ottimizzare una query del tipo "select codice, descrizione from tabella
where
descrizione like %_parametro_%" limitandosi, peraltro, a caricare i primi
100 record....
Intanto, grazie per la risposta !
Scorpio.

Prova su it.comp.software.database... comunque dipende molto dal tipo del
campo su cui fai la query, sul db utilizzato e sul driver jdbc (dipende da
come tratta la sintassi di limitazione).
Prova a fare dei test provando diversi driver. 20 secondo sono francamente
ecceessivi, nessun utente te li accettera'.
Posta qualcosa in piu', magari...


 ecceessivi, nessun utente te li accettera'.
E' in effetti quello che temo.. ti ringrazio per le dritte...
Purtroppo c'è ben poco da postare: a livello di codice, non si fa altro che
eseguire uno preparedStatement con una select secca. Niente arzigogoli nè
giri strani....
Grazie ancora!
Scorpio.

Che DB stai usando, e quale sintassi di limitazione? La stessa query,
eseguita dal client, ci impiega lo stesso tempo?


 eseguita dal client, ci impiega lo stesso tempo?
Si tratta del DB2 nativo su AS400. Se uso il client a riga di comando, i
tempi sono addirittura peggiori, a meno che non utilizzi l'interprete SQL
nativo.
Quest'ultimo, però, può fare una cosa che in SQL non si può fare: ossia,
tiene  probabilmente traccia di un puntatore diretto alla struttura interna
del DB2 / 400. Ciò spiegherebbe la velocità di esecuzione del client
"tradizionale".
Ora, la query è semplicemente quella che ho postato: "SELECT
CODICE,DESCRIZIONE FROM TABELLA WHERE DESCRIZIONE LIKE %parametro% FETCH
FIRST 200 ROWS ONLY", dove parametro è passato dall'utente.
La fetch limita il resultSet ad un numero prefissato di tuple. Per
"paginare" i risultati, tengo traccia della pagina corrente, e mi "sposto"
all'interno del resultset utilizzando il metodo absolute(). In effetti le
paginazioni successive sono velocissime (qualche decimo), pur dovendo
rieseguire ogni volta la query (anticipo una tua logica replica: potrei
anche cachare il resultset, ma mi è stato vietato)... è la prima esecuzione
che mi uccide.
Grazie,
Scorpio.


Se non trovi una buona soluzione anche provando altri db o driver, credo che 
tu debba passare a un motore di ricerca come Lucene e integrarlo nella tua 
applicazione. 

ma il campo di ricerca è indicizzato?

hai notato la clausola?
LIKE '%parametro%'.
Hai voglia di indicizzarlo... cosa fai, indicizzi un varchar? :-)


 ha scritto nel messaggio
news:1117449041.6...@g43g2000cwa.googlegroups.com...
ma il campo di ricerca č indicizzato?
Sě. Le query vengono eseguite su una vista fisica.
Scorpio.

 Hai voglia di indicizzarlo... cosa fai, indicizzi un varchar? :-)
Ad essere precisi la vista fisica è ordinata per campo descrizione. Anche
se, ovviamente, non è la stessa cosa.
Scorpio.

 100 record....
In condizioni normali, quella restrizione costringe il database a 
spazzolarsi tutta la tabella per essere verificata. Non c'č molto da 
ottimizzare, se non attivando una particolare feature (se disponibile 
per il tuo database) per le ricerche testuali.

 per il tuo database) per le ricerche testuali.
Quindi, mi stai dicendo che la lentezza è "congenita", ed in casi come
questi è "colpa" del database ?
Scorpio.

 ha scritto nel messaggio 
news:429af...@x-privat.org...

ti sta dicendo che i motori di ricerca non si fanno con i LIKE, nemmeno dal 
punto di vista prestazionale. 

 punto di vista prestazionale.
Ok, alternative ?

 ha scritto nel messaggio 
news:429af...@x-privat.org...

che db usi? alcuni (tra cui MySql) hanno un supporto nativo per le ricerche 
full-text.
Altrimenti c'é Lucene:
http://lucene.apache.org/java/docs/index.html
 

 
http://lucene.apache.org/java/docs/index.html
Non conosco questo framework...premesso che non ho  la possibilità di
duplicare / spostare i dati dal DBMS originale,  secondo te è ancora
possibile utilizzarlo ? Premetto che non sto scrivendo un motore di ricerca,
ma alcune classi a supporto di un gestionale.
Scorpio.

 questi è "colpa" del database ?
Si, è colpa del database. Perchè facendo LIKE '%valore%' è come se io ti 
dicessi di cercare sul vocabolario le parole che contengono 'valore'; è 
ovvio che l'ordinamento alfabetico non ti è di aiuto e tu potrai 
rispondermi solo dopo aver letto tutte le parole del vocabolario.
La soluzione per far lavorare il db in modo ottimale è (come ti dicevo) 
abilitare le ricerche full text, sempre che sia una feature disponibile.

 ma alcune classi a supporto di un gestionale.
i dati non occorre che vangano duplicati o spostati.
Il motore di ricerca ti richiede però la creazione di un indice anche 
abbastanza grosso memorizzato su filesystem.
Beh il motore di ricerca mica lo dovresti scrivere tu, lo dovresti solo 
utilizzare!
Avresti anche altri vantaggi del tipo che non é piu' una ricerca di 
sottostringhe, ma una ricerca sulle parole o sulle frasi. Puoi anche 
inserire delle stop word (come gli articoli le congiunzioni ecc), e fare 
altre cose che renderebbero più intelligente la tua applicazione, a costo di 
un aumento della complessità ;)

 ha scritto nel messaggio
news:429b04f0$0$17094$5fc...@news.tiscali.it...

Non è la complessità in sè che mi spaventa, ma se propongo l'utilizzo di un
motore di ricerca a chi di dovere
mi impiccano :-)
Comunque ti ringrazio sincermamente per i tuoi consigli...e mi scuso se
eventualmente sono sembrato
brusco ....
Scorpio.

 Scorpio.
Ciao,
L'as/400 ha la maledetta abitudine di prendere la ODP più vicina alla query
che fai, spesso la sbaglia completamente.
Prova a mettere sotto strsrvjob il lavoro che prende in carico la
connessione, poi fai un strdbg e vedi quale vista logica prende.
Tieni presente che i fisici a chiave sono mooooooolto + lenti che un indice
su una tabella. Ti consiglio di aprire strsql e fare una create view
sull'archivio, la tua select migliorerà del 60 %


Se vuoi ti mando anche il codice che uso io....a patto che poi se trovi 
soluzioni migliori me le dici! ;) 

 ha scritto nel messaggio
news:429c4034$0$15907$5fc...@news.tiscali.it...

Guarda, sei davvero molto gentile ma purtroppo vorrei evitare un'ulteriore
sperimentazione....
grazie lo stesso !
Scorpio.