22

Sep

Windows Azure – SQL Azure, concetti avanzati

Con il cloud l’utente decide di delegare sì la gestione dell’infrastruttura, ma anche di abbracciare idee come l’alta affidabilità e l’alta scalabilità intrinsecamente offerte da una struttura altamente ridondata come quella del Cloud Computing. Per quanto riguarda SQL Azure, esso sovrasta una tecnologia già matura (SQL Server HA) ospitata nei datacenters di Microsoft. Mi permetto quindi di dire che l’HA è garantita. E per quanto riguarda la scalabilità? Esistono due modi di scalare in SQL Azure: in dimensione (scale up) e in numero di databases (scale-out).

Scale up

Nell’approccio Scale up, quando dovesse essere necessario un DB più grande, potrei crescere in dimensione (cone una semplice query T-SQL apposita) e avrei risolto. Chiaramente va considerato il problema del costo legato alle grandi istanze (passiamo presto da un ordine di grandezza ad un altro, con pochi GB di differenza), ma è anche la soluzione più comoda. Tuttavia quello che capita è che spesso, per esempio passando da un database di 1GB ad uno di 5GB, non si occupi tutto lo spazio e che magari rimanga spazio libero per mesi se non anni.

Supponiamo infatti di avere una soluzione di prenotazioni online con crescita lineare. Ogni giorno si aggiungono T tuple alla tabella prenotazioni e il giorno K il DB raggiunge la dimensione di 990MB. Sotto queste ipotesi non è difficile cosiderare che probabilmente il nuovo DB da 5GB verrà saturato in un tempo pari a 5K, per cui se K è un anno, abbiamo circa 4 anni di sottoutilizzo di un database che ci costa parecchio.

Scale-out

Per i motivi sopra potremmo decidere di non scalare in dimensione ma in numero di DB concomitanti. Nell’esempio sopra, al saturarsi di un DB delle prenotazioni, se ne può generare un’altro identico e, per esempio, far scrivere i nuovi dati sul nuovo DB. C’è inoltre da considerare che, tolto l’effort amministrativo sicuramente maggiore che nel caso di Scale-up, N servers sono meglio di uno, sia in termini di affidabilità che di velocità di esecuzione delle query. Diverso è invece l’approccio nel caso in cui ci siano picchi di utilizzo ben delineabili e/o nel caso in cui la curva della crescita dei dati non fosse lineare. In tal caso vanno considerati bene tutti i fattori e valutate le varie soluzioni (anche quelle ibride) che abbiano un miglior rapporto benefici/costi.

Sharding pattern

Nel caso di una applicazione multi-tenant, possiamo pensare ad un DB per ogni tenant, oppure ad un singolo DB per tutti. Altrimenti possiamo adottare una soluzione ibrida a patto di rivedere/modificare alcune scelte dell’architettura del software ed implementare un pattern sharding sulla base dati. In pattern sharding è in sostanza un approccio ibrido in cui si utilizza un pool di Database (locali o su Cloud) per la persistenza/accesso ai dati. A patto di implementare necessari accorgimenti applicativi, il pattern prevede poi di assorbire la crescita delle destinazioni dati in modo trasparente, sempre facendo le opportune supposizioni in merito alle strategie di routing delle connessioni e delle query.

Nota: nel 2011 è previsto che SQL Server preveda una strategia di sharding, nativamente.

Quando sarà disponibile, ci sarà il concetto di Federazione. Una SQL Azure federation è un insieme SQL Azure a cui si applica sharding in base ad un particolare discriminante che prenderà ill nome di Federation Key. Ci sarà una Federation Root che si occuperà di contenere la directory di tutta la federazione e ogni Member avrà delle singole AU (Atomic Unit) che saranno partizionate in base alla Federation Key.

image

Esempi:

image

by Roberto Freato on 9/22/2011
Post archive