picoSQL benchmark

Fare delle comparazioni tra database diversi è un compito molto delicato. Ci sono moltissimi fattori da prendere in considerazione, partendo dalle configurazioni hardware per arrivare ai tipi di query da scegliere. Per questo motivo non pubblichiamo confronti, ma diamo soltanto alcune indicazioni e mettiamo a disposizione dei sorgenti per chi desidera fare confronti diretti. Se poi qualcuno desidera fare confronti con altri database, saremo felici di pubblicare i risultati.
Il primo aspetto che abbiamo valutato riguardano la costanza delle performance al crescere della della concorrenza degli accessi. La costanza delle performance di un database è un dato importante che serve a garantire che i programmi che stiamo sviluppando oggi, tipicamente con pochi dati a disposizione e acceduti da poche persone, funzionino anche domani quando il database si riempe e gli accessi crescono.

Per fare delle prove di concorrenza abbiamo usato il multithreading di Java. Il programma JavaConcBench.java crea una tabella con tre attributi, due numerici e uno stringa. Due indici univoci vengono creati sul primo attributo numerico e sull'attributo stringa. Viene poi inserita la prima riga con i valori "(0, 0, 'First record')". A questo punto vengono generati dei thread, il cui numero viene specificato sulla linea di comando, ciascuno dei quali scrive una riga identificata univocamente dal nome che Java assegna a ciascun thread. Inizia quindi un ciclo in cui viene letta la prima riga del DB con una "select ... for update" in modo da bloccarla (l'opzione "SuspensiveLock" deve essere uguale a YES), viene incrementato di uno il primo attributo e viene riscritta la riga. Fatto questo viene riscritta la riga caratteristica del thread mettendo nel primo attributo il numero appena letto incrementato di uno mentre il secondo attributo numerico conta il numero di volte che questa operazione viene eseguita. Tutti i thread accedono quindi alla stessa riga, simulando così una condizione di elevata concorrenza. La correttezza della concorrenza viene garantita dal fatto che il primo attributo della tabella, cui è legato un indice univoco, non appaia duplicato in alcun momento. Il programma termina dopo 10'000 operazioni eseguite da tutti i thread. Aumentando il numero di thread quindi il numero di operazioni non cambia e quindi il risultato ottimale si ha quando il programma impiega lo stesso tempo sia che venga lanciato con un thread, sia venga lanciato con un numero qualsiasi di thread.
Nelle prove fatte sul computer dove abbiamo eseguito il test (Linux Pentium4 1.9Ghz) usando picoSQL il programma impiega 57 secondi lanciato con 1 thread. Il tempo sale a 1 minuto e 8 secondi se i thread contemporanei sono 16, per arrivare a 1 minuto e 19 secondi quando viene lanciato con 128 thread. Lo stesso programma con database Oracle 8.1.7.0.1, installato sullo stesso computer senza particolari configurazioni, ha impiegato 1 minuto e 12 secondi con 1 thread e ben 3 minuti con 16 thread. Con 128 thread non abbiamo fatto il test percé avremmo dovuto riconfigurare il computer. Abbiamo tentato di effettuare il test con altri DB, e precisamente MS-SQL e mySql, ma in entrambi i casi non siamo riusciti a far andare il programma con più di un thread, probabilmente a causa delle nostre limitate conoscenze su quei sistemi.