[Linuxtrent] Implementazione di un recordset persistente lato server per applicazioni AJAX
- From: Guido <gdo@xxxxxxxxx>
- To: linuxtrent <linuxtrent@xxxxxxxxxxxxx>
- Date: Sat, 12 Aug 2006 12:05:03 +0200
Sono impegnato in questi mesi allo sviluppo di un framework, usato anche
in un paio di progetti G.P.L.(*), per gestire con tecnologia AJAX la
visualizzazione, modifica e cancellazione di record da database, per ora
PostgreSQL.
Nel caso di debba eseguire browsing di recordset con molti record (le
prove le conduco con un numero di record da 100.000 a 1.000.000) non è
materialmente possibile tenere persistente il recordset, sia perchè
occuperebbe troppa memoria, sia perchè il tutto gira in Apache1.3 o
Apache2.0 con evidente difficoltà nel mantenere l'oggetto in chiamate
successive del browser con più processi o thread che possono raccogliere
le richieste.
Ho quindi implementato un meccanismo misto, che dalle prove fatte mi
sembra il giusto compromesso tra velocità, occupazione di memoria ed
impatto sull'utente utilizzatore (... viviamo in un mondo di compromessi).
Vediamo ora il metodo in dettaglio:
1) Il calcolo del numero di record disponibili viene calcolato con
"select count(*) from
..... where ....." solo quando dal browser proviene una richiesta di
selezionare un nuovo recordset
2) Recupero delle chiavi dalla cache (vedi avanti) oppure Individuazione
delle chiavi dei record da recuperare, indicando il range da cui
prelevare dall'intero insieme: "select <KEY> from ..... where ......
offset ..... limit ......"
3) Salvataggio delle chiavi e rispettive posizioni nel recordset in una
tabella di cache.
Il numero di chiavi da recuperare è più grande del numero di record che
l'utente visualizza, in modo che successive richieste dal browser
vengano soddisfatte senza dover ricalcolare le query ai punti 1) e 2)
4) Recupero dei dati completi con la query "select <KEY>, ....... from
...... where id= <key1> or id = <key2> or ........ "
PRO:
L'acceso a recordset molto grandi rimane veloce; in quanto il conteggio
non viene ripetuto e per i record già recuperati non è necessario
lanciare la query di recupero delle chiavi.
I record modificati o inseriti rimangono nella stessa posizione fino a
quando non si esegue una diversa query.
Se il servizio Apache subisce un reset il browser non perde il recordset.
CONTRO:
Il recupero di range di chiavi non ancora presenti in cache varia se si
fanno modifiche successive.
Ad esempio nel caso che un record modificato cambi di posizione e venga
ripescato in una posizione diversa che ancora non era stata letta prima,
si avrebbe in cache lo stesso record, oltre ad influenzare l'ordine di
tutti gli altri che lo seguono.
Per gestire il problema del conflitto, quando viene rilevato, la cache
viene azzerata e l'utente viene avvisato che la query è stata
ricalcolata a causa delle modifiche fatte e che quindi la posizione dei
record modificati ed inseriti potrebbe essere diverso...
Il metodo ovviamente non è perfetto in quanto i record pescati in
successive query potrebbero essere incompleti anche senza pescare record
gia pescati (e quindi con disallineamento rilevabile).
Ma nell'uso normale che un utente fà, dalle prove che abbiamo fatto,
sembra essere un effetto tracurabile, che capita raramente e comunque
non pregiudica la consistenza dei dati.
Con un banale server Athlon 64 e dischi SATA, con 150.000 record e
dimensione del blocco di precaricamento di 100 record abbiamo 50msec di
tempo in più quando il record richiesto non è in cache (una volta su cento).
Qualche idea migliore?
cordiali saluti
Guido brugnara
(*) OpenClassroom 2.0 e MasonSQL 1.0; il cui rilascio in Internet è
previsto in autunno
--
Per iscriversi (o disiscriversi), basta spedire un messaggio con OGGETTO
"subscribe" (o "unsubscribe") a mailto:linuxtrent-request@xxxxxxxxxxxxx
Other related posts:
