Mi sono assentato per in certo periodo in quanto aspettavo un buon momento per poter parlare di SDS (SQL Data Services). Purtroppo, non ne posso ancora parlare e quindi mi invento un'altro argomento, comunque fondamentale.
Una delle caratteristiche peculiari dello storage nel cloud e' quella di poter scalare, potenzialmente scalare indefinitivamente. Fino a qualche anno fa, scalare il database significava aggiungere dischi, e se la potenza di calcolo non era sufficiente, aggiungere nodi al cluster. Non vi e' dubbio che scalare con un cluster, oltre ad incrementare i costi esponenzialmente, presenta comunque un limite fisico oltre al quale non si puo' crescere.
Google, sin dalla sua prima comparsa, ha introdotto il concetto di scalabilita' usando un hardware di basso costo. SDS, cosi' come altre soluzioni, stanno cavalcando la stessa idea. Ma come fanno a scalare un database linearmente mantenendo i costi accettabili.
La soluzione si basa su due aspetti importanti:
- Partizionamento dei dati
- Replica
Immaginiamo che un singolo data server (SQL Server) sia in grado di gestire 10GB di dati. Bene, se dovete gestire 25GB di dati vi serviranno 3 data server e farete in modo di spalmare i dati fra i tre server, possibilmente in modo uniforme.
Avere un singolo server, nodo, ci espone di fronte ad un singolo punto di fallimento. Ecco che quindi entra in gioco la replica. In altre parole i dati potranno essere replicati su altri server in modo che se uno di questi fallisce, l'altro compensa.
Questa semplice tecnica permette servizi come Microsoft SDS, Amazon Simple DB ed altri, di poter fornire il servizio del database a basso costo e con grande livello di affidabilita'. Nel caso particolare di SDS, Microsoft garantisce 3 copie dei dati per ogni partizione.
Per ora mi fermo qui, in un prossimo futuro entrero' meglio nei dettagli del partizionamento in quanto ha un impatto diretto su come si scrivono le applicazioni.