Missione Compiuta (riflessioni sulle applicazioni)

In questi giorni sono stato alle prese con un database con più di 800.000.000 (ottocentomilioni!) di righe in un'unica tabella. Questa volta non mi soffermetò sul design corretto o meno di tale database, ma voglio porre l'attenzione su altri importanti concetti.

Lo scopo della mia consulenza e stato capire perchè su una macchina particolarmente carrozzata - ma neanche poi tanto - (4 Processori Itanium2 a 1.6Ghz 32 e GB di Ram) alcune applicazioni basate su SQL Server erano più lente che su una macchina molto più modesta (AMD Dual Core 2.8Ghz e soli 16 GB di Ram).

Non vi sto a tediare (nè tantomeno potrei farlo) con le varie problematiche riscontrate, ma su una cosa - vitale - voglio porre l'accento.

Il problema centrale è legato al fatto che il futuro è nell soluzioni multi-core, dove quindi la scalabilità di un'applicazione è semplicemente fondamentale.

Se la vostra applicazione non scala, e quando è in presenza di 4 processori (o un domani di 8 o 16 o 64) non è in grado di sfruttare TUTTI i processori...la vostra applicazione è destinata a fallire. Un'applicazione che su 4 processori ne usa solo uno ed al 100%...non ha semplicemente futuro. Certo, oggi un 2.8Ghz batte un 1.6Ghz ma c'è un limite (apparentemente) alla velocità che un processore può raggiungere, ed i 2.8 Ghz sono pericolosamente vicino a questo limite. Il futuro non è quindi tanto nelle soluzioni che spremono il 100% dalle CPU più potenti (in termini di clock), ma di quelle che sono in grado di divere il carico di lavoro su tutti i processori disponibili.

SQL Server è in grado di fare questo per voi, ma dovete programmare in modo che lo possa fare, altrimenti tagliate le gambe alle vostre soluzioni.

Stored Procedure a parte è F-O-N-D-A-M-E-N-T-A-L-E che il codice che scrivete sia il più Set-Oriented possibile e non vi riconduciate ad usare sempre cicli o cursori per risolvere le situazioni apparentemente più complesse. La chiave di volta è lavorare su set di dati (e quindi insiemi) e non row-by-row come, invece, è inizialmente più comodo (almeno da un *** di vista umano) fare.

Seconda cosa: non ostinatevi a pensare di essere dei grandi sviluppatori ed a voler fare tutto da soli. Probabilmente siete davvero dei bravi sviluppatori, ma non avete il tempo che Microsoft (o chi per essa) ha investito per sviluppare tool come gli Integration Services. Usateli, usateli, usateli. Difficilmente le vostre applicazioni potranno scalare agli stessi loro livelli. Oppure volete dirmi che avete tempo di scrivere codice che sfrutta corretamente architetture NUMA? E che avete tutto il tempo necessario per scrivere applicazioni multithread che realmente sfruttano in modo bilanciato tutti i processori?

Credo che sia sempre più importante capire come sfruttare al meglio i tool che abbiamo a disposizione e che questi tool permettano di essere facilmente estesi od integrati con funzionalità custom scritte da noi (e qui entra in gioco - pesantemente - lo sviluppo) in modo da poter implementare le funzionalità che ci servono laddove richieste e dove il tool non ci arriva nativamente.

Credo che questo (almeno nel "mio" mondo) sia il futuro. E' importante prepararsi sin da ora - visto che la tecnolgia diverrà sempre più complessa, formandosi e conoscendo bene gli strumenti con cui dobbiamo lavorare per capire dove li possiamo spingere, dove ci possono portare, e dove dobbiamo intervenire noi.

Rimango sempre più perplesso quando vedo soluzioni custom costruite da zero. Molte volte chi le ha sviluppate non ha fatto una scelta sensata - anzi, non ha proprio fatta nessuna scalta: semplicemente se è buttato a capofitto nello sviluppo senza guardarsi intorno. Come sviluppatore capisco bene questo approcio (è sempre bello mettersi a scrivere codice che rappresenta una sfida) ma come consulente sono più che sicuro che non sia sempre la scelta corretta.

Ultima cosa. Attenzione a chi sostiene che non è importante ottimizzare le applicazioni o i database, visto che tanto l'hardware costa sempre meno e che quindi se servono più performance "si cambia il ferro". Il "ferro" probabilmente costa anche poco (relativamente) ma le licenze non sono regalate. Se inoltre un'applicazione non è scritta per scalare su più processori....buttate via i soldi.

La tecnologia diventa sempre più complessa ed è sempre di più necessario creare applicazioni e soluzioni di qualità medio-alta, in grado di sfruttare la potenza a disposizione.

L'esperienza di tutti i giorni me ne da sempre di più una incofutabile conferma.

Published domenica 25 novembre 2007 23.58 by dmauri

Comments

# re: Missione Compiuta (riflessioni sulle applicazioni)

lunedì 26 novembre 2007 10.13 by DiegoAllera

Caro Mauro,

ho letto davvero con molto interesse il tuo articolo, anche perchè un po' mi riconosco in quel cliente con cui hai avuto a che fare...mi occupo di applicazioni gestionale in ambito farmacutico e proprio in questi giorni mi trovo a dover riflettere su una situazione che tra un anno (o forse meno) dovrò gestire: ossia migliaia di righe su cui fare interrogazioni e decine (o centinaia) di store procedure da eseguire in un secondo. Il problema con cui ti sei scontrato è effettivamente quello che preoccupa tutti gli sviluppatori: come utilizzare al massimo strumenti sw e hw a disposizione. Ora le domande che ti pongo sono: 1. Con quali strumenti posso capire quali sono le strade che mi permettono di massimizzare le prestazioni di una struttura multi-processore? 2. Quando ha senso utilizzare una transazione e quando no (al di là del fatto che è preferibile avere transazioni con pochissime operazioni per evitare situazioni di deadlock o di inconsistenza)? 3. Una applicazione multi-thier con una serie di thin-client e un application server residente sulla stessa macchina in qui risiede il mio SQL Server 2005 può essere una buona soluzione o è preferibile comunque tenere separati application server e SQL Server?

Forse non è proprio questo il punto in cui parlare di tutte queste problematiche, ma mi sono affacciato da poco nell'ambiente MS SQL Server 2005 così come all'intero environment della gestione e sviluppo di applicativi database e quindi l'entusiasmo è tanto e la conoscenza poca...

Ti ringrazio in anticipo.

Ciao Diego.

# Riflessione sulle applicazioni - Risposta condivisa - Impedance Mismatch

Pingback from  Riflessione sulle applicazioni - Risposta condivisa - Impedance Mismatch

# PASS Community Summit 2008 - Day 3 Keynote

venerdì 21 novembre 2008 19.39 by Impedance Mismatch

La keynote di oggi è fatta da David J. DeWitt, "Technical Fellow" (che si traudce in "genio