La risposta all'interessante feedback di Diego al mio post di qualche giorno fa è venuta più lunga del previsto. Dato che credo possa essere di interesse generale ho deciso di fare un post cosi che possa essere letto con più comodoità e possa - perchè no - far iniziare una bella discussione aperta a tutti.
Questo è il feedback di Diego relativamente a questo post: "Missione Compiuta (riflessioni sulle applicazioni)"
"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-tier 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..."
Ciao Diego
finalmente posso risponderti con tutto il tempo che mi serve. Per 30 minuti sono in treno e non ho altro da fare che rispondere a post ed email. Mettiti comodo quindi :-)
Prima di passare alle risposte alle tue domande, rispondo ad una domanda non esternata esplicitamente ma intrinseca alla tue email: come utilizzare al massimo sw e hw a disposizione. La risposta è davvero semplice: usare un approcio scientifico al problema. Misurare, provare, verificare e misurare ancora. Come in tutte le discipline scientifiche anche nell'informatica non sfugge a questa regola di base. E' vero che l'informatica non è una scienza esatta per certi versi (lo sviluppo ad esempio), ma in alcune situazioni (tipicamente sistemistiche) è invece *molto* *molto* scientifica e quindi sottoponibile alle stesse regole ormai consolidate che si applicano a tutte le altre realtà di questo tipo: il metodo scientifico.
Veniamo ora alle tue domande:
1) Con quali strumenti posso capire quali sono le strade che mi permettono di massimizzare le prestazioni di una struttura multi-processore?
Che io sappia non ci sono strumenti specifici per questa problematica. Attualmente le strade sono - in mia opinione - principalmente due. La prima è relativa all'utilizzo di tool corretti che evitano di dover scrivede del codice molto complesso per usufruire correttamente di architetture parallele. Integration Services è un esempio di questo tool che, ovviamente, può essere usato solo se il problema è del dominio relativo ad Integration Services. Astraendo il ragionamento: usare il tool giusto e non lasciarsi prendere dalla voglia di sviluppare da zero un'applicazione.
La seconda strada è quella di svilupparsi da zero l'applicazione che si necessità (dopo aver attentamente valutato i tool che offre il mercato, come già detto) e quindi prendere coscienza che è necessario investire sullo sviluppo di applicazioni multi-thread che sono più difficili da sviluppare ma offrono sicuramente più scalabilità. A questo proposito il futuro è si promette roseo in questo MS è già al lavoro per rendere semplice lo sviluppo di applicazioni di questo genere. PLINQ è un esempio, e giusto oggi sono stati resi dispobinili un pò di nuovi strumenti: MS Parallel Extensions ed il sito MSDN dedicato al Parallel Computing.
Poi c'è una regola di base che vale sempre: usare *bene* gli strumenti a disposizione e *sforzarsi* di non limitarsi a seguire la prima soluzioni che ci viene in mente. Nel mondo dei db questo significa evitare di procedere con la scrittura di loop e cursori (che nel 99% dei casi non servono) e di ragionare in modo set-oriented, ossia lavorando su insiemi di dati e non su un dato per volta.
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)?
Sempre. Ogni singolo comando di un database è transazionale per definizione, quindi immagino tu stia pensando alle transazioni esplicite (BEGIN TRAN....COMMIT TRAN). Per capire quando serve usarle oppure no puoi iniziare seguendo questo principio: se la logica di business che stai implementando deve essere spezzata in più comandi perchè non esiste un singolo comando dell'RDBMS che usi che la può implementare, bene, allora devi usare una transazione esplicita. Pensa ad un ipotetico comando "MOVE". In T-SQL non esiste e quindi deve essere implementato come una sequenza di INSERT e DELETE. Visto che è solo la sequenza INSERT e DELETE a dare il risultato voluto, *devono* essere messi in una transazione, altrimenti se solo uno dei due potesse essere eseguito da solo non riusciremmo ad ottere la logica di business implicita nell'operazione di "MOVE".
Ovviamente questo è il caso più semplice....per tutti gli altri casi il discorso diventerebbe molto lungo....però mi hai fatto venire in mente che si potrebbe fare una bella "tavola rotonda" al prossimo workshop UGISS in perfetto stile "agile", interessante e stimolante!
3) Una applicazione multi-tier 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?
Dipende dal carico di lavoro che ti aspetti. Se la macchina che hai lo può sostenere puoi mettere Application Server e SQL Server 2005 insieme (ovviamente per ora non stiamo considerando gli aspetti di sicurezza). Se il carico di lavoro è troppo alto devi dividerli.
Ma non è questo il punto. Il punto che è tu devi essere sicuro che la tua soluzioni possa essere suddivisa su più server e quindi fare quello che si dice uno "scale-out". Devi progettare la tua soluzione come un insieme di servizi (eventualmente asincroni per un'ottimale scalabilità) che ti permetta di partire con una sola macchina ma di poter usare senza problemi una batteria di server. Stiamo ovviamente parlando di applicazioni grandi ed enterprise, ma oggi grazie ai web services ad a SOA è possibile usare lo stesso principio anche in applicazioni di più modesta entità. Ovviamente tenendo sempre un occhio alle prestazioni è necessario bilanciare bene l'architettura in modo che sia scalabile (scale-out e scale-up), performante e manutenibile.
Per quanto riguarda il "dove" parlare di queste problematiche, il posto giusto è il forum dedicato all'architettura: "Database Design & Server Architecture"