Strategie di partizionamento dei dati (creazione di app cloud Real-World con Azure)

di Rick Anderson, Tom Dykstra

Scaricare Fix It Project o Scaricare E-book

L'e-book Building Real World Cloud Apps with Azure si basa su una presentazione sviluppata da Scott Guthrie. Illustra 13 modelli e procedure che consentono di sviluppare correttamente app Web per il cloud. Per informazioni sulla serie, vedere il primo capitolo.

In precedenza si è visto quanto sia facile ridimensionare il livello Web di un'applicazione cloud aggiungendo e rimuovendo server Web. Tuttavia, se stanno raggiungendo lo stesso archivio dati, il collo di bottiglia dell'applicazione passa dal front-end al back-end e il livello dati è il più difficile da ridimensionare. In questo capitolo viene illustrato come rendere scalabile il livello dati partizionando i dati in più database relazionali o combinando l'archiviazione di database relazionali con altre opzioni di archiviazione dei dati.

La configurazione di uno schema di partizionamento viene eseguita in anticipo per lo stesso motivo indicato in precedenza: è molto difficile modificare la strategia di archiviazione dei dati dopo che un'app è in produzione. Se si pensa duramente a diversi approcci, è possibile evitare di avere un "momento twitter" quando l'app si arresta in modo anomalo o si arresta per molto tempo mentre si riorganizzano i dati e il codice di accesso ai dati dell'app.

Tre vs di archiviazione dei dati

Per determinare se è necessaria una strategia di partizionamento e ciò che dovrebbe essere, considerare tre domande sui dati:

• Volume: quanti dati verranno archiviati? Un paio di gigabyte? Un paio di centinaia di gigabyte? Terabyte? Petabyte?
• Velocità: qual è la velocità con cui cresceranno i dati? Si tratta di un'app interna che non genera molti dati? Un'app esterna in cui i clienti caricheranno immagini e video?
• Varietà: quale tipo di dati archiviare? Relazionali, immagini, coppie chiave-valore, grafici sociali?

Se pensi di avere un sacco di volume, velocità o varietà, devi considerare attentamente quale tipo di schema di partizionamento consentirà all'app di ridimensionare in modo efficiente ed efficace man mano che cresce e per assicurarti di non riscontrare colli di bottiglia.

Esistono fondamentalmente tre approcci al partizionamento:

• Il partizionamento verticale
• Partizionamento orizzontale
• Partizionamento ibrido

Il partizionamento verticale

Il partizionamento verticale è simile alla suddivisione di una tabella per colonne: un set di colonne viene inserito in un archivio dati e un altro set di colonne viene inserito in un archivio dati diverso.

Si supponga, ad esempio, che l'app archivia i dati relativi alle persone, incluse le immagini:

Quando si rappresentano questi dati come tabella e si esaminano le diverse varietà di dati, è possibile notare che le tre colonne a sinistra hanno dati stringa che possono essere archiviati in modo efficiente da un database relazionale, mentre le due colonne a destra sono essenzialmente matrici di byte provenienti dai file di immagine. È possibile archiviare i dati dei file di immagine in un database relazionale e molte persone lo fanno perché non vogliono salvare i dati nel file system. Potrebbero non avere un file system in grado di archiviare i volumi di dati necessari o di non voler gestire un sistema di backup e ripristino separato. Questo approccio funziona bene per i database locali e per piccole quantità di dati nei database cloud. Nell'ambiente locale, potrebbe essere più semplice lasciare che l'amministratore del database si occupi di tutto.

Tuttavia, in un database cloud, l'archiviazione è relativamente costosa e un volume elevato di immagini potrebbe aumentare le dimensioni del database oltre i limiti a cui può operare in modo efficiente. È possibile risolvere questi problemi partizionando i dati in verticale, quindi si sceglie l'archivio dati più appropriato per ogni colonna della tabella dei dati. Ciò che potrebbe funzionare meglio per questo esempio consiste nell'inserire i dati stringa in un database relazionale e nelle immagini nell'archivio BLOB.

L'archiviazione di immagini nell'archiviazione BLOB invece di un database è più pratica nel cloud che in un ambiente locale perché non è necessario preoccuparsi di configurare file server o gestire il backup e il ripristino dei dati archiviati all'esterno del database relazionale: tutto ciò che viene gestito automaticamente dal servizio di archiviazione BLOB.

Questo è l'approccio di partizionamento implementato nell'app Fix It e verrà esaminato il codice nel capitolo Archiviazione BLOB. Senza questo schema di partizionamento e presupponendo una dimensione media dell'immagine di 3 megabyte, l'app Fix It può archiviare solo circa 40.000 attività prima di raggiungere le dimensioni massime del database di 150 gigabyte. Dopo aver rimosso le immagini, il database può archiviare 10 volte il numero di attività; è possibile andare molto più a lungo prima di dover pensare all'implementazione di uno schema di partizionamento orizzontale. E man mano che l'app aumenta, le spese aumentano più lentamente perché la maggior parte delle esigenze di archiviazione entrano in un archivio BLOB molto economico.

Partizionamento orizzontale (sharding)

Il partizionamento orizzontale è simile alla suddivisione di una tabella per righe: un set di righe viene inserito in un archivio dati e un altro set di righe viene inserito in un archivio dati diverso.

Dato lo stesso set di dati, un'altra opzione consiste nell'archiviare intervalli diversi di nomi dei clienti in database diversi.

Si vuole prestare molta attenzione allo schema di partizionamento orizzontale per assicurarsi che i dati vengano distribuiti in modo uniforme per evitare punti caldi. Questo semplice esempio che usa la prima lettera del cognome non soddisfa tale requisito, perché molte persone hanno cognome che iniziano con alcune lettere comuni. È possibile raggiungere le limitazioni delle dimensioni della tabella prima di quanto ci si potrebbe aspettare perché alcuni database potrebbero ottenere dimensioni molto grandi, mentre la maggior parte rimane piccola.

Un lato inferiore del partizionamento orizzontale è che potrebbe essere difficile eseguire query su tutti i dati. In questo esempio, una query deve disegnare da un massimo di 26 database diversi per ottenere tutti i dati archiviati dall'app.

Partizionamento ibrido

È possibile combinare il partizionamento verticale e orizzontale. Ad esempio, nei dati di esempio è possibile archiviare le immagini nell'archivio BLOB e partizionare orizzontalmente i dati della stringa.

Partizionamento di un'applicazione di produzione

Concettualmente è facile vedere come funziona uno schema di partizionamento, ma qualsiasi schema di partizionamento aumenta la complessità del codice e introduce molte nuove complicazioni da gestire. Se si spostano immagini nell'archivio BLOB, cosa si fa quando il servizio di archiviazione è inattivo? Come si gestisce la sicurezza dei BLOB? Cosa accade se il database e l'archiviazione BLOB non vengono sincronizzati? Se si esegue il partizionamento orizzontale, come verrà gestita l'esecuzione di query in tutti i database?

Le complicazioni sono gestibili fino a quando si sta pianificando per loro prima di passare alla produzione. Molte persone che non lo volevano più tardi. In media, il team di Customer Advisory Team (CAT) riceve chiamate telefoniche in panico circa una volta al mese dai clienti le cui app si stanno togliendo in modo molto grande e non hanno fatto questa pianificazione. E dicono qualcosa di simile: "Aiuto! Ho messo tutto in un unico archivio dati, e in 45 giorni sto per esaurire spazio su di esso!" Inoltre, se si dispone di una grande logica di business integrata nel modo in cui si accede all'archivio dati e si hanno clienti che usano l'app, non è consigliabile scendere per un giorno durante la migrazione. Finiamo per cercare di aiutare il cliente a partizionare i dati in tempo reale senza tempi di inattività. È molto emozionante e molto spaventoso, e non qualcosa che si vuole essere coinvolto se si può evitare! Pensando a questo aspetto iniziale e integrandolo nella tua app, la tua vita sarà molto più semplice se l'app crescerà in un secondo momento.

Riepilogo

Uno schema di partizionamento efficace può consentire all'app cloud di ridimensionare in petabyte di dati nel cloud senza colli di bottiglia. E non è necessario pagare in anticipo per macchine di grandi dimensioni o un'infrastruttura estesa, come si potrebbe se si esegue l'app in un data center locale. Nel cloud è possibile aggiungere in modo incrementale la capacità in base alle esigenze e si paga solo per quanto si usa quando viene usata.

Nel capitolo successivo si vedrà come l'app Fix It implementa il partizionamento verticale archiviando le immagini nell'archivio BLOB.

Risorse

Per altre informazioni sulle strategie di partizionamento, vedere le risorse seguenti.

Documentazione:

• Procedure consigliate per la progettazione di servizi di Large-Scale in Windows Azure Servizi cloud. White paper di Mark Simms e Michael Thomassy.
• Modelli e procedure Microsoft - Modelli di progettazione cloud. Vedere Linee guida sul partizionamento dei dati, modello di partizionamento orizzontale.

Video:

• FailSafe: creazione di Servizi cloud scalabili e resilienti. Serie in nove parti di Esegue homann, Marc Mercuri e Mark Simms. Presenta concetti di alto livello e principi architetturali in modo molto accessibile e interessante, con storie tratte dall'esperienza cat (Customer Advisory Team) microsoft con i clienti effettivi. Vedere la discussione sul partizionamento nell'episodio 7.
• Creazione di grandi dimensioni: lezioni apprese dai clienti di Windows Azure - Parte I. Mark Simms illustra gli schemi di partizionamento, le strategie di partizionamento orizzontale, come implementare il partizionamento orizzontale e database SQL le federazione, a partire dalle 19:49. Analogamente alla serie Failsafe, ma vengono fornite altre procedure.

Codice di esempio:

• Nozioni fondamentali sul servizio cloud in Windows Azure. Applicazione di esempio che include un database partizionato. Per una descrizione dello schema di partizionamento orizzontale implementato, vedere DAL - Partizionamento orizzontale di RDBMS nel blog di Windows Azure.

IndietroAvanti