Strategie di partizionamento dei dati

Questo articolo descrive alcune strategie per il partizionamento dei dati in vari archivi dati di Azure. Per indicazioni generali su quando partizionare i dati e le procedure consigliate, vedere partizionamento dei dati.

Partizionamento del database SQL di Azure

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

I pool elastici supportano la scalabilità orizzontale per un database SQL. Usando i pool elastici, è possibile partizionare i dati in partizioni distribuite in più database SQL. È anche possibile aggiungere o rimuovere partizioni quando il volume di dati che è necessario gestire aumenta e riduce. I pool elastici possono anche contribuire a ridurre la contesa distribuendo il carico tra database.

Ogni partizione viene implementata come database SQL. Una partizione può contenere più set di dati (denominata shardlet). Ogni database gestisce i 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 essere mantenuti nello stesso shardlet.

Le applicazioni client sono responsabili dell'associazione di un set di dati a una chiave shardlet. Un database SQL separato funge da gestore mappa partizioni globale. Questo database include un elenco di tutte le partizioni e gli shardlet nel sistema. L'applicazione si connette al database di gestione 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 del database elastico , disponibile per Java e .NET.

Per altre informazioni sui pool elastici, vedere scalabilità orizzontale con il database SQL di Azure.

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

In alternativa, usare di sincronizzazione dati SQL di Azure 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 il mapping dei dati a shardlet e l'archiviazione 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 nel proprio shardlet. Per garantire l'isolamento, ogni shardlet può essere mantenuto all'interno del proprio shard.

  

  Scaricare un file di Visio di questo diagramma.

• Una mappa partizioni di intervallo 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 del primo, perché i tenant condividono l'archiviazione dei dati, ma hanno meno isolamento.

  

  Scaricare un di file di Visio di questo diagramma

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

Scaricare un file di Visio di questo diagramma.

I pool elastici consentono di aggiungere e rimuovere partizioni man mano che il volume dei dati si riduce e aumenta. 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 in tale partizione.

Se un'applicazione deve dividere una partizione in due partizioni separate o combinare partizioni, usare lo strumento di suddivisione-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. Può anche influire sulla frequenza con cui le partizioni devono essere aggiunte o rimosse o che i dati devono essere ripartizionati tra partizioni. Considerare i punti 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.

  Sebbene il 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.

• Non progettare un sistema con dipendenze tra le partizioni. Vincoli di integrità referenziale, trigger e stored procedure in un database non possono fare riferimento a oggetti in un altro.

• Se si dispone di dati di riferimento usati di frequente dalle query, è consigliabile replicare questi dati tra partizioni. Questo approccio può rimuovere 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 le probabilità che diventino obsoleti.

• Gli Shardlet che appartengono alla stessa mappa partizioni devono avere lo stesso schema. Questa regola non viene applicata dal database SQL, ma la gestione dei dati e l'esecuzione di query diventa molto complessa se ogni shardlet ha uno schema diverso. Crea invece mappe di partizione separate per ciascun schema. Tenere presente che i dati appartenenti a shardlet diversi possono essere archiviati nella stessa partizione.

• Le operazioni transazionali sono supportate solo per i dati all'interno di una partizione e non tra partizioni. Le transazioni possono estendersi su shardlet purché facciano parte della stessa partizione. Pertanto, se la logica di business deve eseguire transazioni, archiviare i dati nella stessa partizione o implementare la coerenza finale.

• Posizionare le partizioni vicino agli utenti che accedono ai dati in tali partizioni. Questa strategia consente di ridurre la latenza.

• Evitare di avere una combinazione di partizioni altamente attive e relativamente inattive. Provare a distribuire il carico in modo uniforme tra le partizioni. Ciò potrebbe richiedere l'hashing delle chiavi di partizionamento orizzontale. Se si esegue l'individuazione geografica delle partizioni, assicurarsi che le chiavi con hash eseseguono il mapping agli shardlet archiviati nelle partizioni archiviate vicino agli utenti che accedono a tali dati.

Partizionamento dell'archiviazione tabelle di Azure

Archiviazione tabelle di Azure è un archivio chiave-valore progettato per il partizionamento. Tutte le entità vengono archiviate in una partizione e le partizioni vengono gestite internamente dall'archiviazione tabelle di Azure. Ogni entità archiviata in una tabella deve fornire una chiave in due parti che include:

• La chiave di partizione. Si tratta di un valore stringa che determina la partizione in cui archiviazione tabelle di Azure inserisce l'entità. Tutte le entità con la stessa chiave di partizione vengono archiviate nella stessa partizione.

• La chiave di riga. Si tratta di un valore stringa che identifica l'entità all'interno della partizione. Tutte le entità all'interno di una partizione vengono ordinate in modo lessicale, in ordine crescente, in base a questa chiave. La combinazione di chiave di partizione/chiave di riga deve essere univoca per ogni entità e non può superare la lunghezza di 1 KB.

Se un'entità viene aggiunta a una tabella con una chiave di partizione precedentemente inutilizzata, Archiviazione tabelle di Azure crea una nuova partizione per questa entità. Altre entità con la stessa chiave di partizione verranno archiviate nella stessa partizione.

Questo meccanismo implementa in modo efficace una strategia di scalabilità orizzontale automatica. Ogni partizione viene archiviata nello stesso server in un data center di Azure per garantire che le query che recuperano i dati da una singola partizione vengano eseguite rapidamente.

Microsoft ha pubblicato obiettivi di scalabilità per Archiviazione di Azure. Se è probabile che il sistema superi questi limiti, valutare la possibilità di suddividere le entità in più tabelle. Usare il partizionamento verticale per dividere i campi nei gruppi a cui è più probabile che sia possibile accedere insieme.

Il diagramma seguente illustra la struttura logica di un account di archiviazione di esempio. L'account di archiviazione contiene tre tabelle: Informazioni cliente, Informazioni prodotto e Info ordine.

Ogni tabella ha più partizioni.

• Nella tabella Informazioni cliente i dati vengono partizionati in base alla città in cui si trova il cliente. La chiave di riga contiene l'ID cliente.
• Nella tabella Informazioni prodotto i prodotti vengono partizionati per categoria di prodotto e il codice di riga contiene il numero di prodotto.
• Nella tabella Order Info gli ordini vengono partizionati in base alla data dell'ordine e la chiave di riga specifica l'ora di ricezione dell'ordine. Tutti i dati vengono ordinati in base alla chiave di riga in ogni partizione.

Quando si progettano le entità per l'archiviazione tabelle di Azure, tenere presente quanto segue:

• Selezionare una chiave di partizione e una chiave di riga in base alla modalità di accesso ai dati. Scegliere una combinazione di chiave di partizione/chiave di riga che supporti la maggior parte delle query. Le query più efficienti recuperano i dati specificando la chiave di partizione e la chiave di riga. Le query che specificano una chiave di partizione e un intervallo di chiavi di riga possono essere completate analizzando una singola partizione. Questa operazione è relativamente veloce perché i dati vengono mantenuti nell'ordine delle chiavi di riga. Se le query non specificano quale partizione analizzare, è necessario analizzare ogni partizione.

• Se un'entità ha una chiave naturale, usarla come chiave di partizione e specificare una stringa vuota come chiave di riga. Se un'entità ha una chiave composta costituita da due proprietà, selezionare la proprietà di modifica più lenta come chiave di partizione e l'altra come chiave di riga. Se un'entità ha più di due proprietà chiave, usare una concatenazione delle proprietà per fornire le chiavi di partizione e di riga.

• Se si eseguono regolarmente query che eseguono ricerche sui dati usando campi diversi dalle chiavi di partizione e di riga, è consigliabile implementare il modello di tabella di indice o valutare l'uso di un archivio dati diverso che supporti l'indicizzazione, ad esempio Azure Cosmos DB.

• Se si generano chiavi di partizione usando una sequenza monotonica ( ad esempio "0001", "0002", "0003") e ogni partizione contiene solo una quantità limitata di dati, l'archiviazione tabelle di Azure può raggruppare fisicamente queste partizioni nello stesso server. Archiviazione di Azure presuppone che l'applicazione esegua le query in un intervallo contiguo di partizioni (query di intervallo) ed è ottimizzata per questo caso. Tuttavia, questo approccio può portare ad hotspot, perché è probabile che tutti gli inserimenti di nuove entità vengano concentrati in un'unica estremità dell'intervallo contiguo. Può anche ridurre la scalabilità. Per distribuire il carico in modo più uniforme, è consigliabile eseguire l'hashing della chiave di partizione.

• Archiviazione tabelle di Azure supporta operazioni transazionali per le entità che appartengono alla stessa partizione. Un'applicazione può eseguire più operazioni di inserimento, aggiornamento, eliminazione, sostituzione o unione come unità atomica, purché la transazione non includa più di 100 entità e il payload della richiesta non superi i 4 MB. Le operazioni che si estendono su più partizioni non sono transazionali e potrebbero richiedere l'implementazione della coerenza finale. Per altre informazioni sull'archiviazione tabelle e sulle transazioni, vedere Esecuzione di transazioni di gruppi di entità.

• Considerare la granularità della chiave di partizione:

  • L'uso della stessa chiave di partizione per ogni entità comporta una singola partizione contenuta in un server. Ciò impedisce il ridimensionamento della partizione e concentra il carico su un singolo server. Di conseguenza, questo approccio è adatto solo per l'archiviazione di un numero ridotto di entità. Tuttavia, garantisce che tutte le entità possano partecipare alle transazioni del gruppo di entità.

  • L'uso di una chiave di partizione univoca per ogni entità fa sì che il servizio di archiviazione tabelle crei una partizione separata per ogni entità, con un numero elevato di partizioni di piccole dimensioni. Questo approccio è più scalabile rispetto all'uso di una singola chiave di partizione, ma le transazioni del gruppo di entità non sono possibili. Inoltre, le query che recuperano più di un'entità potrebbero comportare la lettura da più server. Tuttavia, se l'applicazione esegue query di intervallo, l'uso di una sequenza monotonica per le chiavi di partizione potrebbe contribuire a ottimizzare queste query.

  • La condivisione della chiave di partizione in un subset di entità consente di raggruppare le entità correlate nella stessa partizione. Le operazioni che coinvolgono entità correlate possono essere eseguite usando le transazioni del gruppo di entità e le query che recuperano un set di entità correlate possono essere soddisfatte accedendo a un singolo server.

Per altre informazioni, vedere guida alla progettazione di tabelle di Archiviazione di Azure e strategia di partizionamento scalabile.

Partizionamento di Archiviazione BLOB di Azure

Archiviazione BLOB di Azure consente di contenere oggetti binari di grandi dimensioni. Usare BLOB in blocchi in scenari in cui è necessario caricare o scaricare rapidamente volumi elevati di dati. Usare BLOB di pagine per le applicazioni che richiedono l'accesso casuale anziché seriale a parti dei dati.

Ogni BLOB (blocco o pagina) viene mantenuto in un contenitore in un account di archiviazione di Azure. È possibile usare i contenitori per raggruppare i BLOB correlati che hanno gli stessi requisiti di sicurezza. Questo raggruppamento è logico anziché 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 + il nome del BLOB. La chiave di partizione viene usata per partizionare i dati in intervalli e questi intervalli sono con carico bilanciato nel sistema. I BLOB possono essere distribuiti in molti server per aumentare l'accesso, ma 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 che passa a una partizione, limitando il sistema dal bilanciamento del carico efficace. Ad esempio, se sono presenti operazioni quotidiane che usano un oggetto BLOB con un timestamp, ad esempio aaaa-mm-dd, tutto il traffico per tale operazione passa a un server a partizione singola. Prendere invece in considerazione il prefisso del nome con un hash a tre cifre. Per altre informazioni, vedere Partition Naming Convention.

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 coerenza quando si eseguono operazioni di scrittura tra blocchi, pagine e BLOB, eseguire un blocco di scrittura usando un lease blob.

Partizionamento delle code di Archiviazione di Azure

Le code di Archiviazione di Azure consentono di implementare la messaggistica asincrona tra processi. Un account di archiviazione di Azure può contenere un numero qualsiasi di code e ogni coda può contenere un numero qualsiasi di messaggi. L'unica limitazione è lo spazio disponibile nell'account di archiviazione. La dimensione massima di un singolo messaggio è di 64 KB. Se sono necessari messaggi più grandi di questo, è consigliabile usare invece le code del bus di servizio di Azure.

Ogni coda di archiviazione ha un nome univoco all'interno dell'account di archiviazione che lo contiene. Code di partizioni di Azure in base al nome. Tutti i messaggi per la stessa coda vengono archiviati nella stessa partizione, controllata da un singolo server. Le code diverse possono essere gestite da server diversi per bilanciare il carico. L'allocazione delle code ai server è trasparente per le applicazioni e gli utenti.

In un'applicazione su larga scala, non usare la stessa coda di archiviazione per tutte le istanze dell'applicazione perché questo approccio potrebbe causare l'accesso frequente al server che ospita la coda. Usare invece code diverse per diverse aree funzionali dell'applicazione. Le code di Archiviazione di Azure non supportano le transazioni, pertanto l'indirizzamento dei messaggi a code diverse dovrebbe avere un effetto minimo sulla coerenza della messaggistica.

Una coda di Archiviazione di Azure può gestire fino a 2.000 messaggi al secondo. Se è necessario elaborare i messaggi con una frequenza maggiore di questa, è consigliabile creare più code. In un'applicazione globale, ad esempio, creare code di archiviazione separate in account di archiviazione separati per gestire le istanze dell'applicazione in esecuzione in ogni area.

Partizionamento del bus di servizio di Azure

Il bus di servizio di Azure usa un broker di messaggi per gestire i messaggi inviati a una coda o a un argomento del bus di servizio. Per impostazione predefinita, tutti i messaggi inviati a una coda o a un argomento vengono gestiti dallo stesso processo di Broker messaggi. Questa architettura può porre una limitazione alla velocità effettiva complessiva della coda di messaggi. Tuttavia, è anche possibile partizionare una coda o un argomento quando viene creato. A tale scopo, impostare la proprietà EnablePartitioning della coda o della descrizione dell'argomento su true.

Una coda o un argomento partizionato è suddiviso in più frammenti, ognuno dei quali è supportato da un archivio messaggi separato e un broker di messaggi. Il bus di servizio si assume la responsabilità di creare e gestire questi frammenti. Quando un'applicazione invia un messaggio a una coda o a un argomento partizionato, il bus di servizio assegna il messaggio a un frammento per tale coda o argomento. Quando un'applicazione riceve un messaggio da una coda o una sottoscrizione, il bus di servizio controlla ogni frammento per il messaggio successivo disponibile e quindi lo passa all'applicazione per l'elaborazione.

Questa struttura consente di distribuire il carico tra broker messaggi e archivi messaggi, aumentando la scalabilità e migliorando la disponibilità. Se l'archivio messaggi o l'archivio messaggi per un frammento non è temporaneamente disponibile, il bus di servizio può recuperare i messaggi da uno dei frammenti disponibili rimanenti.

Il bus di servizio assegna un messaggio a un frammento come segue:

• Se il messaggio appartiene a una sessione, tutti i messaggi con lo stesso valore per la proprietà SessionId vengono inviati allo stesso frammento.

• Se il messaggio non appartiene a una sessione, ma il mittente ha specificato un valore per la proprietà PartitionKey, tutti i messaggi con lo stesso valore PartitionKey vengono inviati allo stesso frammento.

  Nota

  Se vengono specificate entrambe le proprietà SessionId e PartitionKey, devono essere impostate sullo stesso valore o il messaggio verrà rifiutato.

• Se le proprietà SessionId e PartitionKey per un messaggio non vengono specificate, ma il rilevamento dei duplicati è abilitato, verrà utilizzata la proprietà MessageId. Tutti i messaggi con lo stesso MessageId verranno indirizzati allo stesso frammento.

• Se i messaggi non includono una proprietà SessionId , PartitionKey, o MessageId, il bus di servizio assegna i messaggi ai frammenti in sequenza. Se un frammento non è disponibile, il bus di servizio passerà alla successiva. Ciò significa che un errore temporaneo nell'infrastruttura di messaggistica non causa l'esito negativo dell'operazione di invio di messaggi.

Quando si decide se o come partizionare una coda di messaggi o un argomento del bus di servizio, tenere presente quanto segue:

• Le code e gli argomenti del bus di servizio vengono creati nell'ambito di uno spazio dei nomi del bus di servizio. Il bus di servizio consente attualmente fino a 100 code o argomenti partizionati per spazio dei nomi.

• Ogni spazio dei nomi del bus di servizio impone quote per le risorse disponibili, ad esempio il numero di sottoscrizioni per argomento, il numero di richieste di invio e ricezione simultanee al secondo e il numero massimo di connessioni simultanee che è possibile stabilire. Queste quote sono documentate in quote del bus di servizio. Se si prevede di superare questi valori, creare spazi dei nomi aggiuntivi con code e argomenti personalizzati e distribuire il lavoro in questi spazi dei nomi. In un'applicazione globale, ad esempio, creare spazi dei nomi separati in ogni area e configurare le istanze dell'applicazione in modo da usare le code e gli argomenti nello spazio dei nomi più vicino.

• I messaggi inviati come parte di una transazione devono specificare una chiave di partizione. Può trattarsi di un SessionId, PartitionKeyo proprietà MessageId. Tutti i messaggi inviati come parte della stessa transazione devono specificare la stessa chiave di partizione perché devono essere gestiti dallo stesso processo di Broker messaggi. Non è possibile inviare messaggi a code o argomenti diversi all'interno della stessa transazione.

• Le code e gli argomenti partizionati non possono essere configurati per essere eliminati automaticamente quando diventano inattive.

• Le code e gli argomenti partizionati non possono attualmente essere usati con il protocollo AMQP (Advanced Message Queuing Protocol) se si creano soluzioni multipiattaforma o ibrida.

Partizionamento di Azure Cosmos DB

azure Cosmos DB per NoSQL è un database NoSQL per l'archiviazione di documenti JSON. Un documento in un database di Azure Cosmos DB è una rappresentazione serializzata JSON di un oggetto o di altri dati. Non vengono applicati schemi fissi, ad eccezione del fatto che ogni documento deve contenere un ID univoco.

I documenti sono organizzati in raccolte. È possibile raggruppare i documenti correlati in una raccolta. Ad esempio, in un sistema che gestisce i post di blog, è possibile archiviare il contenuto di ogni post di blog come documento in una raccolta. È anche possibile creare raccolte per ogni tipo di oggetto. In alternativa, in un'applicazione multi-tenant, ad esempio un sistema in cui autori diversi controllano e gestiscono i propri post di blog, è possibile partizionare i blog per autore e creare raccolte separate per ogni autore. Lo spazio di archiviazione allocato alle raccolte è elastico e può ridursi o aumentare in base alle esigenze.

Azure Cosmos DB supporta il partizionamento automatico dei dati in base a una chiave di partizione definita dall'applicazione. Una partizione logica è una partizione che archivia tutti i dati per un singolo valore della chiave di partizione. Tutti i documenti che condividono lo stesso valore per la chiave di partizione vengono inseriti nella stessa partizione logica. Azure Cosmos DB distribuisce i valori in base all'hash della chiave di partizione. Una partizione logica ha una dimensione massima di 20 GB. Pertanto, la scelta della chiave di partizione è una decisione importante in fase di progettazione. Scegliere una proprietà con un'ampia gamma di valori e persino modelli di accesso. Per altre informazioni, vedere Partizione e scalabilità in Azure Cosmos DB.

Se il meccanismo di partizionamento fornito da Azure Cosmos DB non è sufficiente, potrebbe essere necessario partizionare i dati a livello di applicazione. Le raccolte di documenti forniscono un meccanismo naturale per il partizionamento dei dati all'interno di un singolo database. Il modo più semplice per implementare il partizionamento orizzontale consiste nel creare una raccolta per ogni partizione. I contenitori sono risorse logiche e possono estendersi su uno o più server. I contenitori a dimensione fissa hanno un limite massimo di 20 GB e una velocità effettiva di 10.000 UR/sec. I contenitori illimitati non hanno dimensioni di archiviazione massime, ma devono specificare una chiave di partizione. Con il partizionamento orizzontale dell'applicazione, l'applicazione client deve indirizzare le richieste alla partizione appropriata, in genere implementando il proprio meccanismo di mapping in base ad alcuni attributi dei dati che definiscono la chiave di partizione.

Tutti i database vengono creati nel contesto di un account del database Azure Cosmos DB. Un singolo account può contenere diversi database e specifica in quali aree vengono creati i database. Ogni account applica anche il proprio controllo di accesso. È possibile usare gli account Azure Cosmos DB per individuare geograficamente le partizioni (raccolte all'interno dei database) vicino agli utenti che devono accedervi e applicare restrizioni in modo che solo gli utenti possano connettersi a tali partizioni.

Quando si decide come partizionare i dati con Azure Cosmos DB per NoSQL, tenere presente quanto segue:

• Le risorse disponibili per un database Azure Cosmos DB sono soggette alle limitazioni di quota dell'account. Ogni database può contenere una serie di raccolte e ogni raccolta è associata a un livello di prestazioni che regola il limite di velocità delle UR (velocità effettiva riservata) per tale raccolta. Per altre informazioni, vedere abbonamento Azure e limiti e vincoli dei servizi.

• Ogni documento deve avere un attributo che può essere utilizzato per identificare in modo univoco il documento all'interno dell'insieme in cui è contenuto. Questo attributo è diverso dalla chiave di partizione, che definisce la raccolta che contiene il documento. Una raccolta può contenere un numero elevato di documenti. In teoria, è limitato solo dalla lunghezza massima dell'ID documento. L'ID documento può contenere fino a 255 caratteri.

• Tutte le operazioni su un documento vengono eseguite all'interno del contesto di una transazione. Le transazioni hanno come ambito la raccolta in cui è contenuto il documento. Se un'operazione non riesce, viene eseguito il rollback del lavoro eseguito. Mentre un documento è soggetto a un'operazione, tutte le modifiche apportate sono soggette all'isolamento a livello di snapshot. Questo meccanismo garantisce che, ad esempio, una richiesta di creazione di un nuovo documento abbia esito negativo, un altro utente che esegue una query sul database contemporaneamente non visualizzerà un documento parziale che verrà quindi rimosso.

• le query di database hanno anche come ambito il livello di raccolta. Una singola query può recuperare i dati da una sola raccolta. Se è necessario recuperare i dati da più raccolte, è necessario eseguire query su ogni raccolta singolarmente e unire i risultati nel codice dell'applicazione.

• Azure Cosmos DB supporta elementi programmabili che possono essere archiviati in una raccolta insieme a documenti. Tra cui stored procedure, funzioni definite dall'utente e trigger (scritti in JavaScript). Questi elementi possono accedere a qualsiasi documento all'interno della stessa raccolta. Inoltre, questi elementi vengono eseguiti all'interno dell'ambito della transazione di ambiente (nel caso di un trigger che viene attivato come risultato di un'operazione di creazione, eliminazione o sostituzione eseguita su un documento) o avviando una nuova transazione (nel caso di una stored procedure eseguita come risultato di una richiesta client esplicita). Se il codice in un elemento programmabile genera un'eccezione, viene eseguito il rollback della transazione. È possibile usare stored procedure e trigger per mantenere l'integrità e la coerenza tra documenti, ma questi documenti devono far parte della stessa raccolta.

• Le raccolte che si intende contenere nei database devono superare i limiti di velocità effettiva definiti dai livelli di prestazioni delle raccolte. Per altre informazioni, vedere unità richiesta in Azure Cosmos DB. Se si prevede di raggiungere questi limiti, è consigliabile suddividere le raccolte tra database in account diversi per ridurre il carico per raccolta.

Partizionamento di Ricerca intelligenza artificiale di Azure

La possibilità di cercare dati è spesso il metodo principale di navigazione ed esplorazione fornito da molte applicazioni Web. Consente agli utenti di trovare rapidamente risorse (ad esempio, prodotti in un'applicazione di e-commerce) in base a combinazioni di criteri di ricerca. Il servizio di ricerca di intelligenza artificiale offre funzionalità di ricerca full-text sul contenuto Web e include funzionalità come type-ahead, query suggerite basate su corrispondenze vicine e navigazione in base a facet. Per altre informazioni, vedere Che cos'è la ricerca di intelligenza artificiale?.

Ricerca intelligenza artificiale archivia il contenuto ricercabile come documenti JSON in un database. È possibile definire gli indici che specificano i campi ricercabili in questi documenti e fornire queste definizioni alla ricerca di intelligenza artificiale. Quando un utente invia una richiesta di ricerca, Ricerca di intelligenza artificiale usa gli indici appropriati per trovare gli elementi corrispondenti.

Per ridurre i conflitti, l'archiviazione usata da Ricerca di intelligenza artificiale può essere suddivisa in 1, 2, 3, 4, 6 o 12 partizioni e ogni partizione può essere replicata fino a 6 volte. Il prodotto del numero di partizioni moltiplicato per il numero di repliche viene chiamato unità di ricerca (SU). Una singola istanza di Ricerca intelligenza artificiale può contenere un massimo di 36 SU (un database con 12 partizioni supporta solo un massimo di 3 repliche).

Vengono addebitati i costi per ogni unità di streaming allocata al servizio. Man mano che il volume del contenuto ricercabile aumenta o aumenta la frequenza delle richieste di ricerca, è possibile aggiungere le UR a un'istanza esistente di Ricerca di intelligenza artificiale per gestire il carico aggiuntivo. Ricerca di intelligenza artificiale distribuisce i documenti in modo uniforme tra le partizioni. Attualmente non sono supportate strategie di partizionamento manuali.

Ogni partizione può contenere un massimo di 15 milioni di documenti o occupare 300 GB di spazio di archiviazione (a qualsiasi livello inferiore). È possibile creare fino a 50 indici. Le prestazioni del servizio variano e dipendono dalla complessità dei documenti, dagli indici disponibili e dagli effetti della latenza di rete. In media, una singola replica (1 su) deve essere in grado di gestire 15 query al secondo (QPS), anche se è consigliabile eseguire il benchmarking con i propri dati per ottenere una misura più precisa della velocità effettiva. Per altre informazioni, vedere limiti del servizio in Ricerca di intelligenza artificiale.

Si ha un controllo limitato sul modo in cui la ricerca di intelligenza artificiale partiziona i dati per ogni istanza del servizio. In un ambiente globale, tuttavia, è possibile migliorare le prestazioni e ridurre ulteriormente la latenza e contesa partizionando il servizio stesso usando una delle strategie seguenti:

• Creare un'istanza di Ricerca di intelligenza artificiale in ogni area geografica e assicurarsi che le applicazioni client vengano indirizzate all'istanza più vicina disponibile. Questa strategia richiede che tutti gli aggiornamenti per il contenuto ricercabile vengano replicati in modo tempestivo in tutte le istanze del servizio.

• Creare due livelli di Ricerca intelligenza artificiale:

  • Un servizio locale in ogni area che contiene i dati a cui accedono più frequentemente gli utenti in tale area. Gli utenti possono indirizzare le richieste qui per risultati rapidi ma limitati.
  • Un servizio globale che include tutti i dati. Gli utenti possono indirizzare le richieste qui per risultati più lenti ma più completi.

Questo approccio è più adatto quando si verifica una variazione regionale significativa nei dati di cui viene eseguita la ricerca.

Partizionamento di Cache Redis di Azure

Cache Redis di Azure offre un servizio di memorizzazione nella cache condivisa nel cloud basato sull'archivio dati chiave-valore redis. Come suggerisce il nome, Cache Redis di Azure è destinata a una soluzione di memorizzazione nella cache. Usarlo solo per contenere dati temporanei e non come archivio dati permanente. Le applicazioni che usano Cache Redis di Azure devono essere in grado di continuare a funzionare se la cache non è disponibile. Cache Redis di Azure supporta la replica primaria/secondaria per offrire disponibilità elevata, ma attualmente limita le dimensioni massime della cache a 53 GB. Se è necessario più spazio di questo, è necessario creare cache aggiuntive. Per altre informazioni, vedere Azure Cache for Redis.

Il partizionamento di un archivio dati Redis comporta la suddivisione dei dati tra istanze del servizio Redis. Ogni istanza costituisce una singola partizione. Cache Redis di Azure astrae i servizi Redis dietro una facciata e non li espone direttamente. Il modo più semplice per implementare il partizionamento consiste nel creare più istanze di Cache Redis di Azure e distribuire i dati tra di essi.

È possibile associare ogni elemento di dati a un identificatore (una chiave di partizione) che specifica la cache in cui è archiviato l'elemento di dati. La logica dell'applicazione client può quindi usare questo identificatore per instradare le richieste alla partizione appropriata. Questo schema è molto semplice, ma se lo schema di partizionamento cambia (ad esempio, se vengono create altre istanze di Cache Redis di Azure), le applicazioni client potrebbero dover essere riconfigurate.

Redis nativo (non Cache Redis di Azure) supporta il partizionamento lato server basato sul clustering Redis. In questo approccio è possibile dividere i dati in modo uniforme tra server usando un meccanismo di hashing. Ogni server Redis archivia i metadati che descrivono l'intervallo di chiavi hash contenute nella partizione e contiene anche informazioni sulle chiavi hash che si trovano nelle partizioni in altri server.

Le applicazioni client inviano semplicemente richieste a uno dei server Redis partecipanti (probabilmente quello più vicino). Il server Redis esamina la richiesta client. Se può essere risolto in locale, esegue l'operazione richiesta. In caso contrario, inoltra la richiesta al server appropriato.

Questo modello viene implementato usando il clustering Redis ed è descritto in modo più dettagliato nell'esercitazione cluster Redis pagina sul sito Web Redis. Il clustering Redis è trasparente per le applicazioni client. È possibile aggiungere altri server Redis al cluster (e i dati possono essere ripartizionati) senza dover riconfigurare i client.

La pagina partizionamento: come suddividere i dati tra più istanze di Redis nel sito Web Redis fornisce altre informazioni sull'implementazione del partizionamento con Redis. Nella parte restante di questa sezione si presuppone che si stia implementando il partizionamento lato client o assistito da proxy.

Quando si decide come partizionare i dati con Cache Redis di Azure, tenere presente quanto segue:

• Cache Redis di Azure non è progettata per fungere da archivio dati permanente, quindi qualsiasi schema di partizionamento implementato, il codice dell'applicazione deve essere in grado di recuperare i dati da una posizione che non è la cache.

• I dati a cui si accede di frequente devono essere mantenuti nella stessa partizione. Redis è un potente archivio chiave-valore che fornisce diversi meccanismi altamente ottimizzati per la strutturazione dei dati. Questi meccanismi possono essere uno dei seguenti:

  • Stringhe semplici (dati binari fino a 512 MB di lunghezza)
  • Tipi di aggregazione come elenchi (che possono fungere da code e stack)
  • Set (ordinati e non ordinati)
  • Hash (che possono raggruppare i campi correlati, ad esempio gli elementi che rappresentano i campi in un oggetto)

• I tipi di aggregazione consentono di associare molti valori correlati alla stessa chiave. Una chiave Redis identifica un elenco, un set o un hash anziché gli elementi di dati contenuti. Questi tipi sono tutti disponibili con Cache Redis di Azure e sono descritti dalla pagina tipi di dati nel sito Web Redis. Ad esempio, in parte di un sistema di e-commerce che tiene traccia degli ordini effettuati dai clienti, i dettagli di ogni cliente possono essere archiviati in un hash Redis che viene chiaveto usando l'ID cliente. Ogni hash può contenere una raccolta di ID ordine per il cliente. Un set Redis separato può contenere gli ordini, strutturati di nuovo come hash e con chiave usando l'ID ordine. La figura 8 mostra questa struttura. Si noti che Redis non implementa alcuna forma di integrità referenziale, quindi è responsabilità dello sviluppatore mantenere le relazioni tra clienti e ordini.

Figura 8. Struttura suggerita nell'archivio Redis per registrare gli ordini dei clienti e i relativi dettagli.

• È possibile implementare il partizionamento verticale archiviando le informazioni correlate in aggregazioni diverse nello stesso database. Ad esempio, in un'applicazione di e-commerce, è possibile archiviare informazioni di accesso comune sui prodotti in un hash Redis e informazioni dettagliate meno frequenti in un altro. Entrambi gli hash possono usare lo stesso ID prodotto come parte della chiave. Ad esempio, è possibile usare "product: nn" (dove nn è l'ID prodotto) per le informazioni sul prodotto e "product_details: nn" per i dati dettagliati. Questa strategia consente di ridurre il volume di dati che è probabile che la maggior parte delle query recuperi.

• È possibile ripartizionare un archivio dati Redis, ma tenere presente che si tratta di un'attività complessa e dispendiosa in termini di tempo. Il clustering Redis può ripartizionare automaticamente i dati, ma questa funzionalità non è disponibile con Cache Redis di Azure. Pertanto, quando si progetta lo schema di partizionamento, provare a lasciare spazio libero sufficiente in ogni partizione per consentire la crescita dei dati prevista nel tempo. Tenere tuttavia presente che Cache Redis di Azure è progettata per memorizzare temporaneamente i dati nella cache e che i dati contenuti nella cache possono avere una durata limitata specificata come valore TTL (Time-to-Live). Per i dati relativamente volatili, la durata (TTL) può essere breve, ma per i dati statici la durata (TTL) può essere molto più lunga. Evitare di archiviare grandi quantità di dati di lunga durata nella cache se è probabile che il volume di questi dati riempia la cache. È possibile specificare un criterio di rimozione che fa sì che Cache Redis di Azure rimuovono i dati se lo spazio è premium.

  Nota

  Quando si usa Cache Redis di Azure, si specificano le dimensioni massime della cache (da 250 MB a 53 GB) selezionando il piano tariffario appropriato. Tuttavia, dopo aver creato una Cache Redis di Azure, non è possibile aumentarne o ridurne le dimensioni.

• I batch e le transazioni Redis non possono estendersi su più connessioni, pertanto tutti i dati interessati da un batch o una transazione devono essere mantenuti nello stesso database (partizione).

  Nota

  Una sequenza di operazioni in una transazione Redis non è necessariamente atomica. I comandi che compongono una transazione vengono verificati e accodati prima dell'esecuzione. Se si verifica un errore durante questa fase, l'intera coda viene rimossa. Tuttavia, dopo l'invio della transazione, i comandi in coda vengono eseguiti in sequenza. Se un comando ha esito negativo, l'esecuzione viene interrotta solo da tale comando. Vengono eseguiti tutti i comandi precedenti e successivi nella coda. Per altre informazioni, visitare la pagina transazioni sul sito Web Redis.

• Redis supporta un numero limitato di operazioni atomico. Le uniche operazioni di questo tipo che supportano più chiavi e valori sono operazioni MGET e MSET. Le operazioni MGET restituiscono una raccolta di valori per un elenco specificato di chiavi e le operazioni MSET archiviano una raccolta di valori per un elenco specificato di chiavi. Se è necessario usare queste operazioni, le coppie chiave-valore a cui fanno riferimento i comandi MSET e MGET devono essere archiviate nello stesso database.

Partizionamento di Azure Service Fabric

Azure Service Fabric è una piattaforma di microservizi che fornisce un runtime per le applicazioni distribuite nel cloud. Service Fabric supporta file eseguibili guest .NET, servizi con stato e senza stato e contenitori. I servizi con stato forniscono una raccolta reliable collection per archiviare in modo permanente i dati in una raccolta chiave-valore all'interno del cluster di Service Fabric. Per altre informazioni sulle strategie per il partizionamento delle chiavi in una raccolta affidabile, vedere Guidelines and recommendations for Reliable Collections in Azure Service Fabric.

Passaggi successivi

• Panoramica di Azure Service Fabric è un'introduzione ad Azure Service Fabric.

• Partition Service Fabric Reliable Services fornisce altre informazioni su Reliable Services in Azure Service Fabric.

Partizionamento di Hub eventi di Azure

di Hub eventi di Azure è progettato per lo streaming di dati su larga scala e il partizionamento è integrato nel servizio per abilitare la scalabilità orizzontale. Ogni consumer legge solo una partizione specifica del flusso di messaggi.

L'autore di eventi è a conoscenza solo della chiave di partizione, non la partizione in cui gli eventi vengono pubblicati. Questa separazione tra chiave e partizione evita che il mittente debba conoscere troppe informazioni sull'elaborazione downstream. È anche possibile inviare eventi direttamente a una determinata partizione, ma in genere non è consigliabile.

Prendere in considerazione la scalabilità a lungo termine quando si seleziona il numero di partizioni. Dopo aver creato un hub eventi, non è possibile modificare il numero di partizioni.

Passaggi successivi

Per altre informazioni sull'uso di partizioni in Hub eventi, vedere Che cos'è Hub eventi?.

Per considerazioni sui compromessi tra disponibilità e coerenza, vedere disponibilità e coerenza in Hub eventi.