13

Jun

Windows Azure – Strategie di Storage pt.2 – Partitioning orizzontale

Nel partizionamento orizzontale è necessario impostare una strategia di suddivisione del dato per blocchi “logici”. Con Azure Table Storage, il partitioning orizzonatale è automatico e esplicitamente delegato allo sviluppatore. Infatti la presenza del campo PartitionKey per ogni record, forza lo sviluppatore ad incasellare il record in una partizione logica: come poi Azure gestirà il tutto, non ci è dato sapere.

Chiaro è che con questo supporto all-inclusive al partizionamento, si deve per forza sviluppare una applicazione che, nonostante possa non essere efficente, perlomeno sia Partition-ready. Perchè potrebbe non essere efficente? Perchè si potrebbe salvare tutto in una sola partizione, anche quando i dati sarebbero comodamente divisibili.

Quali sono i pro e i contro del partitioning orizzonale dell’Azure Storage?

  • Pro:
    • Maggiore velocità nell’esecuzione delle query
    • Disponibilità di dati parziali nel caso di fallimenti hardware (seppur improbabili) o anomalie dovute al software su alcune partizioni
    • Gestione del bilanciamento nel caso di aumento del carico
  • Contro:
    • Le transazioni possono essere effettuate solo intra-partizione
    • Se vogliamo cancellare o riferire un record di cui non sappiamo più la partition key ma solo la RowKey, dobbiamo ciclare ogni partizione
    • Le query cross-partizione vengono eseguite sequenzialmente
      • Con un pattern molto elegante fondato sui Continuation Tokens
      • Bisogna fare estrema attenzione a non fare query che attraversino troppi server

Come viene gestito il partitioning orizzontale in SQL Azure?

Non viene gestito. Nella logica dell’applicazione si deve impostare una qualche euristica per salvare il dato in una data partizione (che sarà di fatto un separato database SQL Azure). Chiaramente prima di affrontare il partizionamento con SQL Azure va considerato che i costi sono direttamente proporzionali al numero di partizioni coinvolte e che bisogna trovare una buona (possibilmente ottimale) soluzione per il forwarding dei dati sui diversi database (altrimenti il partizionamento sarebbe fallimentare). L’unica situazione in cui il partizionamento è d’obbligo è quando il DB deve crescere più di 50GB, che è la dimensione massima oggi consentita per un DB SQL Azure.

Le scelta della chiave di partizione può essere così un problema di ottimizzazione:

  • Chiavi naturali basate sui dati?
    • Paese nel caso di una anagrafica
    • Data nel caso di transazioni numerose
  • Chiavi matematiche?
    • Funzioni di hash sub-ottime
    • Resto della divisione

In ogni caso poi bisogna gestire l’indice, o la tabella di Lookup, per risolvere l’indirizzamento nelle partizioni corrette e per gestire i cambiamenti dei dati nelle partizioni (per esempio dopo una ridistribuzione dei dati in seguito a manutenzione).

by Roberto Freato on 6/13/2011
Post archive