Scenari Architetturali con SQL Server 2005
Pubblicato: 11 dicembre 2006
Davide Mauri – Microsoft MVP
L'uscita di Sql Server 2005 rappresenta un grande evento per diversi motivi. In questo articolo tralasceremo tutti quelli prettamente di "basso livello", legati allo sviluppo e all'ottimizzazione di codice e di modelli dati, e ci concentreremo solamente sulle implicazioni architetturali; queste sono di notevole importanza e, ancora, non sono state discusse.
In questa pagina
Sql Server 2005 come piattaforma applicativa
Scenari architetturali con Sql Server 2005
Conclusione
Sql Server 2005 come piattaforma applicativa
La prima grossa novità, che poi è anche quella che ci permette di guardare a Sql Server 2005 da un punto di vista puramente architetturale, è il fatto che Sql Server 2005 non è più solo un RDMBS ma è un'intera piattaforma applicativa; più precisamente è una piattaforma per lo sviluppo di applicazioni strettamente legate ai dati ed alla loro elaborazione. A voler essere ancora più precisi possiamo dire che è una piattaforma che permette:
la gestione, l'analisi e la distribuzione dei dati;
lo sviluppo di Data Access Layer avanzati;
la semplificazione dello sviluppo di applicazioni distribuite ed eventualmente asincrone.
L'altra grossa novità è data dalla versione gratuita di Sql Server 2005, ossia la versione Express, che, a differenza di quanto si potrebbe pensare, non è solamente relegata all'utilizzo amatoriale o semi-professionale ma, al contrario, è un punto fondamentale per la realizzazione di sistemi distribuiti dai costi contenuti ma estremamente affidabili.
Da quanto detto diventa piuttosto naturale pensare a Sql Server 2005 come le fondamenta sopra le quali verrà costruita una qualsiasi applicazione, dalla più semplice alla più complessa: dopotutto non credo che oggi possano esistere applicazioni non banali che non debbano memorizzare dati da qualche parte. Se quindi è ovvio che Sql Server 2005 è ideale come sistema per la memorizzazione e la ricerca dei dati, cosa ancora non è cosi ovvio? Scopriamolo.
Scenari architetturali con Sql Server 2005
Gli scenari di applicazione dalla piattaforma sono davvero molti e per ognuno ci sarebbe da scrivere pagine e pagine di testo. Ovviamente non penso di fare tanto, in quanto l'obbiettivo di questo articolo è quello di avvicinare quante più persone possibili a Sql Server 2005 e un articolo di 10.000 righe certo non riuscirebbe in questa impresa. Purtroppo non posso neanche essere troppo sintetico altrimenti non riuscirei a rendere con sufficiente chiarezza le possibilità fornite dalla piattaforma; quindi mettetevi comodi, stampatevi l'articolo e leggetelo un po' per volta (l'ho diviso in sezioni apposta) in modo da poter assimilare con calma la grossa quantità di novità - e potenzialità - che Sql Server 2005 porta con sé.
Ambienti distribuiti
Uno dei primi scenari in cui Sql Server 2005 può fare bella mostra delle nuove funzionalità è il classico scenario di un ambiente distribuito, potenzialmente disconnesso.
Attualmente ogni modifica di una dato su un database remoto richiede la presenza costante dell'accessibilità di rete oltre che la raggiungibilità e la disponibilità del server remoto.
Grazie a .NET la possibilità di essere un po’ più indipendenti dalla rete è garantita in quanto è molto più semplice che in passato costruire applicazioni disconnesse, ma questo, purtroppo, non risolve un’ annosa questione: se la connettività di rete è presente e funziona perfettamente, ma è il server ad essere TROPPO carico di lavoro e quindi non disponibile a processare la nostra richiesta, che succede?
La risposta è semplice, ma altrettanto dolorosa: il server si rifiuterà di processare i nostri dati dandoci un qualche tipo di errore, con il risultato che non riusciremo ad ottenere quello che vogliamo (una prenotazione, un biglietto per un concerto, la conferma di un ordine e via dicendo). Facciamo un esempio pratico: pensiamo ad un sito web di una società di gestione delle spedizioni.
Le spedizioni posso essere richieste dai clienti sia in via telefonica, dove un’ operatrice con un software dedicato provvederà alla registrazione della richiesta, sia in modo autonomo via web tramite un sito pubblico dedicato, sia tramite software dedicati dati in uso a società presso la quale esistono accordi quadro.
Tutte le operazioni vengono fatte su un unico database centralizzato al quale ognuno si collega tramite la rete.
Ogni registrazione di richiesta di spedizione provoca una serie di inserimenti di dati sul database server che possono essere anche molto complessi ma che, in condizioni normali, non provocano uno stress eccessivo della macchina che si comporta in modo egregio fornendo tempi di risposta più che buoni.
Il problema non si pone, quindi, fino a quando non accade per qualche motivo, un evento diciamo "eccezionale" che provoca un picco di lavoro molto elevato, al quale il nostro server non riesce a star dietro.
Come risultato si avranno tempi di risposta sempre più elevati fino ad arrivare al blocco di ogni richiesta che, nei fatti, si traduce nell'impossibilità dei nostri utenti di usare i nostri servizi e, di conseguenza, in un danno economico.
Tali eventi "eccezionali" nella realtà si verificano più spesso di quanto si creda, e ciò tutto sommato è corretto in quanto normalmente non ha senso comprare macchine estremamente potenti (e costose) solo per gestire i picchi di lavoro. Sarebbe molto meglio, a tutti gli effetti, se il picco di lavoro fosse gestito in automatico dal sistema, "diluendolo" in tempi più ampi ma garantendo sempre la qualità del servizio. In pratica sto dicendo questo: il fatto che sia necessario scrivere dei dati nel nostro database per far sì che la richiesta di spedizione sia registrata necessita della condizione che tale operazione sia sincrona? Detto in parole più povere: non è possibile affidare al sistema la richiesta che verrà inserita nel database nel tempo più breve possibile MA SENZA andare a creare intasamenti nel caso ci fossero già molto richieste in via di elaborazione? La risposta è ovviamente sì e credo che molti di voi abbiano già in mente il metodo normalmente utilizzato: un gestore di code come il MSMQ.
Risposta corretta ma in molti casi molto complessa da realizzare e molto invasiva rispetto ad applicazioni già esistenti. Sql Server 2005 grazie ad una funzionalità chiamata Service Broker permette di creare un sistema di gestione delle code completamente INTERNO al database (e quindi transazionale) e, volendo, completamente trasparente all'applicazione (non sto dicendo che è bene che l'applicazione sia ignara dell'esistenza di questo sistema, sto dicendo che se necessario è possibile farlo!).
Un'architettura basata su tale infrastruttura funziona nel modo seguente: l'applicazione invia un messaggio a Sql Server 2005 che lo prende in carico e assicura l'applicazione che il contenuto del messaggio (se privo di errori) verrà recapitato al destinatario. Il destinatario potrebbe essere un altro Sql Server o lo stesso che ha ricevuto il messaggio. In questo ultimo caso il messaggio verrà letto ed il contenuto verrà immediatamente processato. Se l'elaborazione del contenuto è molto lunga e nel frattempo arrivano altre richieste tramite messaggi, questi verranno messi in una coda che verrà smaltita in automatico, senza trattenere l'applicazione che ne ha fatto richiesta che può in ogni caso stare tranquilla in quanto la lettura e l'elaborazione del messaggio è garantita da Sql Server (in quanto sistema transazionale).
In questo modo è evidente che eventuali picchi di lavoro non metteranno in crisi il sistema perchè la coda di messaggi fa da ammortizzatore delle richieste e si preoccupa di darle in pasto a Sql Server solo quando questo è realmente disponibile a processarle.
Fin qui tutto relativamente semplice. Ora pensiamo non solo al problema della saturazione delle risorse del server che ormai abbiamo risolto, ma spostiamo la nostra attenzione sulle applicazioni che usano i nostri operatori ed i nostri clienti "corporate" che usano un'applicazione dedicata per inserire le richieste. Tale applicazione necessita per funzionare della connessione diretta al database centrale. Ma se questa connessione per qualsiasi motivo non è temporaneamente disponibile? Non possono lavorare, noi perdiamo clienti e siamo nella situazione iniziale.
Ecco qui che entra in gioco un'altra capacità notevole del Service Broker: l'autonomia. La nostra applicazione client non deve più essere disegnata per richiedere necessariamente il collegamento al Sql Server centrale, ma dovrà appoggiarsi ad un Sql Server locale che prenderà in carico il messaggio e si incaricherà di inviarlo al destinatario appena possibile. Nel caso la rete non fosse in quel momento disponibile si terrebbe il messaggio nella propria coda e, appena ripristinata la connettività, si preoccuperà di ritentare l'invio fino alla riuscita dello stesso.
Preoccupati del costo di tale soluzione, visto che è necessario installare Sql Server localmente a ogni client? Non preoccupatevi, il Sql Server installato sul client sarà la versione Express, totalmente gratuita!
Risolto questo siete ora preoccupati per l'impatto che tale modifica potrebbe avere sulla vostra applicazione? Tranquilli: l'utilizzo del broker avviene tramite comandi T-SQL e pertanto l'impatto si traduce - potenzialmente - nella modifica della stringa di connessione al database e delle stored procedure che localmente non devono fare delle INSERT ma dei SEND.
In tutto ciò sono ovviamente presenti meccanismi di gestione degli errori (messaggi "vecchi", non processabili, e via dicendo) e di protezione (autenticazione del mittente e del destinatario, cifratura dei messaggi, ecc.) che rendono tutta l'architettura non solo flessibile, ma resistente e sicura.
Direi che ci si può fermare qui con l'esempio, ovviamente si potrebbe continuare e se ne potrebbero fare molti altri, ma credo di aver reso l'idea, che mostra un problema non certo solamente legato alla gestione delle spedizioni ma molto più generale e sentito.
Personalmente sono fermamente convinto che già questa "semplice" feature sia un buon motivo per approfondire il discorso su Sql Server 2005.
Gestione di dati destrutturati e/o complessi
Con Sql Server 2005 diventa possibile andare oltre i limiti imposti da linguaggio T-SQL, perfetto per effettuare query ed elaborazioni su insiemi di dati ma non certo per sviluppare logiche di business complesse e computazionalmente onerose.
Per questo motivo in Sql Server 2005 è stata introdotta la possibilità di sviluppare funzioni e nuovi tipi di dati utilizzando .NET Framework.
Una delle soluzioni più sensate che mi vengono in mente è la memorizzazione di informazioni geografiche o tridimensionali che necessitano di tipi di dati ad hoc (latitudine e longitudine, vettori e coordinate spaziali) che non sono fornite nativamente con Sql Server.
La memorizzazione però da sola non basta. Supponiamo di avere una lista di comuni con la relativa posizione geografica (latitudine e longitudine).
Sarebbe bello poter scrivere una query che mi estragga tutti i comuni che sono entro 5 km da un certo punto di riferimento. Con il solo T-SQL questa richiesta sarebbe praticamente impossibile da portare a termine; utilizzando invece una funzione scritta tramite .NET tutto si può rendere molto ma molto più semplice ed efficiente.
Oltre a .NET in Sql Server 2005 è possibile anche memorizzare in modo nativo documenti o frammenti XML.
XML può essere usato sia come comodo mezzo di trasporto delle informazioni da e verso il database, che al suo interno le tiene memorizzate nel modo a lui più congeniale, ossia tabelle possibilmente normalizzate, oppure per memorizzare documenti XML in modo completo.
Nel primo caso l'utilità è piuttosto ovvia: oggi qualsiasi applicazione in qualche modo è in grado di accettare e produrre XML e quindi avere un database che è in grado di maneggiarlo in modo nativo non può che semplificare la vita e rendere il db stesso ancora più versatile e integrabile; ad esempio è possibile per un web server *nix chiamare senza grossi problemi una funzione di Sql Server tramite Web Service ed ottenere il risultato in formato XML, il che rende senza dubbio più facile la convivenza sotto lo stesso tetto di sistemi estremamente diversi.
Oltre a questo, come già accennato, è possibile anche memorizzare in Sql Server interi documenti XML: la novità rispetto al passato è che ora tali documenti possono essere indicizzati, manipolati, scomposti e ricomposti tramite nuove funzioni dedicate che rendono l'accesso alle informazioni ivi contenuto molto ma molto più agile che nel passato.
Il problema che si pone, a questo punto è: ma ha senso memorizzare interi documenti in XML al posto che cercare di memorizzarli nelle classiche righe e colonne? La mia opinione in proposito è molto chiara e la potete leggere nell’articolo che trovate a questo link:
http://blogs.ugidotnet.org/nettools/articles/14330.aspx
che ho scritto riguardo l'uso XML all'interno di un database.
Bene, quindi ora tutti i nostri database saranno sviluppati utilizzando .NET e XML? Assolutamente no. Lo ripeto assolutamente no. E' importante, molto importante, capire che tali funzionalità non vanno usate a cuor leggero, ma solo dopo un'attenta analisi e valutazione. I motivi sono soprattutto architetturali: tali funzionalità, infatti, tendono a snaturare l'uso del database, che è stato progettato per operare su relazioni non su oggetti come XML e .NET. Ogni volta che vengono utilizzati tali strumenti, infatti, si costringe il database a fare un lavoro in cui non eccelle particolarmente e che, inoltre, rende molto più "oscura" la distinzione tra Data Layer, Data Access Layer e Business Layer. In pratica c'è il rischio (o la possibilità, decidete voi) di rendere Sql Server non un database server ma un application server, cosa ovviamente potenzialmente dannosa.
A questo si aggiunge anche il fatto che, ad oggi, purtroppo c'è la figura del DBA e c'è la figura dello sviluppatore .NET ma non c'è una vera e propria figura che sia esattamente nel mezzo: questo rende pertanto piuttosto difficile per l'uno o per l'altro la manutenzione del database stesso. In effetti, com'è normale che sia, per gestire una maggior potenza è necessaria una maggiore attenzione ed una maggiore sensibilità.
Concludendo, è possibile dire che come metro di parametro è bene ricordasi che XML e .NET all’interno di un database nel 99% dei casi non servono: essi devono essere usati se e solo se il rapporto tra prestazioni, manutenibilità, costi e benefici è – sul medio/lungo periodo - vantaggioso; altrimenti continuate ad usare senza remore il "buon vecchio" T-SQL.
Integrazione
Un punto forte della piattaforma di Sql Server 2005 è dato dai Sql Server 2005 Integration Services (IS). Già il nome di tale servizio indica il suo dichiarato obbiettivo: l'integrazione.
In sistemi informatici che diventano via via sempre più complessi ed eterogenei una grossa sfida è rappresentata oggi dall'integrazione e dall'elaborazione di informazioni che arrivano in formati diversi, sistemi operativi diversi, tempi e quantità differenti, e via dicendo.
Gli IS permettono di creare in modo quasi totalmente visuale, tramite un editor dedicato, le regole con la quale questi dati, in modalità batch, devono essere prelevati, manipolati, gestiti, trasformati ed elaborati.
Da questo punto di vista, grazie anche alle notevoli possibilità di monitoring e di alerting implementabili, tale servizio può facilmente essere pensato (e diventare) un fulcro importante per ogni soluzione enterprise (e non) che per sua natura abbia la necessità di estrarre informazioni andando ad estrapolare/confrontare dati da diverse sorgenti; sorgenti che possono essere database (di qualsiasi vendor) ma anche Web Services, file Excel, flat-file e quant'altro.
La cosa particolarmente interessante è che ogni cosa appena detta è integrabile con applicazioni .NET sviluppate ad hoc in quanto ogni singola funzionalità è implementata attraverso un object model accessibile, programmabile ed estendibile che può essere pertanto sfruttato, di fatto, in ogni situazione in cui sia necessario dover lavorare in modalità batch dati eterogenei e - magari - poco "puliti". Pensiamo ad esempio a dati rappresentanti i feedback degli utenti di grosse società di elettronica di consumo. I dati arrivano nelle forme più disparate:
dal call-center inseriti dagli operatori tramite applicazioni ad hoc basate su access;
da file .csv riempiti da scanner OCR automatici che leggono i questionari distribuiti a fiere, nei prodotti e via dicendo;
da file excel forniti dai rivenditori al dettaglio che rappresentano informazioni di prodotti restituiti in quanto non funzionanti, danneggiati e via dicendo;
dal database della registrazione dei prodotti riempito direttamente dall'utente finale tramite il sito web della società;
dal database (Oracle, MySql, ecc...) della società appena acquistata.
Tutti questi dati, per poter fornire una base comune, coerente ed utilizzabile devono essere processati e resi omogenei. Perchè fare questo? Un esempio potrebbe essere legato a tematiche tipo CRM: come utente mi piacerebbe entrare nel sito della società di elettronica di consumo, vedere i prodotti che ho acquisto, vedere a che punto sono quelli che ho portato in riparazione, essere avvisato tempestivamente tramite e-mail se un prodotto viene ritirato dal mercato perchè difettoso, e via dicendo.
Dal punto di vista della società di elettronica di consumo, invece, sono molto interessato a sapere qual è il prodotto con più lamentele, quali sono le lamentele più frequenti, quali sono i feedback dei miei clienti, magari in relazioni a campagne pubblicitarie che sto facendo.
Per fare tutto questo è vitale avere dati coerenti e, tipicamente, ogni applicazione utilizzata per registrare tali dati avrà strutture di dati proprietarie, informazioni parziali o incomplete, e via dicendo. Utilizzando gli IS è possibile cercare di correggere, arricchire, consolidare e rendere accessibile in modo omogeneo dati che, altrimenti, avrebbero la loro utilità castrata almeno del 70%.
Reportistica & Analisi
L'ultimo punto, non certo per importanza, ancora da affrontare è quello dell'analisi dei dati e della reportistica, normalmente esigenze fortemente legate l'una all'altra.
Grazie a servizi come Analysis Server (AS) ed i Reporting Services (RS) la piattaforma di Sql Server 2005 copre abbondantemente quest'ultima necessità.
AS assicura che ogni singolo dato proveniente da qualsiasi fonte societaria possa essere confrontabile con qualsiasi altro dato, così da far emergere informazioni altrimenti nascoste: l'impatto di una partnership con un'altra società con le vendite di un prodotto, informazioni di geomarketing, la qualità della produzione di materie prime, il monitoraggio delle ore lavorative, ferie, permessi, malattie e via dicendo.
Il tutto, grazie a Reporting Services (che è un prodotto comunque slegato da Analysis Server e che funziona in maniera completamente autonoma), può essere convertito in un report PDF, EXCEL, oppure consultabile sulla intranet oppure ancora inviabile in modo automatico come allegato e-mail ogni mattina alle ore 8.30 nella casella postale di "n" destinatari.
La cosa sicuramente ottima di un prodotto come RS è che è - di fatto - "semplicemente" un web service (anzi, due). Cosa significa questo? Che può essere arbitrariamente integrato con applicazioni web e non, in modo totalmente invisibile all'utente finale, ideale quindi per lo sviluppo di applicazioni intranet o extranet, fornendo anche tutta la sicurezza necessaria per far si che solo le persone autorizzate possano vedere i report a loro dedicati.
Conclusione
Dopo questa breve carrellata sui singoli "prodotti" presenti nella piattaforma Sql Server 2005, un'idea di come e dove tali funzionalità possono essere utilizzate nel vostro ambito di lavoro credo che ve la siate fatta. Come tale, se l'introduzione ha stuzzicato il vostro interesse, non mancate di farcelo sapere così da poter dedicare ancora altro spazio a queste tematiche che, alla fine, credo riguardino un po' tutti. Ricollegandomi alle prime righe di questo articolo: quale applicazione può fare a meno di un database oggi?