Database Sharding e MapReduce per lo scaling del data tier
La scalabilità delle applicazioni è un problema sentito in questi tempi di distribuzioni dei servizi tramite Web Services; molto spesso il successo di un’applicazione si misura sulla quantità di utenti che la utilizza e di dati che gestisce.
Nello scaling di una applicazione ci si può imbattere nel collo di bottiglia del data tier; nonostante le ottimizzazioni dell’applicazione (ad esempio l’ottimizzazione delle query) e delle modalità di visualizzazione dei dati (caching, ristrutturazione dell’interfaccia grafica per visualizzare solo i dati indispensabili) i dati gestiti dall’applicativo sono cresciuti al punto che il DBMS risponde troppo lentamente alle richieste inviate.
Soluzioni tradizionali
Una prima opzione prevede di norma il riservare al DBMS una quantità maggiore di risorse hardware, ad esempio spostandolo su un server dedicato oppure corredando il server che lo ospita di più RAM o maggiore potenza di calcolo.
Una seconda opzione prevede invece l’utilizzo, improprio ma ingegnoso, del database replication per mettere a disposizione del logic tier due database distinti, magari su server differenti, su cui smistare le query. In questo modo il carico dovuto all’estrazione dei dati viene diviso su più server ed è quindi possibile contare su prestazioni migliori.
Limiti delle soluzioni tradizionali
Entrambe le opzioni sono valide ma possono dimostrare le proprie debolezze a fronte di alcune considerazioni in più delle volte valide:
- Non è economicamente conveniente costruire subito una infrastruttura che permetta di gestire un’alta mole di dati - Secondo le previsioni l’applicazione si troverà a gestire n dati entro due anni, e ci dotiamo di una infrastruttura che supporti quella mole di dati; come conseguenza ci troviamo a sostenere i costi di realizzazione e di manutenzione di questa infrastruttura fin dal primo giorno, e nel caso le previsioni siano corrette al ribasso ci troveremo ad avere un’infrastruttura sovradimensionata.
- Non è economicamente conveniente procedere al refactoring di una infrastruttura informatica, e i tempi di refactoring sono spesso superiori ai tempi entro i quali si deve procedere allo scaling dell’applicazione
- La quantità di dati che l’applicazione si trova a dover gestire non è facilmente prevedibile
- Il tasso di crescita della quantità di dati è variabile, e potrebbe registrare delle “impennate”
- Il successo dell’applicazione ha come causa diretta la crescita della mole di dati gestiti
Le soluzioni tradizionali si mostrano inadeguate a fronteggiare questo tipo di situazioni; si deve quindi ricorrere a soluzioni alternative che abbiano dimostrato nella pratica la propria validità.
Database Sharding e MapReduce: caratteristiche comuni
Entrambe le soluzioni hanno la caratteristica di non considerare il data tier come un’entità atomica. Se è vero che un DBMS può risiedere su una sola macchina, allora i dati gestiti devono essere divisi e distribuiti su più DBMS, e quindi potenzialmente su più server. La libertà di poter distribuire i dati su server differenti permette al singolo server di gestire una quantità di dati minore, e quindi di essere maggiormente performante.
Una seconda caratteristica comune alle due soluzioni è prevedere una infrastruttura elastica in cui è possibile aggiungere, togliere o sosituire un componente senza compromettere il funzionamento complessivo dell’infrastruttura.
Come conseguenza delle due caratteristiche esposte, l’adozione di soluzioni Database Sharding e MapReduce permettono l’utilizzo di commodity hardware, ovvero di componenti a basso costo, abbattendo i costi totali di realizzazione dell’infrastruttura.
Database Sharding: dividere i dati in sottodomini
La tecnica del Database Sharding prevede l’individuazione di porzioni indipendenti di dati e la sistemazione delle diverse porzioni su diversi database. Prendiamo ad esempio un’applicazione per l’inserimento delle fatture emesse dalle aziende; ogni azienda ha le proprie fatture e non è prevista la combinazione delle fatture introdotte da aziende differenti.
L’infrastruttura mette a disposizione 2 server; per semplicità, tutte le aziende con partita IVA dispari verranno dirottate sul primo server, insieme alle relative fatture, mentre le aziende con partita IVA dispari vengono dirottate sul secondo.
Quando l’applicazione avrà necessità di accedere alle fatture di un’azienda con partita IVA pari, invierà le proprie richieste esclusivamente al secondo server; al contrario per le partite IVA dispari esclusivamente al primo.
MapReduce: distribuire dati e computazione perifericamente
Se il Database Sharding ha la necessità di individuare porzioni indipendenti di dati, MapReduce distribuisce le entry che ha da gestire su server differenti senza porre questo vincolo; per continuare con il nostro esempio precedente, parte delle fattura della prima azienda saranno custodite nel primo server, e parte nel secondo.
Questo tipo di approccio garantisce senza dubbio una libertà maggiore, ma ci pone di fronte al problema del recupero dei dati.
Se l’applicazione richiede l’estrazione di tutte le fatture della prima azienda, questa richiesta dovrà essere propagata ad entrambi i server che abbiamo in dotazione; questi dovranno estrarre da tutte le fatture che custodiscono, quelle della prima azienda e quindi comunicarle all’applicazione. L’applicazione infine procederà a combinare i dati che gli sono pervenuti per ottenere il risultato finale.
22 Agosto 2007
Categorie: Database, Soluzioni, Ricerca
Articoli simili