Suggerimenti per il partizionamento dei dati

Articolo
11/15/2023

Si applica a questa raccomandazione per l'affidabilità del framework ben progettato di Azure:

RE:06	Implementare una strategia di scalabilità tempestiva e affidabile a livello di applicazione, dati e infrastruttura.

Guida correlata: Ridimensionamento

Questa guida descrive le raccomandazioni per la progettazione di una strategia di partizionamento dei dati per la tecnologia di archiviazione dei dati e del database distribuita. Questa strategia consente di migliorare l'affidabilità del patrimonio di dati.

Strategie di progettazione chiave

In molte soluzioni su larga scala, le partizioni vengono usate per dividere i dati in modo che possano essere gestiti e accessibili separatamente. Il partizionamento dei dati migliora la scalabilità, riduce la contesa e ottimizza le prestazioni. Implementare il partizionamento dei dati per dividere i dati in base al modello di utilizzo. Ad esempio, è possibile archiviare i dati meno recenti in un archivio dati poco costoso. Scegliere attentamente la strategia di partizionamento per massimizzare i vantaggi e ridurre al minimo gli effetti negativi.

Nota

In questo articolo il termine partizionamento si riferisce al processo di suddivisione fisica dei dati in archivi dati separati. Differisce dal partizionamento delle tabelle di SQL Server.

È possibile partizionare i dati in:

Migliorare la scalabilità. Quando si aumentano le prestazioni di un singolo sistema di database, il database raggiunge infine un limite hardware fisico. Se si dividono i dati tra più partizioni, con ogni partizione ospitata in un server separato, è possibile aumentare il numero di istanze del sistema quasi indefinito.
Miglioramento delle prestazioni. In ogni partizione, le operazioni di accesso ai dati vengono eseguite su un volume di dati inferiore rispetto ai dati non partizionati. Partizionare i dati per rendere il sistema più efficiente. Le operazioni che interessano più di una partizione possono essere eseguite in parallelo.
Migliorare la sicurezza. In alcuni casi, è possibile separare i dati sensibili e senza distinzione in partizioni diverse e applicare controlli di sicurezza diversi ai dati sensibili.
Fornire flessibilità operativa. È possibile partizionare i dati per ottimizzare le operazioni, ottimizzare l'efficienza amministrativa e ridurre al minimo i costi. Ad esempio, è possibile definire strategie per la gestione, il monitoraggio, il backup e il ripristino e altre attività amministrative in base all'importanza dei dati in ogni partizione.
Combinare l'archivio dati al modello di utilizzo. È possibile distribuire ogni partizione in un tipo diverso di archivio dati in base al costo e alle funzionalità predefinite offerte dall'archivio dati. Ad esempio, è possibile archiviare dati binari di grandi dimensioni nell'archivio BLOB e archiviare dati strutturati in un database di documenti. Per altre informazioni, vedere Informazioni sui modelli di archivio dati.
Migliorare la disponibilità. Per evitare un singolo punto di errore, è possibile separare i dati tra più server. In caso di problemi in un'istanza, risultano non disponibili solo i dati in tale partizione. Le operazioni continuano in altre partizioni. Questa considerazione è meno rilevante per gli archivi dati PaaS (Managed Platform as a Service) perché hanno ridondanza predefinita.

Selezionare la strategia di partizionamento corretta

Per il partizionamento dei dati esistono tre strategie tipiche:

Il partizionamento orizzontale (spesso chiamato sharding). In questa strategia, ogni partizione è un archivio dati separato, ma tutte le partizioni hanno lo stesso schema. Ogni partizione è nota come partizione e contiene un subset dei dati, ad esempio un set di ordini cliente.
Il partizionamento verticale. In questa strategia ogni partizione contiene un sottoinsieme dei campi per gli elementi nell'archivio dati. I campi sono suddivisi in base ai loro modello di utilizzo. I campi usati di frequente ad esempio possono essere collocati in una partizione verticale, mentre i campi usati raramente possono essere collocati in un'altra partizione.
Partizionamento funzionale. In questa strategia i dati vengono aggregati in base al modo in cui ogni contesto delimitato nel sistema usa i dati. Un sistema di e-commerce, ad esempio, potrebbe archiviare i dati delle fatture in una partizione e quelli relativi all'inventario dei prodotti in un'altra.

Valutare la possibilità di combinare queste strategie quando si progetta uno schema di partizionamento. Ad esempio, si potrebbe dividere i dati in partizioni e quindi utilizzare il partizionamento verticale per suddividere ulteriormente i dati in ogni partizione.

Partizionamento orizzontale (sharding)

L'immagine seguente mostra un esempio di partizionamento orizzontale o partizionamento orizzontale. Questo esempio divide i dati di inventario dei prodotti in partizioni basate sul codice Product Key. Ogni partizione contiene i dati per un intervallo contiguo di chiavi di partizione (A-G e H-Z), organizzati in ordine alfabetico. Quando si esegue il partizionamento orizzontale, il carico viene distribuito su più computer, riducendo così la contesa e migliorando le prestazioni.

Il fattore più importante è la chiave di partizionamento orizzontale scelta. Può essere difficile modificare la chiave quando il sistema è in esecuzione. La chiave deve garantire che i dati siano partizionati in modo che la distribuzione del carico di lavoro tra le partizioni sia il più uniforme possibile.

Non è necessario che le partizioni siano di uguali dimensioni. È più importante bilanciare il numero di richieste. Alcune partizioni potrebbero essere di grandi dimensioni, ma ogni elemento nella partizione ha un numero ridotto di operazioni di accesso. Altre partizioni potrebbero essere più piccole, ma ogni elemento nella partizione è accessibile più frequentemente. È anche importante assicurarsi che una singola partizione non superi i limiti di scalabilità, in termini di capacità ed elaborazione delle risorse, dell'archivio dati.

Evitare di creare partizioni ad accesso frequente che possono influire sulle prestazioni e sulla disponibilità. Ad esempio, se si usa la prima lettera del nome di un cliente, può creare una distribuzione sbilanciata perché alcune lettere sono più comuni di altre. Usare invece un hash dell'identificatore cliente per distribuire i dati in modo uniforme tra le partizioni.

Scegliere una chiave di partizionamento orizzontale che riduce al minimo la necessità futura di suddividere partizioni di grandi dimensioni, combinare piccole partizioni in partizioni più grandi o modificare lo schema. Queste operazioni richiedono molto tempo e potrebbero richiedere la modalità offline di una o più partizioni.

Se le partizioni vengono replicate, è possibile mantenere online alcune delle repliche mentre altre vengono suddivise, unite o riconfigurate. Tuttavia, il sistema potrebbe limitare le operazioni che possono essere eseguite durante la riconfigurazione. Ad esempio, i dati nelle repliche potrebbero essere contrassegnati come di sola lettura per evitare incoerenze dei dati.

Per altre informazioni, vedere Modello di partizionamento orizzontale.

Il partizionamento verticale

L'uso più comune per il partizionamento verticale consiste nel ridurre i costi di I/O e prestazioni associati al recupero di elementi a cui si accede di frequente. L'immagine seguente mostra un esempio di partizionamento verticale. Nell'esempio, le diverse proprietà di un elemento vengono archiviate in partizioni diverse. Una partizione contiene i dati a cui si accede più frequentemente, inclusi il nome del prodotto, la descrizione e il prezzo. Un'altra partizione contiene i dati di inventario, inclusi il conteggio delle scorte e l'ultima data ordinata.

In questo esempio, l'applicazione esegue regolarmente query sul nome, la descrizione e il prezzo del prodotto quando visualizza i dettagli del prodotto ai clienti. Il conteggio delle scorte e l'ultima data ordinata si trovano in una partizione separata perché questi due articoli vengono comunemente usati insieme.

Vedere i vantaggi seguenti del partizionamento verticale:

È possibile separare i dati a spostamento relativamente lento (nome del prodotto, descrizione e prezzo) da dati più dinamici (livello di magazzino e data dell'ultima ordinamento). I dati a spostamento lento sono un buon candidato per un'applicazione nella cache in memoria.
È possibile archiviare dati sensibili in una partizione separata con controlli di sicurezza aggiunti.
Il partizionamento verticale può ridurre il numero di accessi simultanei necessario.

Il partizionamento verticale opera a livello di entità all'interno di un archivio dati, normalizzando parzialmente un'entità per suddividerla da un elemento di grandi dimensioni a una raccolta di elementi di dimensioni ridotte. È ideale per gli archivi dati orientati alle colonne, ad esempio HBase e Cassandra. Se è improbabile che i dati in una raccolta di colonne cambino, è consigliabile usare gli archivi di colonne in SQL Server.

Partizionamento funzionale

Quando è possibile identificare un contesto delimitato per ogni area aziendale distinta in un'applicazione, il partizionamento funzionale può migliorare le prestazioni di isolamento e accesso ai dati. Un altro uso comune del partizionamento funzionale è la separazione dei dati di lettura/scrittura dai dati di sola lettura. L'immagine seguente mostra una panoramica del partizionamento funzionale con dati di inventario separati dai dati dei clienti.

Questa strategia di partizionamento può contribuire a ridurre i conflitti di accesso ai dati in diverse parti del sistema.

Progettare partizioni per la scalabilità

È fondamentale considerare le dimensioni e il carico di lavoro per ogni partizione. Bilanciarli in modo che i dati vengano distribuiti per ottenere la massima scalabilità. È tuttavia necessario partizionare anche i dati in modo che non superino i limiti di scalabilità di un singolo archivio di partizioni.

Seguire questa procedura quando si progettano partizioni per la scalabilità:

Analizzare l'applicazione per comprendere i modelli di accesso ai dati, ad esempio le dimensioni del set di risultati restituito da ogni query, la frequenza di accesso, latenza intrinseca e i requisiti di elaborazione del calcolo lato server. In molti casi, alcune entità principali richiedono la maggior parte delle risorse di elaborazione.
Usare questa analisi per determinare gli obiettivi di scalabilità correnti e futuri, ad esempio le dimensioni dei dati e il carico di lavoro. Distribuire i dati nelle partizioni in modo da soddisfare l'obiettivo di scalabilità. Per il partizionamento orizzontale, scegliere la chiave di partizione corretta per garantire la distribuzione uniforme. Per altre informazioni, vedere Modello di partizionamento orizzontale.
Assicurarsi che ogni partizione disponga di risorse sufficienti per gestire i requisiti di scalabilità in termini di dimensioni e velocità effettiva dei dati. A seconda dell'archivio dati, potrebbe essere previsto un limite per ogni partizione per la quantità di spazio di archiviazione, la potenza di elaborazione o la larghezza di banda di rete. Se è probabile che i requisiti superino questi limiti, potrebbe essere necessario perfezionare la strategia di partizionamento o suddividere ulteriormente i dati. Potrebbe essere necessario combinare due o più strategie.
Monitorare il sistema per verificare che i dati vengano distribuiti come previsto e che le partizioni possano gestire il carico. L'utilizzo effettivo non corrisponde sempre a quello previsto da un'analisi. Potrebbe essere necessario ribilanciare le partizioni o riprogettare alcune parti del sistema per ottenere il saldo necessario.

Alcuni ambienti cloud allocano risorse in base ai limiti dell'infrastruttura. Assicurarsi che i limiti del limite selezionato forniscano spazio sufficiente per la crescita prevista del volume di dati, dell'archiviazione dei dati, della potenza di elaborazione e della larghezza di banda.

Ad esempio, se si usa Archiviazione tabelle di Azure, esiste un limite al volume di richieste che una singola partizione può gestire in un determinato periodo di tempo. Per altre informazioni, vedere Obiettivi di scalabilità e prestazioni per gli account di archiviazione standard. Una partizione occupata potrebbe richiedere una quantità di risorse superiore a quella che può essere gestita da una singola partizione. Potrebbe essere necessario ripartizionare la partizione per distribuire il carico. Se le dimensioni totali o la velocità effettiva di queste tabelle superano la capacità di un account di archiviazione, potrebbe essere necessario creare più account di archiviazione e distribuire le tabelle tra questi account.

Progettare partizioni per le prestazioni delle query

È possibile migliorare le prestazioni delle query usando set di dati di piccole dimensioni ed eseguendo query parallele. Ogni partizione deve contenere una piccola percentuale dell'intero set di dati. La riduzione del volume può migliorare le prestazioni delle query. Tuttavia, il partizionamento non è un'alternativa alla progettazione e alla configurazione appropriate del database. Assicurarsi di implementare gli indici necessari.

Seguire questa procedura quando si progettano partizioni per le prestazioni delle query:

Esaminare i requisiti e le prestazioni dell'applicazione.
- Usare i requisiti aziendali per determinare le query critiche che devono sempre essere eseguite rapidamente.
- Monitorare il sistema per identificare le query che eseguono lentamente.
- Determinare le query che eseguono più frequentemente. Anche se una singola query ha un costo minimo, l'utilizzo cumulativo delle risorse può essere significativo.
Partizionare i dati che causano prestazioni lente.
- Limitare le dimensioni di ogni partizione in modo che il tempo di risposta della query sia compreso nel target.
- Se si usa il partizionamento orizzontale, progettare la chiave di partizione in modo che l'applicazione possa selezionare facilmente la partizione appropriata. Questa specifica impedisce alla query di analizzare ogni partizione.
- Considerare la posizione di una partizione. Provare a mantenere i dati nelle partizioni geograficamente vicine alle applicazioni e agli utenti che vi accedono.
Se un'entità ha requisiti di velocità effettiva e prestazioni delle query, usare il partizionamento funzionale basato su tale entità. Se questa allocazione non soddisfa ancora i requisiti, è possibile aggiungere il partizionamento orizzontale. Una singola strategia di partizionamento è in genere adeguata, ma in alcuni casi è più efficiente combinare entrambe le strategie.
Eseguire query in parallelo tra partizioni per migliorare le prestazioni.

Progettare partizioni per la disponibilità

Partizionare i dati per migliorare la disponibilità delle applicazioni. Il partizionamento garantisce che l'intero set di dati non abbia un singolo punto di errore ed è possibile gestire in modo indipendente singoli subset del set di dati.

Considerare i fattori seguenti, che influiscono sulla disponibilità:

Determinare la criticità dei dati. Identificare i dati aziendali critici, ad esempio le transazioni, e i dati operativi meno critici, ad esempio i file di log.

Archiviare i dati critici in partizioni a disponibilità elevata e creare un piano di backup appropriato.
Stabilire procedure di gestione e monitoraggio separate per set di dati diversi.
Posizionare i dati con lo stesso livello di criticità nella stessa partizione in modo che sia possibile eseguirne il backup con la stessa frequenza. Ad esempio, potrebbe essere necessario eseguire il backup di partizioni che contengono dati delle transazioni più spesso rispetto alle partizioni che contengono informazioni di registrazione o traccia.

Gestire singole partizioni. Progettare partizioni per supportare la gestione e la manutenzione indipendenti. Questa procedura offre diversi vantaggi, ad esempio:

In caso di problemi in una partizione, questa può essere ripristinata in modo indipendente senza le applicazioni che accedono ai dati in altre partizioni.
Il partizionamento dei dati in base all'area geografica consente di eseguire attività di manutenzione pianificate in orari di minore attività per ogni località. Assicurarsi che le partizioni non siano così grandi che impediscono il completamento della manutenzione pianificata durante questo periodo.

Replicare i dati critici tra le partizioni. Questa strategia migliora la disponibilità e le prestazioni, ma può anche introdurre problemi di coerenza. La sincronizzazione delle modifiche con ogni replica richiede tempo. Durante la sincronizzazione, partizioni diverse contengono valori di dati diversi.

Ottimizzare il codice dell'applicazione per usare le partizioni

Il partizionamento aumenta la complessità di progettazione e sviluppo del sistema. Partizionare i dati come parte fondamentale della progettazione del sistema anche se inizialmente il sistema contiene solo una singola partizione. Se si affronta il partizionamento come un'operazione successiva, è difficile perché si dispone già di un sistema attivo da gestire. È possibile:

Modificare la logica di accesso ai dati.
È necessario eseguire la migrazione di grandi quantità di dati esistenti per distribuirli tra partizioni.
Si verificano problemi perché gli utenti si aspettano di continuare a usare il sistema durante la migrazione.

In alcuni casi, il partizionamento non è importante perché il set di dati iniziale è piccolo e un singolo server può gestirlo facilmente. Alcuni carichi di lavoro possono andare senza partizioni, ma molti sistemi commerciali devono espandersi man mano che aumenta il numero di utenti.

Alcuni archivi dati di piccole dimensioni traggono vantaggio anche dal partizionamento. Ad esempio, centinaia di client simultanei potrebbero accedere a un archivio dati di piccole dimensioni. Se si partiziona i dati in questa situazione, può essere utile per ridurre i conflitti e migliorare la velocità effettiva.

Quando si progetta un schema di partizionamento dei dati, tenere presente quanto riportato di seguito:

Ridurre al minimo le operazioni di accesso ai dati tra partizioni. Provare a mantenere insieme i dati per le operazioni di database più comuni in una partizione per ridurre al minimo le operazioni di accesso ai dati tra partizioni. Può richiedere più tempo per eseguire query tra partizioni anziché eseguire query all'interno di una singola partizione. Tuttavia, l'ottimizzazione delle partizioni per un set di query potrebbe influire negativamente su altri set di query. Se è necessario eseguire query tra partizioni, ridurne al minimo la durata eseguendo query parallele e aggregando i risultati all'interno dell'applicazione. In alcuni casi, non è possibile usare questo approccio, ad esempio se il risultato di una query viene usato nella query successiva.

Replicare i dati di riferimento statici. Se le query usano dati di riferimento relativamente statici, ad esempio tabelle di codice postale o elenchi di prodotti, è consigliabile replicare questi dati in tutte le partizioni per ridurre le operazioni di ricerca separate in partizioni diverse. Questo approccio può anche ridurre la probabilità che i dati di riferimento diventino un set di dati ad accesso frequente con traffico elevato proveniente dall'intero sistema. Sono previsti costi aggiuntivi associati alla sincronizzazione delle modifiche apportate ai dati di riferimento.

Ridurre al minimo i join tra partizioni. Quando possibile, ridurre al minimo i requisiti di integrità referenziale tra le partizioni verticali e funzionali. In questi schemi, l'applicazione è responsabile del mantenimento dell'integrità referenziale tra le partizioni. Le query che aggiungono dati tra più partizioni sono inefficienti perché l'applicazione esegue in genere query consecutive basate su una chiave e quindi su una chiave esterna. Si consiglia di replicare o de-normalizzare i dati rilevanti. Se sono necessari join tra partizioni, eseguire query parallele sulle partizioni e unire i dati all'interno dell'applicazione.

Implementare la coerenza finale. Valutare se la coerenza assoluta è un requisito. Nei sistemi distribuiti, un approccio comune consiste nell'implementare la coerenza finale. I dati in ogni partizione vengono aggiornati separatamente e la logica dell'applicazione garantisce che gli aggiornamenti vengano completati correttamente. La logica dell'applicazione gestisce anche le incoerenze derivanti dall'esecuzione di query sui dati durante l'esecuzione di un'operazione finale coerente.

È necessario considerare come le query individuano la partizione corretta. Se una query deve analizzare tutte le partizioni per individuare i dati necessari, influisce in modo significativo sulle prestazioni, anche quando vengono eseguite più query parallele. Con il partizionamento verticale e funzionale, le query possono specificare la partizione. D'altra parte, il partizionamento orizzontale può rendere difficile l'individuazione di un elemento perché ogni partizione ha lo stesso schema. Una soluzione tipica consiste nel mantenere una mappa usata per cercare la posizione delle partizioni degli elementi. Implementare questa mappa nella logica di partizionamento orizzontale dell'applicazione. Può anche essere gestito dall'archivio dati se l'archivio dati supporta il partizionamento orizzontale trasparente.

Ribilanciare periodicamente le partizioni. Con il partizionamento orizzontale, il ribilanciamento delle partizioni consente di distribuire uniformemente i dati in base alle dimensioni e al carico di lavoro. Ribilanciare le partizioni per ridurre al minimo gli hotspot, ottimizzare le prestazioni delle query e aggirare le limitazioni dell'archiviazione fisica. Questa attività è complessa e spesso richiede uno strumento o un processo personalizzato.

Replicare le partizioni. Replicare ogni partizione per fornire una protezione aggiuntiva in caso di errore. Se una singola replica ha esito negativo, le query vengono indirizzate a una copia funzionante.

Estendere la scalabilità a un livello diverso. Se si raggiungono i limiti fisici di una strategia di partizionamento, potrebbe essere necessario estendere la scalabilità a un livello diverso. Ad esempio, se il partizionamento è a livello di database, potrebbe essere necessario individuare o eseguire la replica delle partizioni in più database. Se il partizionamento è già a livello di database e esistono limitazioni fisiche, potrebbe essere necessario individuare o replicare partizioni in più account di hosting.

Evitare transazioni che accedono ai dati in più partizioni. Alcuni archivi dati implementano la coerenza transazionale e l'integrità per le operazioni che modificano i dati, ma solo quando i dati si trovano in una singola partizione. Se è necessario il supporto transazionale tra più partizioni, implementarlo come parte della logica dell'applicazione perché la maggior parte dei sistemi di partizionamento non fornisce supporto nativo.

Tutti gli archivi dati richiedono una gestione operativa e il monitoraggio dell'attività. Queste attività includono il caricamento dei dati, il backup e il ripristino dei dati, la riorganizzazione dei dati e la garanzia che il sistema funzioni correttamente ed in modo efficiente.

Considerare i seguenti fattori che influiscono sulla gestione operativa:

Implementare le attività operative e di gestione appropriate quando i dati vengono partizionati. Queste attività possono includere il backup e il ripristino, l'archiviazione dei dati, il monitoraggio del sistema e altre attività amministrative. Ad esempio, può essere difficile mantenere la coerenza logica durante le operazioni di backup e ripristino.
Caricare i dati in più partizioni e aggiungere nuovi dati provenienti da altre origini. Alcuni strumenti e utilità potrebbero non supportare operazioni sui dati partizionate, ad esempio il caricamento di dati nella partizione corretta.
Archiviare ed eliminare regolarmente i dati. Per evitare l'aumento eccessivo delle partizioni, archiviare ed eliminare i dati ogni mese. Potrebbe essere necessario trasformare i dati in modo che corrispondano a uno schema di archivio diverso.
Individuare i problemi di integrità dei dati. Prendere in considerazione l'esecuzione di un processo periodico per individuare i problemi di integrità dei dati, ad esempio i dati in una partizione che fanno riferimento a informazioni mancanti in un'altra. Il processo può tentare automaticamente di risolvere questi problemi o generare un report per la revisione manuale.

Ribilanciare le partizioni

Con l'evoluzione del sistema potrebbe essere necessario modificare lo schema di partizionamento. Ad esempio, le singole partizioni potrebbero iniziare a ricevere un volume sproporzionato di traffico e diventare ad accesso frequente, causando un conflitto eccessivo. In alternativa, si potrebbe aver sottovalutato il volume di dati in alcune partizioni, il che fa sì che le partizioni si avvicinino ai limiti di capacità.

Alcuni archivi dati, ad esempio Azure Cosmos DB, possono ribilanciare automaticamente le partizioni. In altri casi, è possibile ribilanciare le partizioni in due fasi:

Determinare una nuova strategia di partizionamento.
- Quali partizioni devono essere suddivise o combinate?
- Qual è la nuova chiave di partizione?
Eseguire la migrazione dei dati dallo schema di partizionamento precedente al nuovo set di partizioni.

Potrebbe essere necessario rendere le partizioni non disponibili durante la rilocazione dei dati, denominata migrazione offline. A seconda dell'archivio dati, è possibile eseguire la migrazione dei dati tra partizioni mentre sono in uso. Questa tecnica è detta migrazione online.

Migrazione offline

La migrazione offline riduce la probabilità che si verifichi un conflitto. Per eseguire la migrazione offline:

Contrassegnare la partizione come offline. È possibile contrassegnare una partizione come di sola lettura in modo che le applicazioni possano comunque leggere i dati durante lo spostamento.
Dividere/unire e spostare i dati nelle nuove partizioni.
Verify the data.
Portare le nuove partizioni online.
Rimuovere la partizione precedente.

Migrazione online

La migrazione online è più complessa ma meno impegnativa rispetto alla migrazione offline. Il processo è simile alla migrazione offline, ma non si contrassegna la partizione originale come offline. A seconda della granularità del processo di migrazione, ad esempio l'elemento per elemento rispetto alla partizione per partizione, il codice di accesso ai dati nelle applicazioni client potrebbe dover leggere e scrivere dati che si trovano in due posizioni, la partizione originale e la nuova partizione.

Facilitazione di Azure

Le sezioni seguenti descrivono le raccomandazioni per il partizionamento dei dati archiviati nei servizi di Azure.

Partizione in database SQL di Azure

Un singolo database SQL ha un limite per il volume di dati che può contenere. La velocità effettiva è vincolata da fattori di architettura e dal numero di connessioni simultanee supportate.

I pool elastici supportano la scalabilità orizzontale di un database SQL. Usare i pool elastici per partizionare i dati in partizioni distribuite in più database SQL. È anche possibile aggiungere o rimuovere partizioni man mano che il volume dei dati aumenta e si riduce. I pool elastici consentono anche di ridurre la contesa distribuendo il carico tra i database.

Ogni partizione viene implementata come un database SQL. Una partizione può contenere più set di dati. Ogni set di dati è denominato shardlet. Ogni database contiene metadati che descrivono gli shardlet che contiene. Uno shardlet può essere un singolo elemento di dati o un gruppo di elementi che condividono la stessa chiave shardlet. Ad esempio, in un'applicazione multi-tenant, la chiave shardlet può essere l'ID tenant e tutti i dati per un tenant possono trovarsi nello stesso shardlet.

Le applicazioni sono responsabili dell'associazione di un set di dati a una chiave shardlet. Un database SQL separato effettua la gestione del mapping globale delle partizioni. Questo database ha un elenco di tutte le partizioni e tutti gli shardlet nel sistema. L'applicazione si connette al database di gestione delle mappe partizioni per ottenere una copia della mappa partizioni, Memorizza nella cache la mappa partizioni in locale e usa la mappa per instradare le richieste di dati alla partizione appropriata. Questa funzionalità è nascosta dietro una serie di API contenute nella libreria client della funzionalità Database elastico di database SQL, disponibile per Java e .NET.

Per altre informazioni sui pool elastici, vedere Scalabilità orizzontale con database SQL.

Per ridurre la latenza e migliorare la disponibilità, è possibile replicare il database di gestione globale delle mappe partizioni. Con i piani tariffari Premium, è possibile configurare la replica geografica attiva per copiare continuamente i dati nei database in aree diverse.

In alternativa, usare sincronizzazione dati SQL per database SQL o Azure Data Factory per replicare il database di Gestione mappe partizioni tra aree. Questa forma di replica viene eseguita periodicamente ed è più adatta se la mappa partizioni cambia raramente e non richiede il livello Premium.

Il database elastico offre due schemi per la mappature di dati per gli shardlet e per archiviarli in partizioni:

Una mappa partizioni elenco associa una singola chiave a uno shardlet. Ad esempio, in un sistema multi-tenant, i dati per ogni tenant possono essere associati a una chiave univoca e archiviati in un proprio shardlet. Per garantire l'isolamento, ogni shardlet può essere contenuto all'interno di una specifica partizione.

Scaricare un file di Visio di questo diagramma.
Una mappa partizioni di intervalli associa un set di valori di chiave contigui a uno shardlet. Ad esempio, è possibile raggruppare i dati per un set di tenant, ognuno con la propria chiave, all'interno dello stesso shardlet. Questo schema è meno costoso rispetto a una mappa partizioni di elenco perché i tenant condividono l'archiviazione dei dati, ma offre meno isolamento.

Scaricare un file di Visio di questo diagramma

Una singola partizione può contenere i dati di diversi shardlet. Ad esempio, è possibile usare gli shardlet dell'elenco per archiviare i dati per i diversi tenant non contigui nella stessa partizione. È anche possibile combinare shardlet di intervallo e elenchi di shardlet nella stessa partizione, ma quindi vengono indirizzati tramite mappe diverse. Il diagramma seguente illustra questo approccio:

Scaricare un file di Visio di questo diagramma.

Con i pool elastici è possibile aggiungere e rimuovere partizioni man mano che il volume dei dati aumenta e si riduce. Le applicazioni client possono creare ed eliminare partizioni in modo dinamico e aggiornare in modo trasparente il gestore mappe partizioni. Tuttavia, la rimozione di una partizione è un'operazione distruttiva che richiede anche l'eliminazione di tutti i dati della partizione.

Se un'applicazione deve dividere una partizione in due partizioni separate o combinare partizioni, usare lo strumento di divisione-unione. Questo strumento viene eseguito come servizio Web di Azure ed esegue la migrazione dei dati in modo sicuro tra le partizioni.

Lo schema di partizionamento può influire significativamente sulle prestazioni del sistema, nonché sulla frequenza con cui è necessario aggiungere o rimuovere partizioni o ripartizionare i dati tra le partizioni. Considerare gli aspetti seguenti:

Raggruppare i dati usati insieme nella stessa partizione ed evitare operazioni che accedono ai dati da più partizioni. Una partizione è un database SQL a proprio diritto e i join tra database devono essere eseguiti sul lato client quando le operazioni accedono a più partizioni.

Sebbene database SQL non supporti join tra database, è possibile usare gli strumenti di database elastici per eseguire query su più partizioni. Una query su più partizioni invia singole query a ogni database e unisce i risultati.
Progettare un sistema che non ha dipendenze tra le partizioni. Vincoli di integrità referenziale, trigger e stored procedure in un database non possono fare riferimento a oggetti in un altro.
Valutare la possibilità di replicare i dati tra partizioni se sono presenti dati di riferimento usati di frequente dalle query. Questo approccio può eliminare la necessità di unire dati tra database. Idealmente, questi dati devono essere statici o lenti per ridurre al minimo lo sforzo di replica e ridurre la probabilità che diventino obsoleti.
Usare lo stesso schema per gli shardlet che appartengono alla stessa mappa partizioni. Queste linee guida non vengono applicate da database SQL, ma la gestione dei dati e l'esecuzione di query sono complesse se ogni shardlet ha uno schema diverso. Creare invece mappe partizioni separate per ogni schema. È possibile archiviare i dati appartenenti a shardlet diversi nella stessa partizione.
Archiviare i dati nella stessa partizione o implementare la coerenza finale se la logica di business deve eseguire transazioni. Le operazioni transazionali sono supportate solo per i dati contenuti in una partizione e non tra partizioni. Le transazioni possono estendersi su shardlet se fanno parte della stessa partizione.
Posizionare le partizioni vicino agli utenti che accedono ai dati in esse contenuti. Questa strategia consente di ridurre la latenza.
Evitare di avere una combinazione di partizioni altamente attive e relativamente inattive. Provare a distribuire uniformemente il carico tra le partizioni. Potrebbe essere necessario eseguire l'hash delle chiavi di partizionamento orizzontale. Se si esegue l'individuazione geografica delle partizioni, assicurarsi che le chiavi con hash eseseguono il mapping agli shardlet contenuti nelle partizioni archiviate vicino agli utenti che accedono a tali dati.

Partizione in Archiviazione BLOB di Azure

Con l'archiviazione BLOB è possibile archiviare oggetti binari di grandi dimensioni. Usare BLOB in blocchi in scenari che richiedono di caricare o scaricare rapidamente volumi elevati di dati. Usare i BLOB di pagine per le applicazioni che richiedono l'accesso casuale, anziché seriale, a parti dei dati.

Ogni BLOB in blocchi o BLOB di pagine viene mantenuto in un contenitore in un account di archiviazione di Azure. Usare i contenitori per raggruppare i BLOB correlati che hanno gli stessi requisiti di sicurezza. Questo raggruppamento è logico e non fisico. All'interno di un contenitore ogni BLOB ha un nome univoco.

La chiave di partizione per un BLOB è il nome dell'account, il nome del contenitore e il nome del BLOB. La chiave di partizione viene usata per partizionare i dati in intervalli. Questi intervalli sono con carico bilanciato nel sistema. I BLOB possono essere distribuiti in molti server per aumentare l'accesso. Un singolo BLOB può essere gestito solo da un singolo server.

Se lo schema di denominazione usa timestamp o identificatori numerici, può causare un traffico eccessivo a una partizione. Impedisce al sistema di bilanciare efficacemente il carico. Ad esempio, se si dispone di operazioni giornaliere che usano un oggetto BLOB con un timestamp, ad esempio aa-mm-gg, tutto il traffico per tale operazione passa a un singolo server di partizione. Al contrario, anteporre al nome un hash a tre cifre. Per altre informazioni, vedere Convenzione di denominazione delle partizioni.

Le azioni di scrittura di un singolo blocco o pagina sono atomiche, ma le operazioni che si estendono su blocchi, pagine o BLOB non sono. Se è necessario garantire la coerenza quando le operazioni di scrittura vengono eseguite tra blocchi, pagine e BLOB, eseguire un blocco di scrittura usando un lease blob.

Considerazioni

Il partizionamento dei dati presenta alcune problematiche e complessità da considerare.

La sincronizzazione dei dati tra le partizioni potrebbe diventare una sfida. Assicurarsi che gli aggiornamenti o le modifiche apportate a una partizione vengano propagati alle altre partizioni in modo tempestivo e coerente.
I processi di failover e ripristino di emergenza diventano complessi quando è necessario coordinare il backup e il ripristino di più partizioni. I problemi di integrità dei dati possono verificarsi se alcune partizioni o i relativi backup sono danneggiati o non disponibili.
Il partizionamento dei dati può influire sulle prestazioni e sull'affidabilità se è necessario eseguire query tra partizioni e quando si ribilanciano le partizioni se i dati aumentano in modo non uniforme.

Elenco di controllo per l'affidabilità

Fare riferimento al set completo di raccomandazioni.

Elenco di controllo per l'affidabilità

Condividi tramite

Suggerimenti per il partizionamento dei dati

Strategie di progettazione chiave