L’evoluzione del mondo No SQL è innegabile ed è certamente molto comodo avere a disposizione molte piattaforme database con concezioni diverse. A seconda dell’applicazione o del servizio che vogliamo creare, possiamo scegliere la soluzione più indicata.
Per un gran numero di sviluppatori e di imprese la piattaforma di riferimento resta comunque il mondo relazionale e quindi una qualche versione di SQL. Quindi tutto quello che può ottimizzare un ambiente SQL è benvenuto.
L’ottimizzazione di un ambiente database non è semplice e comprende molti aspetti. Uno è sicuramente fare in modo che le query e in generale le operazioni messe a disposizione degli utenti si svolgano nel minore tempo possibile. Un database veloce supporta più utenti e li rende anche soddisfatti. Ecco alcuni consigli generici su come fare.
Una operazione preventiva che viene spesso trascurata è l’unione di determinate tabelle. Se molte query e report eseguono operazioni simili di unione sulle stesse grandi tabelle, un modo per velocizzarle è preparare i dati in anticipo creando una nuova tabella che sia l’unione di quelle interessate.
Così facendo query e report potranno operare direttamente su una tabella senza eseguire il join. In molti casi reali esiste la possibilità di sfruttare questa opzione, che fa risparmiare risorse al database server.
Sempre per evitare di creare colli di bottiglia sul server, meglio scomporre l’aggiornamento o la cancellazione di grandi quantità di dati in blocchi più piccoli.
Il motivo è facile da capire: un aggiornamento o una cancellazione di molti dati sono comunque gestiti come una transazione unica, talmente “corposa” che può bloccare le altre. Se qualcosa poi va storto, il database deve eseguire il rollback di tutta la transazione.
Dividendo questo carico in piccoli batch si evitano sia i colli di bottiglia sia il problema di rollback impegnativi in caso di problemi.
Tra l’altro, se non è necessario eseguire tutte le operazioni in sequenza, i piccoli batch possono essere distribuiti nell’arco della giornata o anche oltre, alleggerendo ulteriormente il carico sul database server.
Analogamente, anche le transazioni troppo articolate dovrebbero essere scomposte in elementi più semplici.
Le query che agiscono su più tabelle corrono infatti il rischio concreto di bloccarle tutte fino al completamento della transazione. Meglio suddividere le operazioni in più routine che agiscono ciascuna su una singola tabella.
Attenzione anche ad analizzare che tipo di query insistono su tabelle di grandi dimensioni. Non è raro scoprire che per arrivare a un certo risultato si eseguono in una stessa procedura più query distinte su una stessa grande tabella o si estrae più volte uno stesso sottoinsieme. In entrambi i casi si sprecano risorse e il codice va ottimizzato.
Altro consiglio: usare le stored procedure quanto più possibile. Non è un concetto che piace agli sviluppatori secondo cui logica applicativa dovrebbe risiedere nel codice delle applicazioni e non nel database, ma è un approccio utile.
Le stored procedure sono profilabili e controllabili, inoltre portano a un riutilizzo più coerente del codice SQL.
A proposito di riuso, è certamente un bel vantaggio poter sfruttare codice SQL già fatto da qualche altro sviluppatore nostro collega, magari per un progetto simile al nostro. Ma non usiamolo ciecamente.Quasi certamente quel codice non è ottimizzato per la specifica operazione che vogliamo compiere. Esaminiamolo allora attentamente e vediamo se e dove può essere modificato per avere prestazioni migliori.
