The Performance Model

Un post di oggi di Igor mi ha stimolato a scrivere un articolo che da qualche giorno ho nel cassetto. L'idea mi è venuta da quando ho assistito alla presetazioni di Paul Nielsen riguardo alla modellazione dei dati, dove, in una slide iniziale, mostrava in modo estramamente chiaro e semplice che impatto hanno sulle performance le ottimizzazioni che possiamo fare su un qualsiasi database (SQL Server 2000 e 2005 in particolare). Il concetto è riassunto da questa piramide:

Che in modo incofutabile comunica che l'impatto maggiore sulle prestazioni è dato da questa sequenza:

1 - Modello del database

Se il database è disegnato male (troppo o troppo poco normalizzato, tabelle con tipi di dati non corretti, e via dicendo) abbiamo un grosso problema. Questo livello è messo alla base di tutti gli altri non a caso; l'efficacia di ogni altra ottimizzazione, infatti, dipende da questo e quindi se il database è disegnato male non ci sarà nessun modo di ottere delle prestazioni davvero ottimali! (A questo si può cercare di porre rimendio tramite del refactoring sul database)

2 - Query

Le query devono essere scritte bene, in particolare per sfruttare al 100% le capacità di elaborazione di set di dati fornite dai database (Quindi niente cursori ed attenzione alle soluzioni row-by-row!). Oltre a questo bisogna prestare attenzione a richiedere solo i dati che ci servono (quindi niente "select *" !) ed a limitare il campo di azione della query (quindi occhio alle clausole where).

3 - Indici

Se il database è fatto bene e le query anche, gli indici fanno la differenza. A titolo informativo (esperienza di vita vissuta) possono migliorare le prestazioni del 1000% (si ho scritto proprio mille!). Gli indici hanno però la "penalità" di occupare spazio (su disco, in memoria, nei backup) e di dover essere mantenuti aggiornati (statistiche comprese).

4 - Concorrenza

Alcune volte le query sono lente perchè ci sono problemi di alta concorrenza sui dati e questo causa colli di bottiglia. Se le query sono fatte bene ed gli indici pure i colli di bottiglia non sono a carico di questi ultimi e sono probabilmente dovuti ad un "semplice" ingolfamento delle risorse. Normalmente ottimizzazioni in questo campo migliorano le prestazioni della singola query e non dell'intero sistema

5 - Server Tuning

Ok, dopo che siete sicuri che tutti gli altri punti sono già perfettamente controllati, è possibile fare del tuning al server in modo da verificare che i colli di bottiglia che creano eventuali attese troppo lunghe non siano da ricondursi ad una macchina sottodimensionata o mal configurata.

 

Prima che i DBA mi prendano a sassate sottolineo che questa piramide è costruita dal punto di vista dello sviluppatore, e quindi si dà per scontato che la macchina sulla quale gira SQL Server sia configurata in modo almeno sufficiente. E' altrettanto vero, infatti, che se la macchina è _davvero_ mal configurata (quindi senza neanche seguire le best practices di base) il punto 5 può diventare uno dei primi da controllare. Il problema verò, però, è che tutti punti sono dipendendenti l'uno dall'altro (anche se l'importanza assegnata dalla piramide a ciascun punto rimane vera) e quindi un database per essere davvero ottimizzato deve essere programmato e amministrato molto ma molto bene.

Dal grafico a piramide, in conclusione, si può dedurre che è  bene prendere tutto il tempo che serve (ovviamente senza esagerare) per disegnare il miglor modello dati che possiamo fare, in quanto, essendo posto come fondamenta della nostra struttura, è quello che più ha voce in capitolo in termini di prestazioni ed ottimizzazione ed è anche quello dalla quale tutto il resto dipende....inoltre, il problema dei database, è che una volta che sono messi in produzione hanno una vita media che è il triplo di quella di un'applicazione (quante volte viene rifatta da zero un'applicazione ma il database viene solamente ritoccato?). E' facile immaginare il perchè: una volta che i dati solo dentro nel database, estrarli tutti per importarli in un altro database disegnato meglio è un'operazione tutt'altro che agevole, dispendiosa e facilmente soggetta ad errori....il che si traduce in un database che diventa monolitico ed intoccabile

Spero che questo post aiuti a far chiarezza su questo concetto, putroppo gran parte dei database che ho visto in giro (escudendo io miei, of course ) sono disegnati _davvero_ male, fatti velocemente e da persone senza esperienza in materia. Se non sapete da che parte inziare ho segnalato alcuni libri sul wiki e spero, in futuro, di aver tempo di scrivere un pò di articoli in proposito.

Print | posted on Monday, October 10, 2005 7:32 PM

Feedback

# re: The Performance Model

Left by AlessandroD at 10/11/2005 12:27 PM
Gravatar Vero quello che dici. Ma è anche vero che per creare un buon modello bisogna sapere bene quello che si sta facendo, cioè conoscere al meglio possibile la realtà che si cerca di modellare. E secondo me il vero problema è proprio questo, manca una buona analisi del "problema" a cui si deve dare una soluzione. Per tantissimi motivi, tra cui l'ovvia mancanza di tempo, le ovvie specifiche poco chiare, gli ovvi sviluppi futuri non previsti, ecc...
Siamo sempre li, sarebbe da imparare bene a conoscere il problema che si sta affrontando, senza questo tutto il resto serve solo fino a un certo punto.
E forse forse questo dettaglio per chi progetta DB è parecchio più vincolante rispetto a quanto non sia per chi sviluppa le applicazioni.
Ciao, Alessandro

# re: The Performance Model

Left by Davide Mauri at 10/11/2005 5:42 PM
Gravatar Oppppssss...ho scritto Igor ma intendevo AlessandroD chiedo venia

# re: The Performance Model

Left by AlessandroD at 10/12/2005 8:49 AM
Gravatar Ah, ecco...
Comments have been closed on this topic.

Copyright © Davide Mauri

Design by Bartosz Brzezinski

Design by Phil Haack Based On A Design By Bartosz Brzezinski