Indicazioni sul partizionamento dei dati

In molte soluzioni su larga scala, i dati sono suddivisi in partizioni che possono essere gestite e accessibili separatamente. Il partizionamento può migliorare la scalabilità, ridurre la contesa e ottimizzare le prestazioni, nonché offrire un meccanismo per dividere i dati in base al modello di utilizzo. È ad esempio possibile archiviare i dati meno recenti in un archivio dati più economico.

Tuttavia, la strategia di partizionamento deve essere scelta attentamente per massimizzare i vantaggi riducendo al minimo gli effetti negativi.

Perché i dati della partizione?

• Migliorare la scalabilità. Quando si aumentano le prestazioni di un singolo sistema di database, alla fine raggiungerà un limite hardware fisico. Se si suddividono i dati tra più partizioni, ognuno ospitato in un server separato, è possibile aumentare il numero di istanze del sistema quasi indefinito.

• Migliorare le prestazioni. Le operazioni di accesso ai dati su ogni partizione vengono eseguite su un volume di dati più piccolo. Fatto correttamente, il partizionamento può 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.

• Offrire flessibilità operativa. Il partizionamento offre molte opportunità per ottimizzare le operazioni, ottimizzare l'efficienza amministrativa e ridurre al minimo i costi. Ad esempio, è possibile definire strategie diverse per la gestione, il monitoraggio, il backup e il ripristino e altre attività amministrative in base all'importanza dei dati in ogni partizione.

• Associare l'archivio dati al modello di utilizzo. Il partizionamento consente di distribuire ogni partizione in un tipo diverso di archivio dati, in base al costo e alle funzionalità predefinite offerte dall'archivio dati. Ad esempio, i dati binari di grandi dimensioni possono essere archiviati nell'archivio BLOB, mentre i dati più strutturati possono essere conservati in un database di documenti. Per altre informazioni, vedere Scegliere l'archivio dati corretto.

• Migliorare la disponibilità. La separazione dei dati tra più server evita un singolo punto di errore. Se un'istanza ha esito negativo, solo i dati in tale partizione non sono disponibili. Le operazioni su altre partizioni possono continuare. Per gli archivi dati PaaS (Managed Platform as a Service), questa considerazione è meno rilevante perché questi servizi sono progettati con ridondanza predefinita.

Progettazione di partizioni

Esistono tre strategie tipiche per il partizionamento dei dati:

• 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 specifico dei dati, ad esempio tutti gli ordini per un set specifico di clienti.

• Partizionamento verticale. In questa strategia ogni partizione contiene un subset dei campi per gli elementi nell'archivio dati. I campi vengono divisi in base al modello di utilizzo. Ad esempio, i campi a cui si accede di frequente potrebbero essere inseriti in una partizione verticale e con accesso meno frequente in un altro.

• Partizionamento funzionale. In questa strategia i dati vengono aggregati in base al modo in cui vengono usati da ogni contesto delimitato nel sistema. Ad esempio, un sistema di e-commerce potrebbe archiviare i dati della fattura in una partizione e i dati di inventario dei prodotti in un altro.

Queste strategie possono essere combinate e è consigliabile considerarle tutte quando si progetta uno schema di partizionamento. Ad esempio, è possibile dividere i dati in partizioni e quindi usare il partizionamento verticale per suddividere ulteriormente i dati in ogni partizione.

Partizionamento orizzontale (sharding)

La figura 1 mostra il partizionamento orizzontale o il partizionamento orizzontale. In questo esempio i dati di inventario dei prodotti vengono suddivisi in partizioni in base al codice Product Key. Ogni partizione contiene i dati per un intervallo contiguo di chiavi di partizione (A-G e H-Z), organizzate alfabeticamente. Il partizionamento orizzontale distribuisce il carico su più computer, riducendo la contesa e migliorando le prestazioni.

Figura 1 - Partizionamento orizzontale (partizionamento orizzontale) dei dati in base a una chiave di partizione.

Il fattore più importante è la scelta di una chiave di partizionamento orizzontale. Può essere difficile modificare la chiave dopo che il sistema è in funzione. La chiave deve garantire che i dati siano partizionati per distribuire il carico di lavoro il più uniformemente possibile tra le partizioni.

I frammenti non devono essere della stessa dimensione. È più importante bilanciare il numero di richieste. Alcune partizioni potrebbero essere molto grandi, ma ogni elemento ha un numero ridotto di operazioni di accesso. Altre partizioni potrebbero essere più piccole, ma ogni elemento è accessibile molto più frequentemente. È anche importante assicurarsi che una singola partizione non superi i limiti di scalabilità (in termini di capacità e risorse di elaborazione) dell'archivio dati.

Evitare di creare partizioni "ad accesso frequente" che possono influire sulle prestazioni e sulla disponibilità. Ad esempio, l'uso della prima lettera del nome di un cliente causa una distribuzione sbilanciata, perché alcune lettere sono più comuni. Usare invece un hash di un identificatore cliente per distribuire i dati in modo più uniforme tra le partizioni.

Scegliere una chiave di partizionamento orizzontale che riduce al minimo i requisiti futuri per suddividere partizioni di grandi dimensioni, unire piccole partizioni in partizioni più grandi o modificare lo schema. Queste operazioni possono richiedere molto tempo e potrebbero richiedere una o più partizioni offline durante l'esecuzione.

Se le partizioni vengono replicate, potrebbe essere possibile mantenere online alcune delle repliche mentre altre vengono suddivise, unite o riconfigurate. Tuttavia, potrebbe essere necessario 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 sul partizionamento orizzontale, vedere Modello di partizionamento orizzontale.

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. La figura 2 mostra un esempio di partizionamento verticale. In questo 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: il conteggio delle scorte e la data dell'ultimo ordine.

Figura 2 : partizionamento verticale dei dati in base al modello di utilizzo.

In questo esempio, l'applicazione esegue regolarmente query sul nome, sulla descrizione e sul prezzo del prodotto quando vengono visualizzati i dettagli del prodotto ai clienti. Il conteggio delle scorte e la data dell'ultimo ordine vengono mantenuti in una partizione separata perché questi due articoli vengono comunemente usati insieme.

Altri vantaggi del partizionamento verticale:

• I dati a spostamento relativamente lento (nome del prodotto, descrizione e prezzo) possono essere separati dai dati più dinamici (livello di magazzino e data dell'ultima ordine). Il rallentamento dello spostamento dei dati è un buon candidato per un'applicazione nella cache in memoria.

• I dati sensibili possono essere archiviati in una partizione separata con controlli di sicurezza aggiuntivi.

• Il partizionamento verticale può ridurre la quantità di accesso simultaneo necessario.

Il partizionamento verticale opera a livello di entità all'interno di un archivio dati, normalizzando parzialmente un'entità per suddividerla da un elemento ampio a un set di elementi ristretti. È ideale per gli archivi dati orientati alle colonne, ad esempio HBase e Cassandra. Se è improbabile che i dati in una raccolta di colonne cambino, è anche possibile prendere in considerazione l'uso di 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 è un modo per migliorare le prestazioni di isolamento e accesso ai dati. Un altro uso comune per il partizionamento funzionale consiste nel separare i dati di lettura/scrittura dai dati di sola lettura. La figura 3 mostra una panoramica del partizionamento funzionale in cui i dati di inventario sono separati dai dati dei clienti.

Figura 3- Partizionamento funzionale dei dati in base al contesto delimitato o al sottodominio.

Questa strategia di partizionamento consente di ridurre i conflitti di accesso ai dati in diverse parti di un sistema.

Progettazione di partizioni per la scalabilità

È fondamentale considerare le dimensioni e il carico di lavoro per ogni partizione e 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 ridimensionamento di un singolo archivio di partizioni.

Per la progettazione di partizioni per la scalabilità, seguire questa procedura:

1. 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, la 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.
2. Usare questa analisi per determinare gli obiettivi di scalabilità correnti e futuri, ad esempio le dimensioni dei dati e il carico di lavoro. Distribuire quindi i dati tra le partizioni per soddisfare la destinazione di scalabilità. Per il partizionamento orizzontale, è importante scegliere la chiave di partizione corretta per assicurarsi che la distribuzione sia uniforme. Per altre informazioni, vedere il modello di partizionamento orizzontale.
3. Assicurarsi che ogni partizione disponga di risorse sufficienti per gestire i requisiti di scalabilità, in termini di dimensioni dei dati e velocità effettiva. A seconda dell'archivio dati, potrebbe essere previsto un limite per la quantità di spazio di archiviazione, potenza di elaborazione o larghezza di banda di rete per partizione. Se è probabile che i requisiti superino questi limiti, potrebbe essere necessario perfezionare la strategia di partizionamento o suddividere ulteriormente i dati, eventualmente combinando due o più strategie.
4. 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 quanto previsto da un'analisi. In tal caso, potrebbe essere possibile ribilanciare le partizioni o riprogettare alcune parti del sistema per ottenere il saldo necessario.

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

Ad esempio, se si usa l'archiviazione tabelle di Azure, è previsto un limite al volume di richieste che possono essere gestite da una singola partizione in un determinato periodo di tempo. Per altre informazioni, vedere Obiettivi di scalabilità e prestazioni di Archiviazione di Azure. Una partizione occupata potrebbe richiedere più risorse che una singola partizione può gestire. In tal caso, 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 account di archiviazione aggiuntivi e distribuire le tabelle tra questi account.

Progettazione di partizioni per le prestazioni delle query

Le prestazioni delle query possono spesso essere migliorate usando set di dati più piccoli ed eseguendo query parallele. Ogni partizione deve contenere una piccola percentuale dell'intero set di dati. Questa riduzione del volume può migliorare le prestazioni delle query. Tuttavia, il partizionamento non è un'alternativa per la progettazione e la configurazione di un database in modo appropriato. Ad esempio, assicurarsi di disporre degli indici necessari.

Per la progettazione di partizioni per le prestazioni delle query, seguire questa procedura:

1. Esaminare i requisiti e le prestazioni dell'applicazione:

   • Usare i requisiti aziendali per determinare le query critiche che devono essere sempre eseguite rapidamente.
   • Monitorare il sistema per identificare le query che eseguono lentamente.
   • Individuare le query eseguite più frequentemente. Anche se una singola query ha un costo minimo, l'utilizzo cumulativo delle risorse potrebbe essere significativo.

2. Partizionare i dati che causano prestazioni lente:

   • Limitare le dimensioni di ogni partizione in modo che il tempo di risposta della query rientri nell'obiettivo.
   • Se si usa il partizionamento orizzontale, progettare la chiave di partizione in modo che l'applicazione possa selezionare facilmente la partizione corretta. In questo modo la query non deve eseguire l'analisi in ogni partizione.
   • Prendere in considerazione la posizione di una partizione. Se possibile, provare a mantenere i dati in partizioni geograficamente vicine alle applicazioni e agli utenti che vi accedono.

3. Se un'entità ha requisiti di velocità effettiva e prestazioni delle query, usare il partizionamento funzionale basato su tale entità. Se questo non soddisfa ancora i requisiti, applicare anche il partizionamento orizzontale. Nella maggior parte dei casi, una singola strategia di partizionamento sarà sufficiente, ma in alcuni casi è più efficiente combinare entrambe le strategie.

4. Prendere in considerazione l'esecuzione di query in parallelo tra le partizioni per migliorare le prestazioni.

Progettazione di partizioni per la disponibilità

Il partizionamento dei dati può migliorare la disponibilità delle applicazioni assicurando che l'intero set di dati non rappresenti un singolo punto di errore e che singoli subset del set di dati possano essere gestiti in modo indipendente.

Considerare i fattori seguenti che influiscono sulla disponibilità:

Qual è la criticità dei dati per le operazioni aziendali. Identificare quali dati sono informazioni aziendali critiche, ad esempio transazioni, e quali dati sono dati operativi meno critici, ad esempio i file di log.

• Prendere in considerazione l'archiviazione di dati critici in partizioni a disponibilità elevata con un piano di backup appropriato.

• Stabilire procedure di gestione e monitoraggio separate per i diversi set di dati.

• Inserire i dati con lo stesso livello di criticità nella stessa partizione in modo che possa essere eseguito il backup insieme a una frequenza appropriata. Ad esempio, le partizioni che contengono dati delle transazioni potrebbero dover essere sottoposte a backup più frequentemente rispetto alle partizioni che contengono informazioni di registrazione o traccia.

Modalità di gestione delle singole partizioni. La progettazione di partizioni per supportare la gestione e la manutenzione indipendenti offre diversi vantaggi. Per esempio:

• Se una partizione ha esito negativo, può essere recuperata in modo indipendente senza applicazioni che accedono ai dati in altre partizioni.

• Il partizionamento dei dati in base all'area geografica consente di eseguire attività di manutenzione pianificate alle ore di minore attività per ogni località. Assicurarsi che le partizioni non siano troppo grandi per impedire il completamento della manutenzione pianificata durante questo periodo.

Indica se replicare i dati critici tra partizioni. Questa strategia può migliorare la disponibilità e le prestazioni, ma può anche introdurre problemi di coerenza. La sincronizzazione delle modifiche con ogni replica richiede tempo. Durante questo periodo, partizioni diverse conterranno valori di dati diversi.

Considerazioni sulla progettazione delle applicazioni

Il partizionamento aggiunge complessità alla progettazione e allo sviluppo del sistema. Considerare il partizionamento come parte fondamentale della progettazione del sistema anche se inizialmente il sistema contiene solo una singola partizione. Se si affronta il partizionamento come un afterthought, sarà più complesso perché si dispone già di un sistema attivo da gestire:

• La logica di accesso ai dati dovrà essere modificata.
• Potrebbe essere necessario eseguire la migrazione di grandi quantità di dati esistenti per distribuirli tra partizioni.
• Gli utenti si aspettano di poter continuare a usare il sistema durante la migrazione.

In alcuni casi, il partizionamento non è considerato importante perché il set di dati iniziale è piccolo e può essere facilmente gestito da un singolo server. Questo potrebbe essere vero per alcuni carichi di lavoro, ma molti sistemi commerciali devono espandersi man mano che aumenta il numero di utenti.

Inoltre, non solo archivi dati di grandi dimensioni che traggono vantaggio dal partizionamento. Ad esempio, un archivio dati di piccole dimensioni potrebbe essere molto accessibile da centinaia di client simultanei. Il partizionamento dei dati in questa situazione può contribuire a ridurre la contesa e migliorare la velocità effettiva.

Quando si progetta uno schema di partizionamento dei dati, tenere presente quanto segue:

Ridurre al minimo le operazioni di accesso ai dati tra partizioni. Se possibile, mantenere insieme i dati per le operazioni di database più comuni in ogni partizione per ridurre al minimo le operazioni di accesso ai dati tra partizioni. L'esecuzione di query tra partizioni può richiedere più tempo rispetto all'esecuzione di query all'interno di una singola partizione, ma l'ottimizzazione delle partizioni per un set di query potrebbe influire negativamente su altri set di query. Se è necessario eseguire query tra partizioni, ridurre al minimo il tempo di query eseguendo query parallele e aggregando i risultati all'interno dell'applicazione. Questo approccio potrebbe non essere possibile in alcuni casi, ad esempio quando il risultato di una query viene usato nella query successiva.

Valutare la possibilità di 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 "frequente", con traffico elevato proveniente dall'intero sistema. Tuttavia, è previsto un costo aggiuntivo associato alla sincronizzazione delle modifiche apportate ai dati di riferimento.

Ridurre al minimo i join tra partizioni. Se possibile, ridurre al minimo i requisiti per l'integrità referenziale tra partizioni verticali e funzionali. In questi schemi, l'applicazione è responsabile della gestione dell'integrità referenziale tra le partizioni. Le query che aggiungono dati tra più partizioni sono inefficienti perché l'applicazione in genere deve eseguire query consecutive in base a una chiave e quindi a una chiave esterna. Invece, considera di replicare o denormalizzare i dati pertinenti. Quando sono necessari join tra partizioni, esegui query parallele sulle partizioni e unisci i dati all'interno dell'applicazione.

Abbraccia la coerenza finale. Valutare se la coerenza assoluta è effettivamente un requisito. Un approccio comune nei sistemi distribuiti consiste nell'implementare la coerenza finale. I dati in ogni partizione vengono aggiornati separatamente e la logica dell'applicazione garantisce che tutti gli aggiornamenti vengano completati correttamente. Gestisce anche le incoerenze che possono derivare dall'esecuzione di query sui dati durante l'esecuzione di un'operazione coerente alla fine.

Valutare il modo in cui le query individuano la partizione corretta. Se una query deve analizzare tutte le partizioni per individuare i dati necessari, si verifica un impatto significativo sulle prestazioni, anche quando sono in esecuzione più query parallele. Con il partizionamento verticale e funzionale, le query possono specificare naturalmente la partizione. Il partizionamento orizzontale, d'altra parte, può rendere difficile l'individuazione di un elemento, perché ogni partizione ha lo stesso schema. Soluzione tipica per gestire una mappa usata per cercare la posizione delle partizioni per elementi specifici. Questa mappa può essere implementata nella logica di partizionamento orizzontale dell'applicazione o gestita dall'archivio dati se supporta il partizionamento orizzontale trasparente.

Valutare la possibilità di ribilanciare periodicamente le partizioni. Con il partizionamento orizzontale, il ribilanciamento delle partizioni consente di distribuire i dati in modo uniforme in base alle dimensioni e al carico di lavoro per ridurre al minimo gli hotspot, ottimizzare le prestazioni delle query e aggirare le limitazioni dell'archiviazione fisica. Tuttavia, si tratta di un'attività complessa che spesso richiede l'uso di uno strumento o di un processo personalizzato.

Replicare le partizioni. Se si esegue la replica di ogni partizione, offre protezione aggiuntiva da errori. Se una singola replica ha esito negativo, le query possono essere indirizzate a una copia funzionante.

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 replicare partizioni in più database. Se il partizionamento è già a livello di database e le limitazioni fisiche rappresentano un problema, potrebbe significare che è 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, probabilmente sarà necessario implementare questa funzionalità come parte della logica dell'applicazione perché la maggior parte dei sistemi di partizionamento non fornisce supporto nativo.

Tutti gli archivi dati richiedono alcune attività operative di gestione e monitoraggio. Le attività possono variare dal caricamento dei dati, dal backup e dal ripristino dei dati, dalla riorganizzazione dei dati e dall'esecuzione corretta ed efficiente del sistema.

Considerare i fattori seguenti che influiscono sulla gestione operativa:

• Come implementare le attività operative e di gestione appropriate quando i dati vengono partizionati. Queste attività possono includere backup e ripristino, archiviazione dei dati, monitoraggio del sistema e altre attività amministrative. Ad esempio, mantenere la coerenza logica durante le operazioni di backup e ripristino può essere una sfida.

• Come 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.

• Come archiviare ed eliminare regolarmente i dati. Per evitare l'aumento eccessivo delle partizioni, è necessario archiviare ed eliminare i dati a intervalli regolari, ad esempio mensilmente. Potrebbe essere necessario trasformare i dati in modo che corrispondano a uno schema di archivio diverso.

• Come individuare i problemi di integrità dei dati. Prendere in considerazione l'esecuzione di un processo periodico per individuare eventuali 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 di risolvere questi problemi automaticamente o generare un report per la revisione manuale.

Ribilanciamento delle partizioni

Man mano che un sistema matura, potrebbe essere necessario modificare lo schema di partizionamento. Ad esempio, le singole partizioni potrebbero iniziare a ottenere un volume sproporzionato di traffico e diventare ad accesso frequente, causando una contesa eccessiva. Oppure si potrebbe aver sottovalutato il volume di dati in alcune partizioni, causando l'approccio di alcune partizioni ai limiti di capacità.

Alcuni archivi dati, ad esempio Azure Cosmos DB, possono ribilanciare automaticamente le partizioni. In altri casi, il ribilanciamento è un'attività amministrativa costituita da due fasi:

1. Determinare una nuova strategia di partizionamento.

   • Quali partizioni devono essere suddivise (o eventualmente combinate)?
   • Qual è la nuova chiave di partizione?

2. Eseguire la migrazione dei dati dallo schema di partizionamento precedente al nuovo set di partizioni.

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

Migrazione offline

La migrazione offline è in genere più semplice perché riduce le probabilità che si verifichino conflitti. Concettualmente, la migrazione offline funziona come segue:

1. Contrassegnare la partizione offline.
2. Suddividere, unire e spostare i dati nelle nuove partizioni.
3. Verificare i dati.
4. Portare online le nuove partizioni.
5. Rimuovere la partizione precedente.

Facoltativamente, è possibile contrassegnare una partizione come di sola lettura nel passaggio 1, in modo che le applicazioni possano comunque leggere i dati durante lo spostamento.

Migrazione online

La migrazione online è più complessa da eseguire, ma meno disgregante. Il processo è simile alla migrazione offline, ad eccezione della partizione originale non contrassegnata come offline. A seconda della granularità del processo di migrazione (ad esempio, elemento per elemento rispetto alla partizione per partizione), il codice di accesso ai dati nelle applicazioni client potrebbe dover gestire la lettura e la scrittura di dati contenuti in due posizioni, la partizione originale e la nuova partizione.

Passaggi successivi

• Informazioni sulle strategie di partizionamento per servizi di Azure specifici. Per altre informazioni, vedere Strategie di partizionamento dei dati.
• Obiettivi di scalabilità e prestazioni di Archiviazione di Azure

" output is necessary.)

• Scegliere l'archivio dati corretto

I modelli di progettazione seguenti potrebbero essere rilevanti per lo scenario:

• Il modello di partizionamento orizzontale descrive alcune strategie comuni per il partizionamento orizzontale dei dati.

• Il modello di tabella dell'indice mostra come creare indici secondari sui dati. Un'applicazione può recuperare rapidamente i dati con questo approccio usando query che non fanno riferimento alla chiave primaria di una raccolta.

• Il modello di vista materializzato descrive come generare viste prepopolate che riepilogino i dati per supportare operazioni di query veloci. Questo approccio può essere utile in un archivio dati partizionato se le partizioni che contengono i dati riepilogati vengono distribuite in più siti.