Linee guida sulla pianificazione di federazioni di server database
La creazione di una federazione di server database richiede la progettazione di un set di viste partizionate distribuite che trasmetta i dati ai server. Il partizionamento offre risultati soddisfacenti se le tabelle del database sono naturalmente divisibili in partizioni analoghe in cui la maggior parte delle righe a cui accede qualsiasi istruzione SQL può essere posizionata sullo stesso server membro. Le tabelle sono suddivise in unità correlate. Si supponga, ad esempio, che la voce relativa a un ordine faccia riferimento alle tabelle Orders, Customers e Parts, nonché a tutte le tabelle in cui vengono registrate le relazioni tra clienti, ordini e parti. Le partizioni producono risultati ottimali se tutte le righe di un cluster logico possono essere posizionate nello stesso server membro.
Partizioni simmetriche
L'efficienza del partizionamento è ottimale quando le tabelle del database possono essere partizionate simmetricamente, nel modo seguente:
I dati correlati vengono posizionati sullo stesso server membro in modo che la maggior parte delle istruzioni SQL distribuite al server membro appropriato debba fare ricorso solo in misura minima ad altri server membri. Nel progettare una vista partizionata distribuita, è possibile definire come obiettivo una proporzione "80/20", ovvero è consigliabile progettare le partizioni in modo che la maggioranza delle istruzioni SQL possano essere reindirizzate a un server membro, in cui almeno l'80% dei dati si trovi su tale server e le query distribuite siano necessarie al massimo per il 20% dei dati. Per determinare se questo obiettivo è realistico, è possibile verificare se la partizione consente il posizionamento di tutte le righe nello stesso server membro in cui sono archiviate tutte le righe di riferimento della chiave esterna corrispondente. I database progettati in modo da raggiungere questo obiettivo sono i migliori candidati per il partizionamento.
I dati vengono partizionati uniformemente nei server membri.
Si supponga, ad esempio, che una società abbia suddiviso il Nord America in diverse aree. Ogni dipendente opera in un'area specifica e i clienti effettuano la maggior parte degli acquisti nello stato o nella regione di residenza. Le tabelle relative alle aree e ai dipendenti vengono partizionate in base alle aree, mentre i clienti vengono partizionati tra le diverse aree in base allo stato o alla regione di residenza. Può succedere che alcune query richiedano dati da più aree, ma i dati necessari per la maggior parte delle query sono in genere disponibili nel server specifico di una determinata area. Le applicazioni inviano le istruzioni SQL al server membro che include l'area desunta dal contesto dell'input dell'utente.
Partizioni asimmetriche
Anche se le partizioni simmetriche rappresentano l'obiettivo ideale, la maggior parte delle applicazioni prevedono modelli complessi di accesso ai dati che impediscono il partizionamento simmetrico. Le partizioni asimmetriche fanno sì che alcuni server membri assumano ruoli più ampi di altri. Ad esempio, solo alcune tabelle del database possono essere partizionate, e quelle non partizionate rimangono nel server originale. Le partizioni asimmetriche consentono di ottenere prestazioni analoghe a quelle delle partizioni simmetriche, ma con alcuni importanti vantaggi:
Un miglioramento significativo delle prestazioni di un database che non può essere partizionato in modo simmetrico, grazie al partizionamento asimmetrico di alcune tabelle di tale database.
Un partizionamento efficiente di un sistema esistente di grandi dimensioni grazie a una serie di operazioni iterative di partizionamento asimmetrico. Le tabelle selezionate per il partizionamento in ogni fase sono in genere quelle che in quel momento offrono i vantaggi più significativi in termini di prestazioni.
Nell'ambito di uno schema di partizionamento asimmetrico, rimangono in genere archiviate nel server originale alcune tabelle non adeguabili allo schema stesso. Le prestazioni delle tabelle rimanenti in genere sono migliori di quelle del sistema originale in quanto le tabelle membro vengono spostate nei server membri, riducendo in tal modo il carico del server originale.
Molti database possono essere partizionati in più modi. La scelta della modalità di implementazione si basa sull'identificazione delle partizioni che soddisfano al meglio i requisiti della normale gamma di istruzioni SQL eseguite dal livello dei servizi aziendali.