Considerazioni sulla piattaforma dati per carichi di lavoro cruciali in Azure

La selezione di una piattaforma dati applicativa efficace è un'ulteriore area decisionale cruciale, che ha implicazioni di vasta portata in altre aree di progettazione. Azure offre una vasta gamma di piattaforme di dati relazionali, non relazionali e analitici, che differiscono notevolmente in termini di funzionalità. È quindi essenziale che i requisiti chiave non funzionali vengano considerati completamente insieme ad altri fattori decisionali, ad esempio coerenza, operabilità, costo e complessità. Ad esempio, la possibilità di operare in una configurazione di scrittura in più aree avrà un impatto critico sull'idoneità per una piattaforma disponibile a livello globale.

Questa area di progettazione si espande sulla progettazione dell'applicazione, fornendo considerazioni chiave e consigli per informare la selezione di una piattaforma dati ottimale.

Importante

Questo articolo fa parte della serie di carichi di lavoro cruciali di Azure Well-Architected. Se non si ha familiarità con questa serie, è consigliabile iniziare con un carico di lavoro cruciale?

I quattro vs di Big Data

Il "Four Vs of Big Data" fornisce un framework per comprendere meglio le caratteristiche dei prerequisiti per una piattaforma dati a disponibilità elevata e il modo in cui i dati possono essere usati per ottimizzare il valore aziendale. Questa sezione illustra quindi come applicare le caratteristiche Volume, Velocity, Variety e Veracity a livello concettuale per semplificare la progettazione di una piattaforma dati usando tecnologie dati appropriate.

• Volume: quantità di dati in arrivo per informare la capacità di archiviazione e i requisiti di suddivisione in livelli, ovvero le dimensioni del set di dati.
• Velocity: velocità con cui vengono elaborati i dati, come batch o flussi continui, ovvero la velocità del flusso.
• Variety: l'organizzazione e il formato dei dati, l'acquisizione di formati strutturati, semistrutturati e non strutturati, ovvero dati in più archivi o tipi.
• Veracity: include la provenienza e la cura dei set di dati considerati per la governance e la garanzia della qualità dei dati, ovvero l'accuratezza dei dati.

Considerazioni sulla progettazione

Volume

• I volumi di dati esistenti (se presenti) e i volumi di dati futuri previsti in base ai tassi di crescita dei dati previsti sono allineati agli obiettivi e ai piani aziendali.

  • Il volume di dati deve includere i dati stessi e indici, log, dati di telemetria e altri set di dati applicabili.
  • Le applicazioni business critical e cruciali di grandi dimensioni in genere generano e archiviano volumi elevati (GB e TB) su base giornaliera.
  • L'espansione dei dati può comportare implicazioni significative sui costi.

• Il volume dei dati può variare a causa di circostanze aziendali mutevoli o procedure di manutenzione.

• Il volume di dati può avere un impatto significativo sulle prestazioni delle query della piattaforma dati.

• Può esserci un impatto profondo associato al raggiungimento dei limiti del volume della piattaforma dati.

  • Si verifica un tempo di inattività? e in tal caso, per quanto tempo?
  • Quali sono le procedure di mitigazione? e la mitigazione richiede modifiche all'applicazione?
  • Ci sarà un rischio di perdita di dati?

• È possibile usare funzionalità come TTL (Time to Live) per gestire l'aumento dei dati eliminando automaticamente i record dopo un periodo di tempo trascorso, usando la creazione o la modifica dei record.

  • Ad esempio, Azure Cosmos DB offre una funzionalità TTL predefinita.

Velocità

• La velocità con cui i dati vengono generati da vari componenti dell'applicazione e i requisiti di velocità effettiva per il commit e il recupero dei dati rapidi sono fondamentali per determinare una tecnologia dati ottimale per gli scenari chiave del carico di lavoro.

  • La natura dei requisiti di velocità effettiva varia in base allo scenario del carico di lavoro, ad esempio quelli con un numero elevato di operazioni di lettura o scrittura.
    • Ad esempio, i carichi di lavoro analitici dovranno in genere soddisfare una velocità effettiva di lettura di grandi dimensioni.
  • Qual è la velocità effettiva necessaria? E in che modo la velocità effettiva dovrebbe crescere?
  • Quali sono i requisiti di latenza dei dati a livello di carico P50/P99 ai livelli di carico di riferimento?

• Le funzionalità come il supporto di una progettazione senza blocchi, l'ottimizzazione degli indici e i criteri di coerenza sono fondamentali per ottenere una velocità effettiva elevata.

  • L'ottimizzazione della configurazione per la velocità effettiva elevata comporta compromessi, che devono essere pienamente comprensibili.
  • I modelli di persistenza e messaggistica a livello di carico, ad esempio CQRS ed Event Sourcing, possono essere usati per ottimizzare ulteriormente la velocità effettiva.

• I livelli di carico fluttuano naturalmente per molti scenari dell'applicazione, con picchi naturali che richiedono un grado sufficiente di elasticità per gestire la domanda variabile mantenendo al contempo la velocità effettiva e la latenza.

  • La scalabilità Agile è fondamentale per supportare in modo efficace la velocità effettiva delle variabili e i livelli di carico senza effettuare il provisioning dei livelli di capacità.
    • Sia la velocità effettiva di lettura che di scrittura devono essere ridimensionate in base ai requisiti e al carico dell'applicazione.
    • Le operazioni di scalabilità verticale e orizzontale possono essere applicate per rispondere alla modifica dei livelli di carico.

• L'impatto dei dip della velocità effettiva può variare in base allo scenario del carico di lavoro.

  • Si verifica un'interruzione della connettività?
  • Le singole operazioni restituiscono codici di errore mentre il piano di controllo continua a funzionare?
  • La piattaforma dati attiverà la limitazione e, in tal caso, per quanto tempo?

• La raccomandazione fondamentale per la progettazione di applicazioni per l'uso di una distribuzione geografica attiva-attiva introduce problemi relativi alla coerenza dei dati.

  • Esiste un compromesso tra coerenza e prestazioni per quanto riguarda la semantica transazionale ACID completa e il comportamento di blocco tradizionale.
    • Riducendo al minimo la latenza di scrittura, si verificherà un costo della coerenza dei dati.

• In una configurazione di scrittura in più aree, le modifiche dovranno essere sincronizzate e unite tra tutte le repliche, con la risoluzione dei conflitti, se necessario, e ciò potrebbe influire sui livelli di prestazioni e sulla scalabilità.

• Le repliche di sola lettura (all'interno dell'area e tra aree) possono essere usate per ridurre al minimo la latenza di round trip e distribuire il traffico per migliorare le prestazioni, la velocità effettiva, la disponibilità e la scalabilità.

• È possibile usare un livello di memorizzazione nella cache per aumentare la velocità effettiva di lettura per migliorare l'esperienza utente e i tempi di risposta dei client end-to-end.

  • I criteri e i tempi di scadenza della cache devono essere considerati per ottimizzare le recentizza dei dati.

Varietà

• Il modello di dati, i tipi di dati, le relazioni di dati e il modello di query previsto influiranno fortemente sulle decisioni della piattaforma dati.

  • L'applicazione richiede un modello di dati relazionale o può supportare uno schema variabile o un modello di dati non relazionale?
  • Come eseguirà query sui dati dell'applicazione? E le query dipendono da concetti a livello di database, ad esempio join relazionali? Oppure l'applicazione fornisce tale semantica?

• La natura dei set di dati considerati dall'applicazione può essere variata, dal contenuto non strutturato, ad esempio immagini e video, o da file più strutturati, ad esempio CSV e Parquet.

  • I carichi di lavoro di applicazioni compositi avranno in genere set di dati distinti e requisiti associati.

• Oltre alle piattaforme dati relazionali o non relazionali, le piattaforme dati a grafo o chiave-valore possono essere adatte anche per determinati carichi di lavoro di dati.

  • Alcune tecnologie riguardano i modelli di dati a schema variabile, in cui gli elementi di dati sono semanticamente simili e/o archiviati e sottoposti a query insieme, ma differiscono strutturalmente.

• In un'architettura di microservizi, i singoli servizi applicazioni possono essere compilati con archivi dati distinti ottimizzati per gli scenari anziché in base a un singolo archivio dati monolitico.

  • I modelli di progettazione come SAGA possono essere applicati per gestire la coerenza e le dipendenze tra archivi dati diversi.
    • Le query dirette tra database possono imporre vincoli di condivisione della posizione.
  • L'uso di più tecnologie dati aggiungerà un grado di sovraccarico di gestione per mantenere le tecnologie includono.

• I set di funzionalità per ogni servizio di Azure variano in linguaggi, SDK e API, che possono influire notevolmente sul livello di ottimizzazione della configurazione che può essere applicato.

• Le funzionalità per l'allineamento ottimizzato con il modello di dati e i tipi di dati inclusi influiranno fortemente sulle decisioni della piattaforma dati.

  • Livelli di query, ad esempio stored procedure e mapper relazionali a oggetti.
  • Funzionalità di query indipendente dal linguaggio, ad esempio un livello API REST protetto.
  • Funzionalità di continuità aziendale, ad esempio backup e ripristino.

• Gli archivi dati analitici supportano in genere l'archiviazione poliglotta per vari tipi di strutture di dati.

  • Gli ambienti di runtime analitici, ad esempio Apache Spark, possono avere restrizioni di integrazione per analizzare le strutture di dati poliglotta.

• In un contesto aziendale, l'uso di processi e strumenti esistenti e la continuità delle competenze può avere un impatto significativo sulla progettazione della piattaforma dati e sulla selezione di tecnologie dati.

Veridicità

• È necessario considerare diversi fattori per convalidare l'accuratezza dei dati all'interno di un'applicazione e la gestione di questi fattori può avere un impatto significativo sulla progettazione della piattaforma dati.

  • Coerenza dei dati.
  • Funzionalità di sicurezza della piattaforma.
  • Governance dei dati.
  • Gestione delle modifiche e evoluzione dello schema.
  • Dipendenze tra set di dati.

• In qualsiasi applicazione distribuita con più repliche di dati esiste un compromesso tra coerenza e latenza, come espresso nei teoremi CAP e PACELC .

  • Quando i lettori e i writer vengono distribuiti in modo distinto, un'applicazione deve scegliere di restituire la versione più veloce disponibile di un elemento di dati, anche se non aggiornata rispetto a una scrittura appena completata (aggiornamento) dell'elemento di dati in un'altra replica o alla versione più aggiornata dell'elemento di dati, che può comportare una latenza aggiuntiva per determinare e ottenere lo stato più recente.
  • La coerenza e la disponibilità possono essere configurate a livello di piattaforma o a livello di singola richiesta di dati.
  • Qual è l'esperienza utente se i dati devono essere serviti da una replica più vicina all'utente che non riflette lo stato più recente di una replica diversa? Ad esempio, l'applicazione può supportare la gestione dei dati non aggiornati?

• In un contesto di scrittura in più aree, quando lo stesso elemento di dati viene modificato in due repliche di scrittura separate prima di poter replicare una delle due modifiche, viene creato un conflitto che deve essere risolto.

  • È possibile applicare criteri di risoluzione dei conflitti standardizzati, ad esempio "Ultime vittorie di scrittura" o una strategia personalizzata con logica personalizzata.

• L'implementazione dei requisiti di sicurezza può influire negativamente sulla velocità effettiva o sulle prestazioni.

• La crittografia dei dati inattivi può essere implementata a livello di applicazione usando la crittografia lato client e/o il livello dati usando la crittografia lato server, se necessario.

• supporto tecnico di Azure vari modelli di crittografia, tra cui la crittografia lato server che usa chiavi gestite dal servizio, chiavi gestite dal cliente in Key Vault o chiavi gestite dal cliente su hardware controllato dal cliente.

  • Con la crittografia lato client, le chiavi possono essere gestite in Key Vault o in un'altra posizione sicura.

• La crittografia dei collegamenti dati MACsec (IEEE 802.1AE MAC) viene usata per proteggere tutto il traffico che si sposta tra data center di Azure nella rete backbone Microsoft.

  • I pacchetti vengono crittografati e decrittografati nei dispositivi prima dell'invio, impedendo attacchi fisici "man-in-the-middle" o snooping/intercettazioni.

• Autenticazione e autorizzazione per il piano dati e il piano di controllo.

  • In che modo la piattaforma dati autentica e autorizza l'accesso alle applicazioni e l'accesso operativo?

• Osservabilità tramite il monitoraggio dell'integrità della piattaforma e l'accesso ai dati.

  • Come verrà applicato l'invio di avvisi per condizioni esterne ai limiti operativi accettabili?

Indicazioni sulla progettazione

Volume

• Assicurarsi che i volumi di dati futuri associati alla crescita organica non superino le funzionalità della piattaforma dati.

  • Prevedere i tassi di crescita dei dati allineati ai piani aziendali e usare i tassi stabiliti per informare i requisiti di capacità in corso.
  • Confrontare i volumi di record aggregati e per dati con i limiti della piattaforma dati.
  • Se si verifica un rischio di raggiungimento dei limiti in circostanze eccezionali, assicurarsi che siano applicate mitigazioni operative per evitare tempi di inattività e perdita di dati.

• Monitorare il volume dei dati e convalidarlo rispetto a un modello di capacità, considerando i limiti di scalabilità e i tassi di crescita dei dati previsti.

  • Assicurarsi che le operazioni di scalabilità siano allineate ai requisiti di archiviazione, prestazioni e coerenza.
  • Quando è stata introdotta una nuova unità di scala, potrebbe essere necessario replicare i dati sottostanti che richiedono tempo e probabilmente comportano una riduzione delle prestazioni durante la replica. Assicurarsi quindi che queste operazioni vengano eseguite al di fuori dell'orario di ufficio critico, se possibile.

• Definire i livelli dati dell'applicazione per classificare i set di dati in base all'utilizzo e alla criticità per facilitare la rimozione o l'offload dei dati meno recenti.

  • Valutare la possibilità di classificare i set di dati in livelli "hot", "warm" e "cold" ('archive').
    • Ad esempio, le implementazioni di riferimento di base usano Azure Cosmos DB per archiviare i dati "ad accesso frequente" usati attivamente dall'applicazione, mentre Archiviazione di Azure viene usato per i dati delle operazioni "ad accesso sporadico" a scopo analitico.

• Configurare le procedure di manutenzione per ottimizzare la crescita dei dati e favorire l'efficienza dei dati, ad esempio le prestazioni delle query e la gestione dell'espansione dei dati.

  • Configurare la scadenza TTL (Time-To-Live) per i dati non più necessari e non ha un valore analitico a lungo termine.
    • Verificare che i dati precedenti possano essere a livelli sicuri nell'archiviazione secondaria o eliminati in modo definitivo, senza alcun impatto negativo sull'applicazione.
  • Eseguire l'offload di dati non critici nell'archiviazione ad accesso sporadico secondario, ma mantenerli per il valore analitico e soddisfare i requisiti di controllo.
  • Raccogliere i dati di telemetria e le statistiche di utilizzo della piattaforma dati per consentire ai team DevOps di valutare continuamente i requisiti di manutenzione e gli archivi dati di dimensioni corrette.

• In linea con una progettazione di applicazioni di microservizio, prendere in considerazione l'uso di più tecnologie dati diverse in parallelo, con soluzioni di dati ottimizzate per scenari di carico di lavoro e requisiti di volume specifici.

  • Evitare di creare un singolo archivio dati monolitico in cui il volume di dati dall'espansione può essere difficile da gestire.

Velocità

• La piattaforma dati deve essere progettata e configurata intrinsecamente per supportare una velocità effettiva elevata, con carichi di lavoro separati in contesti diversi per ottimizzare le prestazioni usando soluzioni dati ottimizzate per scenari.

  • Assicurarsi che la velocità effettiva di lettura e scrittura per ogni scenario di dati possa essere ridimensionata in base ai modelli di carico previsti, con tolleranza sufficiente per la varianza imprevista.
  • Separare carichi di lavoro di dati diversi, ad esempio operazioni transazionali e analitiche, in contesti di prestazioni distinti.

• Livello di carico tramite l'uso di messaggistica asincrona non bloccanti, ad esempio usando i modelli CQRS o Event Sourcing .

  • Potrebbe verificarsi una latenza tra le richieste di scrittura e quando i nuovi dati diventano disponibili per la lettura, che potrebbero avere un impatto sull'esperienza utente.
    • Questo impatto deve essere compreso e accettabile nel contesto dei requisiti aziendali chiave.

• Garantire una scalabilità agile per supportare livelli di velocità effettiva e carico variabili.

  • Se i livelli di carico sono altamente volatili, prendere in considerazione l'overprovisioning dei livelli di capacità per garantire la velocità effettiva e le prestazioni mantenute.
  • Testare e convalidare l'impatto sui carichi di lavoro dell'applicazione compositi quando non è possibile gestire la velocità effettiva.

• Assegnare priorità ai servizi dati nativi di Azure con operazioni di scalabilità automatizzate per facilitare una risposta rapida alla volatilità a livello di carico.

  • Configurare la scalabilità automatica in base alle soglie del set di applicazioni e interne del servizio.
  • Il ridimensionamento deve essere avviato e completato in intervalli di tempo coerenti con i requisiti aziendali.
  • Per gli scenari in cui è necessaria l'interazione manuale, stabilire "playbook operativi" automatizzati che possono essere attivati anziché eseguire azioni operative manuali.
    • Valutare se i trigger automatizzati possono essere applicati come parte degli investimenti di progettazione successivi.

• Monitorare la velocità effettiva di lettura e scrittura dei dati dell'applicazione in base ai requisiti di latenza P50/P99 e allinearla a un modello di capacità dell'applicazione.

• La velocità effettiva in eccesso deve essere gestita normalmente dalla piattaforma dati o dal livello dell'applicazione e acquisita dal modello di integrità per la rappresentazione operativa.

• Implementare la memorizzazione nella cache per scenari di dati "ad accesso frequente" per ridurre al minimo i tempi di risposta.

  • Applicare i criteri appropriati per la scadenza della cache e il mantenimento internamente per evitare la crescita dei dati in fuga.
    • Scadere gli elementi della cache quando cambiano i dati di backup.
    • Se la scadenza della cache è strettamente basata su durata (TTL), è necessario comprendere l'impatto e l'esperienza del cliente di gestire i dati obsoleti.

Varietà

• In linea con il principio di una progettazione cloud e nativa di Azure, è consigliabile classificare in ordine di priorità i servizi gestiti di Azure per ridurre la complessità operativa e di gestione e sfruttare i vantaggi degli investimenti futuri della piattaforma Microsoft.

• In linea con il principio di progettazione dell'applicazione di architetture di microservizi ad accoppiamento libero, consentire ai singoli servizi di usare archivi dati distinti e tecnologie di dati ottimizzate per gli scenari.

  • Identificare i tipi di struttura dei dati che l'applicazione gestirà per scenari di carico di lavoro specifici.
  • Evitare di creare una dipendenza da un singolo archivio dati monolitico.
    • Si consideri il modello di progettazione SAGA in cui esistono dipendenze tra archivi dati.

• Verificare che le funzionalità necessarie siano disponibili per le tecnologie dati selezionate.

  • Verificare il supporto per le lingue necessarie e le funzionalità sdk. Non tutte le funzionalità sono disponibili per ogni linguaggio/SDK nello stesso modo.

Veridicità

• Adottare una progettazione della piattaforma dati in più aree e distribuire le repliche tra aree per garantire la massima affidabilità, disponibilità e prestazioni spostando i dati più vicini agli endpoint dell'applicazione.

  • Distribuire repliche di dati tra zone di disponibilità (AZ) all'interno di un'area (o usare i livelli di servizio con ridondanza della zona) per ottimizzare la disponibilità all'interno dell'area.

• Se i requisiti di coerenza lo consentono, usare una progettazione della piattaforma dati di scrittura in più aree per ottimizzare la disponibilità globale e l'affidabilità complessive.

  • Prendere in considerazione i requisiti aziendali per la risoluzione dei conflitti quando lo stesso elemento di dati viene modificato in due repliche di scrittura separate prima che una delle due modifiche possa essere replicata e quindi creando un conflitto.
    • Usare criteri di risoluzione dei conflitti standardizzati, ad esempio "Ultima vittoria", dove possibile
      • Se è necessaria una strategia personalizzata con logica personalizzata, assicurarsi che le procedure DevOps CI/CD vengano applicate per gestire la logica personalizzata.

• Testare e convalidare le funzionalità di backup e ripristino e le operazioni di failover tramite test chaos all'interno di processi di recapito continuo.

• Eseguire benchmark delle prestazioni per garantire che i requisiti di velocità effettiva e prestazioni non siano interessati dall'inclusione delle funzionalità di sicurezza necessarie, ad esempio la crittografia.

  • Assicurarsi che i processi di recapito continui considerino test di carico rispetto ai benchmark delle prestazioni noti.

• Quando si applica la crittografia, è consigliabile usare chiavi di crittografia gestite dal servizio come modo per ridurre la complessità della gestione.

  • Se è presente un requisito di sicurezza specifico per le chiavi gestite dal cliente, assicurarsi che vengano applicate procedure di gestione delle chiavi appropriate per garantire la disponibilità, il backup e la rotazione di tutte le chiavi considerate.

Nota

Quando si esegue l'integrazione con un'implementazione organizzativa più ampia, è fondamentale applicare un approccio incentrato sulle applicazioni per il provisioning e il funzionamento dei componenti della piattaforma dati in una progettazione di applicazioni.

In particolare, per ottimizzare l'affidabilità, è fondamentale che i singoli componenti della piattaforma dati rispondano in modo appropriato all'integrità dell'applicazione tramite azioni operative che possono includere altri componenti dell'applicazione. Ad esempio, in uno scenario in cui sono necessarie risorse aggiuntive della piattaforma dati, è probabile che sia necessario ridimensionare la piattaforma dati insieme ad altri componenti dell'applicazione in base a un modello di capacità, potenzialmente tramite il provisioning di unità di scala aggiuntive. Questo approccio sarà infine vincolato se esiste una dipendenza rigida di un team operativo centralizzato per risolvere i problemi relativi alla piattaforma dati in isolamento.

In definitiva, l'uso di servizi dati centralizzati (ovvero DBaaS IT centrale) introduce colli di bottiglia operativi che ostacolano significativamente l'agilità attraverso un'esperienza di gestione in gran parte non testualizzata e devono essere evitati in un contesto cruciale o critico per l'azienda.

Altri riferimenti

Altre indicazioni sulla piattaforma dati sono disponibili nella Guida all'architettura di app Azure lication.

• Albero delle decisioni dell'archivio dati di Azure
• Criteri per la scelta di un archivio dati
• Archivi dati non relazionali
• Archivi dati OLTP relazionali

Archivio dati di scrittura in più aree distribuite a livello globale

Per soddisfare completamente le aspirazioni attive e attive a livello globale di una progettazione di applicazioni, è consigliabile prendere in considerazione una piattaforma dati di scrittura in più aree distribuita, in cui le modifiche alle repliche scrivibili separate vengono sincronizzate e unite tra tutte le repliche, con la risoluzione dei conflitti, se necessario.

Importante

I microservizi potrebbero non richiedere tutti un archivio dati di scrittura in più aree distribuite, pertanto è necessario considerare il contesto architetturale e i requisiti aziendali di ogni scenario di carico di lavoro.

Azure Cosmos DB offre un archivio dati NoSQL distribuito a livello globale e a disponibilità elevata, offrendo operazioni di scrittura in più aree e coerenza ottimizzata predefinita. Le considerazioni e le raccomandazioni di progettazione contenute in questa sezione si concentrerà quindi sull'utilizzo ottimale di Azure Cosmos DB.

Considerazioni relative alla progettazione

Azure Cosmos DB

• Azure Cosmos DB archivia i dati all'interno di contenitori, che sono archivi transazionali indicizzati e basati su righe progettati per consentire letture e scritture transazionali veloci con tempi di risposta nell'ordine di millisecondi.

• Azure Cosmos DB supporta più API diverse con set di funzionalità diversi, ad esempio SQL, Cassandra e MongoDB.

  • Azure Cosmos DB per NoSQL di prima parte fornisce il set di funzionalità più ricco ed è in genere l'API in cui le nuove funzionalità diventeranno disponibili per prime.

• Azure Cosmos DB supporta le modalità gateway e connettività diretta, in cui Direct facilita la connettività tramite TCP ai nodi di replica back-end di Azure Cosmos DB per migliorare le prestazioni con un minor numero di hop di rete, mentre il gateway fornisce connettività HTTPS ai nodi del gateway front-end.

  • La modalità diretta è disponibile solo quando si usa Azure Cosmos DB per NoSQL ed è attualmente supportata solo nelle piattaforme .NET e Java SDK.

• All'interno delle aree abilitate per la zona di disponibilità, Azure Cosmos DB offre il supporto della ridondanza della zona per la disponibilità elevata e la resilienza agli errori di zona all'interno di un'area.

• Azure Cosmos DB gestisce quattro repliche di dati all'interno di una singola area e quando la ridondanza della zona di disponibilità (AZ) è abilitata, Azure Cosmos DB garantisce che le repliche di dati vengano posizionate in più aree di accesso per proteggersi da errori di zona.

  • Il protocollo di consenso di Paxos viene applicato per ottenere il quorum tra le repliche all'interno di un'area.

• Un account Azure Cosmos DB può essere facilmente configurato per replicare i dati in più aree per ridurre il rischio che una singola area diventi non disponibile.

  • La replica può essere configurata con scritture a singola area o scritture in più aree.
    • Con le scritture in una singola area, viene usata un'area primaria "hub" per gestire tutte le operazioni di scrittura e se l'area 'hub' non è più disponibile, è necessario che si verifichi un'operazione di failover per promuovere un'altra area come scrivibile.
    • Con le scritture in più aree, le applicazioni possono scrivere in qualsiasi area di distribuzione configurata, replicando le modifiche tra tutte le altre aree. Se un'area non è disponibile, le aree rimanenti verranno usate per gestire il traffico di scrittura.

• In una configurazione di scrittura in più aree, i conflitti di aggiornamento (inserimento, sostituzione, eliminazione) possono verificarsi in cui i writer aggiornano simultaneamente lo stesso elemento in più aree.

• Azure Cosmos DB offre due criteri di risoluzione dei conflitti, che possono essere applicati per risolvere automaticamente i conflitti.

  • Last Write Wins (LWW) applica un protocollo di sincronizzazione dell'ora usando una proprietà timestamp _ts definita dal sistema come percorso di risoluzione dei conflitti. Se l'elemento è in conflitto con il valore più alto per il percorso di risoluzione dei conflitti diventa vincitore e se più elementi hanno lo stesso valore numerico, il sistema seleziona un vincitore in modo che tutte le aree possano convergere alla stessa versione dell'elemento di cui è stato eseguito il commit.
    • Con conflitti di eliminazione, la versione eliminata prevale sempre sui conflitti di inserimento o sostituzione indipendentemente dal valore del percorso di risoluzione dei conflitti.
    • La priorità dell'ultima scrittura è il criterio di risoluzione dei conflitti predefinito.
    • Quando si usa Azure Cosmos DB per NoSQL, è possibile usare una proprietà numerica personalizzata, ad esempio una definizione di timestamp personalizzata per la risoluzione dei conflitti.
  • I criteri di risoluzione personalizzati consentono alla semantica definita dall'applicazione di riconciliare i conflitti usando una stored procedure di unione registrata che viene richiamata automaticamente quando vengono rilevati conflitti.
    • Il sistema fornisce esattamente una volta la garanzia per l'esecuzione di una routine di tipo merge come parte del protocollo di impegno.
    • I criteri di risoluzione dei conflitti personalizzati sono disponibili solo con Azure Cosmos DB per NoSQL e possono essere impostati solo in fase di creazione del contenitore.

• In una configurazione di scrittura in più aree è presente una dipendenza da una singola area 'hub' di Azure Cosmos DB per eseguire tutte le risoluzioni dei conflitti, con il protocollo di consenso Paxos applicato per ottenere il quorum tra le repliche all'interno dell'area hub.

  • La piattaforma fornisce un buffer di messaggi per i conflitti di scrittura all'interno dell'area hub per il livello di carico e fornire ridondanza per gli errori temporanei.
    • Il buffer è in grado di archiviare alcuni minuti di aggiornamenti di scrittura che richiedono il consenso.

La direzione strategica della piattaforma Azure Cosmos DB consiste nel rimuovere questa dipendenza di una singola area per la risoluzione dei conflitti in una configurazione di scrittura in più aree, usando un approccio di Paxos in 2 fasi per ottenere il quorum a livello globale e all'interno di un'area.

• L'area primaria "hub" è determinata dalla prima area in cui è configurato Azure Cosmos DB.

  • Un ordinamento prioritario è configurato per aree di distribuzione satellite aggiuntive a scopo di failover.

• Il modello di dati e il partizionamento tra partizioni logiche e fisiche svolgono un ruolo importante per ottenere prestazioni e disponibilità ottimali.

• Quando viene distribuita con una singola area di scrittura, Azure Cosmos DB può essere configurato per il failover automatico in base a una priorità di failover definita considerando tutte le repliche di area di lettura.

• L'obiettivo RTO fornito dalla piattaforma Azure Cosmos DB è di circa 10-15 minuti, acquisendo il tempo trascorso per eseguire un failover a livello di area del servizio Azure Cosmos DB se un'emergenza irreversibile influisce sull'area dell'hub.

  • Questo RTO è rilevante anche in un contesto di scrittura in più aree in base alla dipendenza da una singola area "hub" per la risoluzione dei conflitti.
    • Se l'area 'hub' non è più disponibile, le scritture eseguite in altre aree avranno esito negativo dopo il riempimento del buffer dei messaggi perché la risoluzione dei conflitti non sarà in grado di verificarsi finché il servizio non viene eseguito il failover e non viene stabilita una nuova area hub.

La direzione strategica della piattaforma Azure Cosmos DB consiste nel ridurre l'obiettivo RTO a circa 5 minuti consentendo failover a livello di partizione.

• Gli obiettivi del punto di ripristino (RPO) e gli obiettivi del tempo di ripristino (RTO) sono configurabili tramite livelli di coerenza, con un compromesso tra durabilità dei dati e velocità effettiva.

  • Azure Cosmos DB offre un RTO minimo pari a 0 per un livello di coerenza rilassato con scritture in più aree o un RPO pari a 0 per coerenza assoluta con un'area a scrittura singola.

• Azure Cosmos DB offre un contratto di servizio del 99,999% per la disponibilità di lettura e scrittura per gli account di database configurati con più aree di Azure come scrivibili.

  • Il contratto di servizio è rappresentato dalla percentuale di tempo di attività mensile, calcolata come percentuale di errore media del 100%.
  • La tariffa di errore media viene definita come la somma delle tariffe di errore per ogni ora del mese di fatturazione diviso per il numero totale di ore nel mese di fatturazione, in cui la tariffa degli errori è il numero totale di richieste non riuscite diviso per richieste totali durante un intervallo di un'ora specificato.

• Azure Cosmos DB offre un contratto di servizio del 99,99% per velocità effettiva, coerenza, disponibilità e latenza per gli account di database con ambito una singola area di Azure quando configurata con uno dei cinque livelli di coerenza.

  • Un contratto di servizio del 99,99% si applica anche agli account di database che si estendono su più aree di Azure configurate con uno dei quattro livelli di coerenza flessibili.

• Esistono due tipi di velocità effettiva di cui è possibile effettuare il provisioning in Azure Cosmos DB, standard e scalabilità automatica, che vengono misurati usando unità richiesta al secondo (UR/sec).

  • La velocità effettiva standard alloca le risorse necessarie per garantire un valore di UR/s specificato.
    • Standard viene fatturato ogni ora per la velocità effettiva con provisioning.
  • La scalabilità automatica definisce un valore di velocità effettiva massima e Azure Cosmos DB aumenta o riduce automaticamente a seconda del carico dell'applicazione, tra il valore massimo di velocità effettiva e un minimo del 10% del valore massimo di velocità effettiva.
    • La scalabilità automatica viene fatturata ogni ora per la velocità effettiva massima usata.

• La velocità effettiva con provisioning statico con un carico di lavoro variabile può causare errori di limitazione, che influiranno sulla disponibilità percepita dell'applicazione.

  • La scalabilità automatica protegge dagli errori di limitazione consentendo ad Azure Cosmos DB di aumentare le prestazioni in base alle esigenze, mantenendo al contempo la protezione dei costi riducendo le prestazioni quando il carico diminuisce.

• Quando Azure Cosmos DB viene replicato in più aree, le unità richiesta di cui è stato effettuato il provisioning vengono fatturate per area.

• Esiste un delta significativo dei costi tra una configurazione di scrittura in più aree e scrittura a singola area, che in molti casi può rendere proibitiva una piattaforma dati Azure Cosmos DB multimaster.

Lettura/scrittura in un'area singola	Scrittura in una singola area - Doppia area di lettura	Lettura/scrittura in due aree
1 UR	2 UR	4 UR

Il delta tra la scrittura in un'area singola e la scrittura in più aree è in realtà inferiore al rapporto 1:2 riportato nella tabella precedente. In particolare, è previsto un addebito per il trasferimento dei dati tra aree associato agli aggiornamenti di scrittura in una configurazione a scrittura singola, che non viene acquisita all'interno dei costi delle UR come nella configurazione di scrittura in più aree.

• L'archiviazione utilizzata viene fatturata come tariffa fissa per la quantità totale di spazio di archiviazione (GB) utilizzata per ospitare dati e indici per un'ora specifica.

• Sessionè il livello di coerenza predefinito e più ampiamente usato perché i dati vengono ricevuti nello stesso ordine di scrittura.

• Azure Cosmos DB supporta l'autenticazione tramite un'identità Microsoft Entra o chiavi e token di risorse di Azure Cosmos DB, che offrono funzionalità sovrapposte.

• È possibile disabilitare le operazioni di gestione delle risorse usando chiavi o token di risorsa per limitare le chiavi e i token di risorsa solo alle operazioni sui dati, consentendo il controllo degli accessi alle risorse con granularità fine usando il controllo degli accessi in base al ruolo di Microsoft Entra.

  • La limitazione dell'accesso del piano di controllo tramite chiavi o token di risorse disabilita le operazioni del piano di controllo per i client che usano gli SDK di Azure Cosmos DB e deve pertanto essere valutata e testata accuratamente.
  • L'impostazione disableKeyBasedMetadataWriteAccess può essere configurata tramite definizioni IaC del modello di Resource Manager o tramite un Criteri di Azure predefinito.

• Il supporto del controllo degli accessi in base al ruolo di Microsoft Entra in Azure Cosmos DB si applica alle operazioni di gestione del piano di controllo delle risorse e degli account.

  • Gli amministratori di applicazioni possono creare assegnazioni di ruolo per utenti, gruppi, entità servizio o identità gestite per concedere o negare l'accesso alle risorse e alle operazioni sulle risorse di Azure Cosmos DB.
  • Sono disponibili diversi ruoli di controllo degli accessi in base al ruolo predefiniti per l'assegnazione di ruolo e possono essere usati anche ruoli controllo degli accessi in base al ruolo personalizzati per formare combinazioni di privilegi specifiche.
    • Lettore account Cosmos DB consente l'accesso in sola lettura alla risorsa di Azure Cosmos DB.
    • Collaboratore account DocumentDB consente la gestione degli account Azure Cosmos DB, incluse chiavi e assegnazioni di ruolo, ma non abilita l'accesso al piano dati.
    • Operatore Cosmos DB, simile a Collaboratore account DocumentDB, ma non offre la possibilità di gestire chiavi o assegnazioni di ruolo.

• Le risorse di Azure Cosmos DB (account, database e contenitori) possono essere protette da modifiche o eliminazioni non corrette usando blocchi di risorse.

  • I blocchi delle risorse possono essere impostati a livello di account, database o contenitore.
  • Un blocco risorse impostato in su una risorsa verrà ereditato da tutte le risorse figlio. Ad esempio, un set di blocco risorse nell'account Azure Cosmos DB verrà ereditato da tutti i database e i contenitori all'interno dell'account.
  • I blocchi delle risorse si applicano solo alle operazioni del piano di controllo e non impediscono operazioni del piano dati, ad esempio la creazione, la modifica o l'eliminazione di dati.
  • Se l'accesso al piano di controllo non è limitato con disableKeyBasedMetadataWriteAccess, i client saranno in grado di eseguire operazioni del piano di controllo usando le chiavi dell'account.

• Il feed di modifiche di Azure Cosmos DB fornisce un feed ordinato di tempo delle modifiche ai dati in un contenitore di Azure Cosmos DB.

  • Il feed di modifiche include solo operazioni di inserimento e aggiornamento nel contenitore di Azure Cosmos DB di origine; non include eliminazioni.

• Il feed di modifiche può essere usato per mantenere un archivio dati separato dal contenitore primario usato dall'applicazione, con aggiornamenti continui all'archivio dati di destinazione alimentato dal feed di modifiche dal contenitore di origine.

  • Il feed di modifiche può essere usato per popolare un archivio secondario per una ridondanza aggiuntiva della piattaforma dati o per scenari analitici successivi.

• Se le operazioni di eliminazione influiscono regolarmente sui dati all'interno del contenitore di origine, l'archivio alimentato dal feed di modifiche non sarà accurato e non flessivo dei dati eliminati.

  • È possibile implementare un modello di eliminazione temporanea in modo che i record di dati siano inclusi nel feed di modifiche.
    • Anziché eliminare in modo esplicito i record di dati, i record di dati vengono aggiornati impostando un flag ( ad esempio IsDeleted) per indicare che l'elemento viene considerato eliminato.
    • Qualsiasi archivio dati di destinazione alimentato dal feed di modifiche dovrà rilevare ed elaborare gli elementi con un flag eliminato impostato su True; anziché archiviare record di dati eliminati predefinito, sarà necessario eliminare la versione esistente del record di dati nell'archivio di destinazione.
  • Una breve durata (TTL) viene in genere usata con il modello di eliminazione temporanea in modo che Azure Cosmos DB elimini automaticamente i dati scaduti, ma solo dopo che viene riflessa all'interno del feed di modifiche con il flag eliminato impostato su True.
    • Esegue la finalità di eliminazione originale propagando l'eliminazione anche tramite il feed di modifiche.

• Azure Cosmos DB può essere configurato come archivio analitico, che applica un formato di colonna per le query analitiche ottimizzate per risolvere i problemi di complessità e latenza che si verificano con le pipeline ETL tradizionali.

• Azure Cosmos DB esegue automaticamente il backup dei dati a intervalli regolari senza influire sulle prestazioni o sulla disponibilità e senza consumare UR/sec.

• Azure Cosmos DB può essere configurato in base a due modalità di backup distinte.

  • Periodico è la modalità di backup predefinita per tutti gli account, in cui i backup vengono eseguiti a intervalli periodici e i dati vengono ripristinati creando una richiesta con il team di supporto.
    • Il periodo di conservazione periodico predefinito dei backup è di otto ore e l'intervallo di backup predefinito è quattro ore, il che significa che solo i due backup più recenti vengono archiviati per impostazione predefinita.
    • L'intervallo di backup e il periodo di conservazione sono configurabili all'interno dell'account.
      • Il periodo di conservazione massimo si estende a un mese con un intervallo di backup minimo di un'ora.
      • Per configurare la ridondanza dell'archiviazione di backup, è necessaria un'assegnazione di ruolo al ruolo con autorizzazioni di lettura dell'account Di Azure Cosmos DB.
    • Due copie di backup sono incluse senza costi aggiuntivi, ma i backup aggiuntivi comportano costi aggiuntivi.
    • Per impostazione predefinita, i backup periodici vengono archiviati all'interno di archiviazione con ridondanza geografica separata che non è direttamente accessibile.
      • L'archiviazione di backup esiste all'interno dell'area primaria "hub" e viene replicata nell'area abbinata tramite la replica di archiviazione sottostante.
      • La configurazione di ridondanza dell'account di archiviazione di backup sottostante è configurabile nell'archiviazione con ridondanza della zona o nell'archiviazione con ridondanza locale.
    • L'esecuzione di un'operazione di ripristino richiede una richiesta di supporto perché i clienti non possono eseguire direttamente un ripristino.
      • Prima di aprire un ticket di supporto, il periodo di conservazione dei backup deve essere aumentato ad almeno sette giorni entro otto ore dall'evento di perdita dei dati.
    • Un'operazione di ripristino crea un nuovo account Azure Cosmos DB in cui vengono recuperati i dati.
      • Non è possibile usare un account Azure Cosmos DB esistente per il ripristino
      • Per impostazione predefinita, verrà usato un nuovo account Azure Cosmos DB denominato <Azure_Cosmos_account_original_name>-restored<n> .
        • Questo nome può essere modificato, ad esempio riutilizzando il nome esistente se l'account originale è stato eliminato.
    • Se viene effettuato il provisioning della velocità effettiva a livello di database, il backup e il ripristino verranno eseguiti a livello di database
      • Non è possibile selezionare un subset di contenitori da ripristinare.
  • La modalità di backup continuo consente un ripristino a qualsiasi punto di tempo negli ultimi 30 giorni.
    • Le operazioni di ripristino possono essere eseguite per tornare a un punto specifico nel tempo (PITR) con una granularità di un secondo.
    • La finestra disponibile per le operazioni di ripristino è fino a 30 giorni.
      • È anche possibile ripristinare lo stato di creazione di istanze delle risorse.
    • I backup continui vengono eseguiti all'interno di ogni area di Azure in cui è presente l'account Azure Cosmos DB.
      • I backup continui vengono archiviati nella stessa area di Azure di ogni replica di Azure Cosmos DB, usando l'archiviazione con ridondanza locale o l'archiviazione con ridondanza della zona all'interno di aree che supportano zone di disponibilità.
    • È possibile eseguire un ripristino self-service usando gli artefatti portale di Azure o IaC, ad esempio i modelli di Resource Manager.
    • Esistono diverse limitazioni per il backup continuo.
      • La modalità di backup continuo non è attualmente disponibile in una configurazione di scrittura in più aree.
      • Attualmente è possibile configurare solo Azure Cosmos DB per NoSQL e Azure Cosmos DB per MongoDB per il backup continuo.
      • Se un contenitore ha configurato la durata (TTL), i dati ripristinati che hanno superato la durata (TTL) potrebbero essere eliminati immediatamente
    • Un'operazione di ripristino crea un nuovo account Azure Cosmos DB per il ripristino temporizzato.
    • È previsto un costo di archiviazione aggiuntivo per i backup continui e le operazioni di ripristino.

• È possibile eseguire la migrazione degli account Azure Cosmos DB esistenti da periodico a continuo, ma non da continuo a periodico; la migrazione è unidirezionale e non reversibile.

• Ogni backup di Azure Cosmos DB è costituito dai dati stessi e dai dettagli di configurazione per la velocità effettiva di cui è stato effettuato il provisioning, i criteri di indicizzazione, le aree di distribuzione e le impostazioni TTL del contenitore.

  • I backup non contengono impostazioni del firewall, elenchi di controllo di accesso alla rete virtuale, impostazioni dell'endpoint privato, impostazioni di coerenza (un account viene ripristinato con coerenza della sessione), stored procedure, trigger, funzioni definite dall'utente o impostazioni in più aree.
    • I clienti sono responsabili della ridistribuzione delle funzionalità e delle impostazioni di configurazione. Questi non vengono ripristinati tramite il backup di Azure Cosmos DB.
  • Anche i dati dell'archivio analitico di Azure Collegamento a Synapse non sono inclusi nei backup di Azure Cosmos DB.

• È possibile implementare una funzionalità di backup e ripristino personalizzata per scenari in cui gli approcci periodici e continui non sono adatti.

  • Un approccio personalizzato introduce costi significativi e un sovraccarico amministrativo aggiuntivo, che deve essere compreso e valutato attentamente.
    • Gli scenari di ripristino comuni devono essere modellati, ad esempio il danneggiamento o l'eliminazione di un account, un database, un contenitore, nell'elemento di dati.
    • Le procedure di manutenzione devono essere implementate per evitare lo sprawl del backup.
  • Archiviazione di Azure o una tecnologia di dati alternativa può essere usata, ad esempio un contenitore di Azure Cosmos DB alternativo.
    • Archiviazione di Azure e Azure Cosmos DB offrono integrazioni native con i servizi di Azure, ad esempio Funzioni di Azure e Azure Data Factory.

• La documentazione di Azure Cosmos DB indica due opzioni potenziali per l'implementazione di backup personalizzati.

  • Feed di modifiche di Azure Cosmos DB per scrivere dati in una struttura di archiviazione separata.
    • Una funzione di Azure o un processo di applicazione equivalente usa il processore del feed di modifiche per eseguire l'associazione al feed di modifiche ed elaborare gli elementi nell'archiviazione.
  • I backup personalizzati continui o periodici (in batch) possono essere implementati usando il feed di modifiche.
  • Il feed di modifiche di Azure Cosmos DB non riflette ancora le eliminazioni, quindi è necessario applicare un modello di eliminazione temporanea usando una proprietà booleana e una durata (TTL).
    • Questo modello non sarà necessario quando il feed di modifiche fornisce aggiornamenti con fedeltà completa.
  • Connettore di Azure Data Factory per Azure Cosmos DB (connettori API Di Azure Cosmos DB per NoSQL o MongoDB) per copiare i dati.
    • Azure Data Factory (ADF) supporta l'esecuzione manuale e la pianificazione, la finestra a cascata e i trigger basati su eventi.
      • Fornisce il supporto sia per Archiviazione che per Griglia di eventi.
    • ADF è principalmente adatto per le implementazioni periodiche di backup personalizzate a causa dell'orchestrazione orientata ai batch.
      • È meno adatto per le implementazioni di backup continue con eventi frequenti a causa del sovraccarico di esecuzione dell'orchestrazione.
    • Azure Data Factory supporta collegamento privato di Azure per scenari di sicurezza di rete elevati

Azure Cosmos DB viene usato all'interno della progettazione di molti servizi di Azure, quindi un'interruzione significativa a livello di area per Azure Cosmos DB avrà un effetto a catena tra vari servizi di Azure all'interno di tale area. L'impatto preciso su un particolare servizio dipenderà in modo significativo dal modo in cui la progettazione del servizio sottostante usa Azure Cosmos DB.

Indicazioni sulla progettazione

Azure Cosmos DB

• Usare Azure Cosmos DB come piattaforma dati primaria in cui sono consentiti i requisiti.

• Per scenari di carico di lavoro cruciali, configurare Azure Cosmos DB con una replica di scrittura all'interno di ogni area di distribuzione per ridurre la latenza e garantire la massima ridondanza.

  • Configurare l'applicazione in modo da classificare in ordine di priorità l'uso della replica locale di Azure Cosmos DB per operazioni di scrittura e lettura per ottimizzare il carico dell'applicazione, le prestazioni e il consumo di UR/sec a livello di area.
  • La configurazione di scrittura in più aree comporta un costo significativo e deve essere prioritaria solo per gli scenari di carico di lavoro che richiedono la massima affidabilità.

• Per gli scenari di carico di lavoro meno critici, assegnare priorità all'uso della configurazione di scrittura a area singola (quando si usa zone di disponibilità) con repliche in lettura distribuite a livello globale, poiché offre un elevato livello di affidabilità della piattaforma dati (contratto di servizio del 99,999% per il contratto di servizio di lettura, 99,995% per operazioni di scrittura) a un prezzo più interessante.

  • Configurare l'applicazione per l'uso della replica in lettura locale di Azure Cosmos DB per ottimizzare le prestazioni di lettura.

• Selezionare un'area di distribuzione "hub" ottimale in cui si verificherà la risoluzione dei conflitti in una configurazione di scrittura in più aree e tutte le scritture verranno eseguite in una configurazione di scrittura in un'area singola.

  • Prendere in considerazione la distanza rispetto ad altre aree di distribuzione e la latenza associata nella selezione di un'area primaria e le funzionalità necessarie, ad esempio zone di disponibilità supporto.

• Configurare Azure Cosmos DB con ridondanza della zona di disponibilità in tutte le aree di distribuzione con il supporto az per garantire la resilienza agli errori di zona all'interno di un'area.

• Usare Azure Cosmos DB per NoSQL perché offre il set di funzionalità più completo, in particolare in caso di ottimizzazione delle prestazioni.

  • Le API alternative devono essere considerate principalmente per scenari di migrazione o compatibilità.
    • Quando si usano API alternative, verificare che le funzionalità necessarie siano disponibili con il linguaggio selezionato e l'SDK per garantire una configurazione e prestazioni ottimali.

• Usare la modalità connessione diretta per ottimizzare le prestazioni di rete tramite la connettività TCP diretta ai nodi back-end di Azure Cosmos DB, con un numero ridotto di "hop" di rete.

Il contratto di servizio di Azure Cosmos DB viene calcolato in base alla media delle richieste non riuscite, che potrebbero non essere allineate direttamente a un budget di errore del livello di affidabilità del 99,999%. Quando si progetta l'SLO del 99,999%, è quindi fondamentale pianificare l'indisponibilità di scrittura in più aree e a più aree di Azure Cosmos DB, assicurando che una tecnologia di archiviazione di fallback venga posizionata in caso di errore, ad esempio una coda di messaggi persistente per la riproduzione successiva.

• Definire una strategia di partizionamento tra partizioni logiche e fisiche per ottimizzare la distribuzione dei dati in base al modello di dati.

  • Ridurre al minimo le query su più partizioni.
  • Testare e convalidare in modo iterativo la strategia di partizionamento per garantire prestazioni ottimali.

• Selezionare una chiave di partizione ottimale.

  • La chiave di partizione non può essere modificata dopo che è stata creata all'interno della raccolta.
  • La chiave di partizione deve essere un valore della proprietà che non cambia.
  • Selezionare una chiave di partizione con cardinalità elevata, con un'ampia gamma di valori possibili.
  • La chiave di partizione deve distribuire in modo uniforme il consumo di UR e l'archiviazione dei dati in tutte le partizioni logiche per garantire anche il consumo di UR e la distribuzione dell'archiviazione tra le partizioni fisiche.
  • Eseguire query di lettura sulla colonna partizionata per ridurre il consumo e la latenza delle UR.

• L'indicizzazione è anche fondamentale per le prestazioni, quindi assicurarsi che le esclusioni degli indici vengano usate per ridurre i requisiti di UR/sec e archiviazione.

  • Indicizzare solo i campi necessari per filtrare all'interno delle query; progettare indici per i predicati più usati.

• Sfruttare le funzionalità predefinite per la gestione degli errori, i tentativi e l'affidabilità più ampia di Azure Cosmos DB SDK.

  • Implementare la logica di ripetizione dei tentativi all'interno dell'SDK nei client.

• Usare chiavi di crittografia gestite dal servizio per ridurre la complessità della gestione.

  • Se è presente un requisito di sicurezza specifico per le chiavi gestite dal cliente, assicurarsi che vengano applicate procedure di gestione delle chiavi appropriate, ad esempio backup e rotazione.

• Disabilitare l'accesso in scrittura ai metadati basati su chiavi di Azure Cosmos DB applicando il Criteri di Azure predefinito.

• Abilitare Monitoraggio di Azure per raccogliere le metriche chiave e i log di diagnostica, ad esempio la velocità effettiva con provisioning (UR/sec).

  • Instradare i dati operativi di Monitoraggio di Azure in un'area di lavoro Log Analytics dedicata ad Azure Cosmos DB e ad altre risorse globali all'interno della progettazione dell'applicazione.
  • Usare le metriche di Monitoraggio di Azure per determinare se i modelli di traffico dell'applicazione sono adatti per la scalabilità automatica.

• Valutare i modelli di traffico dell'applicazione per selezionare un'opzione ottimale per i tipi di velocità effettiva con provisioning.

  • Prendere in considerazione la velocità effettiva con provisioning con scalabilità automatica per aumentare automaticamente la domanda del carico di lavoro.

• Valutare i suggerimenti sulle prestazioni Microsoft per Azure Cosmos DB per ottimizzare la configurazione lato client e lato server per migliorare la latenza e la velocità effettiva.

• Quando si usa il servizio Azure Kubernetes come piattaforma di calcolo: per i carichi di lavoro a elevato utilizzo di query, selezionare uno SKU del nodo del servizio Azure Kubernetes con funzionalità di rete accelerata per ridurre la latenza e i jitter della CPU.

• Per le distribuzioni in un'area di scrittura singola, è consigliabile configurare Azure Cosmos DB per il failover automatico.

• Livello di carico tramite l'uso di messaggistica asincrona non bloccanti all'interno dei flussi di sistema, che scrivono gli aggiornamenti in Azure Cosmos DB.

  • Prendere in considerazione modelli come la separazione delle responsabilità dei comandi e delle query e l'origine degli eventi.

• Configurare l'account Azure Cosmos DB per i backup continui per ottenere una granularità fine dei punti di ripristino negli ultimi 30 giorni.

  • Prendere in considerazione l'uso dei backup di Azure Cosmos DB in scenari in cui i dati contenuti o l'account Azure Cosmos DB vengono eliminati o danneggiati.
  • Evitare l'uso di un approccio di backup personalizzato, a meno che non sia assolutamente necessario.

• È consigliabile eseguire procedure di ripristino su risorse e dati non di produzione, come parte della preparazione dell'operazione di continuità aziendale standard.

• Definire gli artefatti IaC per ristabilire le impostazioni di configurazione e le funzionalità di un ripristino di backup di Azure Cosmos DB.

• Valutare e applicare le linee guida per il controllo della baseline di sicurezza di Azure per Backup e ripristino di Azure Cosmos DB.

  • BR-1: Garantire backup automatici regolari
  • BR-3: Convalidare tutti i backup, incluse le chiavi gestite dal cliente
  • BR-4, Attenuare il rischio di perdita delle chiavi

• Per i carichi di lavoro analitici che richiedono la disponibilità in più aree, usare l'archivio analitico di Azure Cosmos DB, che applica un formato di colonna per le query analitiche ottimizzate.

Tecnologie di dati relazionali

Per gli scenari con un modello di dati altamente relazionale o dipendenze da tecnologie relazionali esistenti, l'uso di Azure Cosmos DB in una configurazione di scrittura in più aree potrebbe non essere applicabile direttamente. In questi casi, è fondamentale che le tecnologie relazionali usate siano progettate e configurate per sostenere le aspirazioni attive-attive in più aree di una progettazione di applicazioni.

Azure offre molte piattaforme dati relazionali gestite, tra cui database SQL di Azure e Database di Azure per soluzioni relazionali OSS comuni, tra cui MySQL, PostgreSQL e MariaDB. Le considerazioni e le raccomandazioni di progettazione contenute in questa sezione si concentrerà quindi sull'utilizzo ottimale delle versioni di database SQL di Azure e del sistema operativo del database di Azure per ottimizzare l'affidabilità e la disponibilità globale.

Considerazioni relative alla progettazione

• Sebbene le tecnologie dei dati relazionali possano essere configurate per ridimensionare facilmente le operazioni di lettura, le scritture sono in genere vincolate a passare attraverso una singola istanza primaria, che pone un vincolo significativo sulla scalabilità e sulle prestazioni.

• È possibile applicare il partizionamento orizzontale per distribuire i dati e l'elaborazione in più database strutturati identici, partizionando i database orizzontalmente per esplorare i vincoli della piattaforma.

  • Ad esempio, il partizionamento orizzontale viene spesso applicato nelle piattaforme SaaS multi-tenant per isolare i gruppi di tenant in costrutti distinti della piattaforma dati.

Database SQL di Azure

• database SQL di Azure fornisce un motore di database completamente gestito che è sempre in esecuzione nella versione stabile più recente del motore di database di SQL Server e del sistema operativo sottostante.

  • Fornisce funzionalità intelligenti, ad esempio l'ottimizzazione delle prestazioni, il monitoraggio delle minacce e le valutazioni delle vulnerabilità.

• database SQL di Azure offre disponibilità elevata a livello di area predefinita e replica geografica chiavi in mano per distribuire le repliche in lettura tra aree di Azure.

  • Con la replica geografica, le repliche di database secondarie rimangono di sola lettura fino all'avvio di un failover.
  • Fino a quattro repliche secondarie sono supportate nelle stesse aree o in aree diverse.
  • Le repliche secondarie possono essere usate anche per l'accesso alle query di sola lettura per ottimizzare le prestazioni di lettura.
  • Il failover deve essere avviato manualmente, ma può essere sottoposto a wrapping in procedure operative automatizzate.

• database SQL di Azure fornisce Gruppi di failover automatico, che replica i database in un server secondario e consente il failover trasparente in caso di errore.

  • I gruppi di failover automatico supportano la replica geografica di tutti i database del gruppo in un solo server secondario o istanza in un'area diversa.
  • I gruppi di failover automatico non sono attualmente supportati nel livello di servizio Hyperscale.
  • I database secondari possono essere usati per eseguire l'offload del traffico di lettura.

• Le repliche di database del livello di servizio Premium o Business Critical possono essere distribuite tra zone di disponibilità senza costi aggiuntivi.

  • L'anello di controllo viene duplicato anche in più zone come tre anelli di gateway (GW).
    • Il routing a un anello di gateway specifico è controllato da Gestione traffico di Azure.
  • Quando si usa il livello Business Critical, la configurazione con ridondanza della zona è disponibile solo quando viene selezionato l'hardware di calcolo Gen5.

• database SQL di Azure offre un contratto di servizio di disponibilità previsto del 99,99% in tutti i livelli di servizio, ma offre un contratto di servizio superiore del 99,995% per i livelli Business Critical o Premium nelle aree che supportano le zone di disponibilità.

  • database SQL di Azure livelli Business Critical o Premium non configurati per le distribuzioni con ridondanza della zona hanno un contratto di servizio di disponibilità del 99,99%.

• Se configurato con la replica geografica, il livello database SQL di Azure Business Critical fornisce un obiettivo del tempo di ripristino (RTO) di 30 secondi per il 100% delle ore distribuite.

• Se configurato con la replica geografica, il livello database SQL di Azure Business Critical ha un obiettivo del punto di ripristino (RPO) di 5 secondi per il 100% delle ore distribuite.

• database SQL di Azure livello Hyperscale, se configurato con almeno due repliche, ha un contratto di servizio di disponibilità del 99,99%.

• I costi di calcolo associati a database SQL di Azure possono essere ridotti usando uno sconto per la prenotazione.

  • Non è possibile applicare capacità riservata per i database basati su DTU.

• Il ripristino temporizzato può essere usato per restituire un database e i dati contenuti in un momento precedente.

• È possibile usare il ripristino geografico per ripristinare un database da un backup con ridondanza geografica.

Database di Azure per PostgreSQL

• Database di Azure per PostgreSQL è disponibile in tre diverse opzioni di distribuzione:

  • Server singolo, contratto di servizio 99,99%
  • Server flessibile, che offre ridondanza della zona di disponibilità, contratto di servizio 99,99%
  • Hyperscale (Citus), contratto di servizio del 99,95% quando è abilitata la modalità a disponibilità elevata.

• Hyperscale (Citus) offre scalabilità dinamica tramite partizionamento orizzontale senza modifiche dell'applicazione.

  • La distribuzione di righe di tabella tra più server PostgreSQL è fondamentale per garantire query scalabili in Hyperscale (Citus).
  • Più nodi possono contenere collettivamente più dati rispetto a un database tradizionale e in molti casi possono usare CPU di lavoro in parallelo per ottimizzare i costi.

• La scalabilità automatica può essere configurata tramite l'automazione dei runbook per garantire l'elasticità in risposta alla modifica dei modelli di traffico.

• Il server flessibile offre efficienza in termini di costi per i carichi di lavoro non di produzione grazie alla possibilità di arrestare o avviare il server e un livello di calcolo con possibilità di burst adatto per i carichi di lavoro che non richiedono capacità di calcolo continua.

• Non sono previsti costi aggiuntivi per l'archiviazione di backup fino al 100% dell'archiviazione totale del server di cui è stato effettuato il provisioning.

  • L'utilizzo aggiuntivo dell'archiviazione di backup viene addebitato in base a GB/mese utilizzati.

• I costi di calcolo associati a Database di Azure per PostgreSQL possono essere ridotti usando uno sconto per la prenotazione a server singolo o uno sconto per la prenotazione Hyperscale (Citus).

Indicazioni sulla progettazione

• Prendere in considerazione il partizionamento orizzontale per partizionare i database relazionali in base a contesti di dati e applicazioni diversi, consentendo di esplorare i vincoli della piattaforma, ottimizzare la scalabilità e la disponibilità e l'isolamento degli errori.

  • Questa raccomandazione è particolarmente diffusa quando la progettazione dell'applicazione considera tre o più aree di Azure poiché i vincoli tecnologici relazionali possono ostacolare significativamente le piattaforme dati distribuite a livello globale.
  • Il partizionamento orizzontale non è appropriato per tutti gli scenari dell'applicazione, quindi è necessaria una valutazione contestualizzata.

• Classificare in ordine di priorità l'uso di database SQL di Azure in cui esistono requisiti relazionali a causa della maturità nella piattaforma Azure e di un'ampia gamma di funzionalità di affidabilità.

Database SQL di Azure

• Usare il livello di servizio Business Critical per ottimizzare l'affidabilità e la disponibilità, incluso l'accesso alle funzionalità di resilienza critiche.

• Usare il modello di consumo basato su vCore per facilitare la selezione indipendente delle risorse di calcolo e archiviazione, personalizzate in base ai requisiti di volume e velocità effettiva del carico di lavoro.

  • Assicurarsi che venga applicato un modello di capacità definito per informare i requisiti delle risorse di calcolo e archiviazione.
    • Prendere in considerazione capacità riservata per fornire potenziali ottimizzazioni dei costi.

• Configurare il modello di distribuzione con ridondanza della zona per distribuire repliche di database business critical all'interno della stessa area in zone di disponibilità.

• Usare la replica geografica attiva per distribuire repliche leggibili in tutte le aree di distribuzione (fino a quattro).

• Usare i gruppi di failover automatico per fornire il failover trasparente a un'area secondaria, con la replica geografica applicata per fornire la replica ad aree di distribuzione aggiuntive per l'ottimizzazione della lettura e la ridondanza del database.

  • Per gli scenari di applicazione limitati a solo due aree di distribuzione, l'uso dei gruppi di failover automatico deve essere prioritario.

• Prendere in considerazione i trigger operativi automatizzati, in base all'invio di avvisi allineati al modello di integrità dell'applicazione, per eseguire failover in istanze con replica geografica in caso di errore che influisce sul database primario e secondario all'interno del gruppo di failover automatico.

Importante

Per le applicazioni che considerano più di quattro aree di distribuzione, è consigliabile considerare seriamente il partizionamento orizzontale con ambito applicazione o il refactoring dell'applicazione per supportare tecnologie di scrittura in più aree, ad esempio Azure Cosmos DB. Tuttavia, se questo non è fattibile all'interno dello scenario del carico di lavoro dell'applicazione, è consigliabile elevare un'area all'interno di una singola area geografica a uno stato primario che comprende un'istanza con replica geografica in modo più uniforme per l'accesso in lettura distribuito in modo più uniforme.

• Configurare l'applicazione per eseguire query sulle istanze di replica per le query di lettura per ottimizzare le prestazioni di lettura.

• Usare Monitoraggio di Azure e Analisi SQL di Azure per informazioni operative quasi in tempo reale nel database SQL di Azure per il rilevamento degli eventi imprevisti di affidabilità.

• Usare Monitoraggio di Azure per valutare l'utilizzo per tutti i database per determinare se sono state ridimensionate in modo appropriato.

  • Assicurarsi che le pipeline CD considerino test di carico sotto livelli di carico rappresentativi per convalidare il comportamento appropriato della piattaforma dati.

• Calcolare una metrica di integrità per i componenti di database per osservare l'integrità in relazione ai requisiti aziendali e all'utilizzo delle risorse, usando il monitoraggio e gli avvisi per guidare un'azione operativa automatizzata, se appropriato.

  • Assicurarsi che le metriche chiave delle prestazioni delle query siano incorporate in modo da poter eseguire azioni rapide quando si verifica una riduzione delle prestazioni del servizio.

• Ottimizzare query, tabelle e database usando Informazioni dettagliate prestazioni query e raccomandazioni comuni sulle prestazioni fornite da Microsoft.

• Implementare la logica di ripetizione dei tentativi usando l'SDK per attenuare gli errori temporanei che influiscano sulla connettività database SQL di Azure.

• Classificare in ordine di priorità l'uso di chiavi gestite dal servizio quando si applica Transparent Data Encryption (TDE) sul lato server per la crittografia dei dati inattivi.

  • Se sono necessarie chiavi gestite dal cliente o crittografia lato client (AlwaysEncrypted), assicurarsi che le chiavi siano adeguatamente resilienti con i backup e le strutture di rotazione automatizzate.

• Prendere in considerazione l'uso del ripristino temporizzato come playbook operativo per il ripristino da gravi errori di configurazione.

Database di Azure per PostgreSQL

• Il server flessibile è consigliato per usarlo per i carichi di lavoro business critical a causa del supporto della zona di disponibilità.

• Quando si usa Hyperscale (Citus) per i carichi di lavoro business critical, abilitare la modalità a disponibilità elevata per ricevere la garanzia del contratto di servizio del 99,95%.

• Usare la configurazione del server Hyperscale (Citus) per ottimizzare la disponibilità tra più nodi.

• Definire un modello di capacità per l'applicazione per informare i requisiti delle risorse di calcolo e archiviazione all'interno della piattaforma dati.

  • Prendere in considerazione lo sconto per la prenotazione Hyperscale (Citus) per fornire potenziali ottimizzazioni dei costi.

Memorizzazione nella cache per i dati del livello di accesso frequente

È possibile applicare un livello di memorizzazione nella cache in memoria per migliorare una piattaforma dati aumentando significativamente la velocità effettiva di lettura e migliorando i tempi di risposta dei client end-to-end per scenari di dati del livello critico.

Azure offre diversi servizi con funzionalità applicabili per la memorizzazione nella cache delle strutture di dati chiave, con cache di Azure per Redis posizionati per astrarre e ottimizzare l'accesso in lettura alla piattaforma dati. Questa sezione si concentrerà quindi sull'utilizzo ottimale di cache di Azure per Redis negli scenari in cui sono necessarie prestazioni di lettura aggiuntive e durabilità dell'accesso ai dati.

Considerazioni sulla progettazione

• Un livello di memorizzazione nella cache offre una durabilità aggiuntiva per l'accesso ai dati poiché, anche se un'interruzione che influisce sulle tecnologie dati sottostanti, è comunque possibile accedere a uno snapshot dei dati dell'applicazione tramite il livello di memorizzazione nella cache.

• In alcuni scenari di carico di lavoro, la memorizzazione nella cache in memoria può essere implementata all'interno della piattaforma dell'applicazione stessa.

Cache Redis di Azure

• Cache Redis è un sistema di archiviazione noSQL con valore chiave-valore open source in memoria.

• I livelli Enterprise ed Enterprise Flash possono essere distribuiti in una configurazione attiva-attiva in zone di disponibilità all'interno di un'area e in aree di Azure diverse tramite la replica geografica.

  • Se distribuito in almeno tre aree di Azure e tre o più zone di disponibilità in ogni area, con la replica geografica attiva abilitata per tutte le istanze della cache, cache di Azure per Redis fornisce un contratto di servizio del 99,999% per la connettività a un endpoint della cache a livello di area.
  • Quando viene distribuita in tre zone di disponibilità all'interno di una singola area di Azure viene fornito un contratto di servizio di connettività del 99,99%.

• Il livello Enterprise Flash viene eseguito su una combinazione di RAM e memoria flash non volatile e, mentre questo comporta una piccola riduzione delle prestazioni, consente anche dimensioni cache molto grandi, fino a 13 TB con clustering.

• Con la replica geografica, i costi per il trasferimento dei dati tra aree saranno applicabili anche ai costi diretti associati alle istanze della cache.

• La funzionalità Aggiornamenti pianificati non include gli aggiornamenti o gli aggiornamenti di Azure applicati al sistema operativo della macchina virtuale sottostante.

• Durante un'operazione di scalabilità orizzontale durante la migrazione dei dati alle nuove istanze, si verifica un aumento dell'utilizzo della CPU.

Indicazioni sulla progettazione

• Prendere in considerazione un livello di memorizzazione nella cache ottimizzato per scenari di dati "ad accesso frequente" per aumentare la velocità effettiva di lettura e migliorare i tempi di risposta.

• Applicare criteri appropriati per la scadenza e la manutenzione della cache per evitare la crescita dei dati in fuga.

  • Prendere in considerazione la scadenza degli elementi della cache quando i dati di backup cambiano.

Cache Redis di Azure

• Usare lo SKU Premium o Enterprise per ottimizzare l'affidabilità e le prestazioni.

  • Per gli scenari con volumi di dati estremamente grandi, è consigliabile considerare il livello Enterprise Flash.
  • Per gli scenari in cui è necessaria solo la replica geografica passiva, è anche possibile considerare il livello Premium.

• Distribuire istanze di replica usando la replica geografica in una configurazione attiva in tutte le aree di distribuzione considerate.

• Assicurarsi che le istanze di replica vengano distribuite in zone di disponibilità all'interno di ogni area di Azure considerata.

• Usare Monitoraggio di Azure per valutare cache di Azure per Redis.

  • Calcolare un punteggio di integrità per i componenti della cache a livello di area per osservare l'integrità rispetto ai requisiti aziendali e all'utilizzo delle risorse.
  • Osservare e avvisare le metriche chiave, ad esempio utilizzo elevato della CPU, utilizzo elevato della memoria, carico elevato del server e chiavi rimosse per informazioni dettagliate quando ridimensionare la cache.

• Ottimizzare la resilienza della connessione implementando logica di ripetizione dei tentativi, timeout e usando un'implementazione singleton della connessione multiplexer redis.

• Configurare gli aggiornamenti pianificati per prescrivere i giorni e gli orari in cui gli aggiornamenti del server Redis vengono applicati alla cache.

Scenari analitici

È sempre più comune che le applicazioni cruciali considerino scenari analitici come mezzo per favorire un valore aggiuntivo dai flussi di dati inclusi. Gli scenari analitici applicativi e operativi (AIOps) costituiscono quindi un aspetto cruciale della piattaforma dati altamente affidabile.

I carichi di lavoro analitici e transazionali richiedono diverse funzionalità e ottimizzazioni della piattaforma dati per ottenere prestazioni accettabili all'interno dei rispettivi contesti.

Descrizione	Analitico	Transazionale
Caso d'uso	Analizzare volumi di dati molto grandi ("Big Data")	Elaborare volumi molto grandi di singole transazioni
Ottimizzato per	Leggere query e aggregazioni su molti record	Query CRUD (Create/Update/Update/Delete) quasi in tempo reale su pochi record
Caratteristiche chiave	- Consolidare da origini dati di record - Archiviazione basata su colonne - Archiviazione distribuita - Elaborazione parallela - Denormalizzato - Letture e scritture di concorrenza basse - Ottimizzare il volume di archiviazione con la compressione	- Origine dati del record per l'applicazione - Archiviazione basata su righe - Archiviazione contigua - Elaborazione simmetrica -Normalizzato - Letture e scritture di concorrenza elevate, aggiornamenti degli indici - Ottimizzare l'accesso rapido ai dati con l'archiviazione in memoria

Azure Synapse offre una piattaforma analitica aziendale che riunisce dati relazionali e non relazionali con tecnologie Spark, usando l'integrazione predefinita con i servizi di Azure, ad esempio Azure Cosmos DB, per facilitare l'analisi dei Big Data. Le considerazioni sulla progettazione e le raccomandazioni contenute in questa sezione si concentrerà quindi sull'utilizzo ottimale di Azure Synapse e Azure Cosmos DB per gli scenari analitici.

Considerazioni sulla progettazione

• Tradizionalmente, gli scenari analitici su larga scala sono facilitati dall'estrazione dei dati in una piattaforma dati separata ottimizzata per le query analitiche successive.
  • Le pipeline di estrazione, trasformazione e caricamento (ETL) vengono usate per estrarre i dati utilizzeranno la velocità effettiva e influiscono sulle prestazioni del carico di lavoro transazionale.
  • L'esecuzione di pipeline ETL raramente per ridurre la velocità effettiva e gli impatti sulle prestazioni comportano dati analitici meno aggiornati.
  • L'overhead di sviluppo e manutenzione della pipeline ETL aumenta man mano che le trasformazioni dei dati diventano più complesse.
    • Ad esempio, se i dati di origine vengono modificati o eliminati di frequente, le pipeline ETL devono tenere conto di tali modifiche nei dati di destinazione per le query analitiche tramite un approccio aggiuntivo/con controllo delle versioni, il dump e il ricaricamento o le modifiche sul posto sui dati analitici. Ognuno di questi approcci avrà un impatto derivato, ad esempio la ricreazione dell'indice o l'aggiornamento.

Azure Cosmos DB

• Le query analitiche eseguite sui dati transazionali di Azure Cosmos DB vengono in genere aggregate tra partizioni su grandi volumi di dati, usando una velocità effettiva significativa di unità richiesta (UR), che può influire sulle prestazioni dei carichi di lavoro transazionali circostanti.

• L'archivio analitico di Azure Cosmos DB offre un archivio dati orientato alle colonne completamente isolato e schematizzato che consente l'analisi su larga scala sui dati di Azure Cosmos DB da Azure Synapse senza alcun impatto sui carichi di lavoro transazionali di Azure Cosmos DB.

  • Quando un contenitore di Azure Cosmos DB è abilitato come archivio analitico, viene creato internamente un nuovo archivio colonne dai dati operativi nel contenitore. Questo archivio di colonne viene salvato in modo permanente separatamente dall'archivio transazioni orientato alle righe per il contenitore.
  • Le operazioni di creazione, aggiornamento ed eliminazione dei dati operativi vengono sincronizzate automaticamente nell'archivio analitico, quindi non è necessaria alcuna elaborazione ETL o feed di modifiche.
  • La sincronizzazione dei dati dall'archivio operativo all'archivio analitico non utilizza unità richiesta elaborate (UR) di cui è stato effettuato il provisioning nel contenitore o nel database. Non c'è alcun impatto sulle prestazioni sui carichi di lavoro transazionali. L'archivio analitico non richiede l'allocazione di UR aggiuntive in un database o un contenitore di Azure Cosmos DB.
  • La sincronizzazione automatica è il processo in cui le modifiche ai dati operativi vengono sincronizzate automaticamente con l'archivio analitico. La latenza di sincronizzazione automatica è in genere inferiore a due (2) minuti.
    • La latenza di sincronizzazione automatica può richiedere fino a cinque (5) minuti per un database con velocità effettiva condivisa e un numero elevato di contenitori.
    • Al termine della sincronizzazione automatica, è possibile eseguire query sui dati più recenti da Azure Synapse.
  • L'archiviazione dell'archivio analitico usa un modello tariffario basato sul consumo che addebita il volume di dati e il numero di operazioni di lettura e scrittura. I prezzi dell'archivio analitico sono separati dai prezzi dell'archivio transazionale.

• Usando Azure Collegamento a Synapse, è possibile eseguire query sull'archivio analitico di Azure Cosmos DB direttamente da Azure Synapse. In questo modo non è possibile eseguire query sui dati no-ETL, Hybrid Transactional-Analytical Processing (HTAP) di Synapse, in modo che i dati di Azure Cosmos DB possano essere sottoposti a query insieme ad altri carichi di lavoro analitici di Synapse quasi in tempo reale.

• L'archivio analitico di Azure Cosmos DB non è partizionato per impostazione predefinita.

  • Per determinati scenari di query, le prestazioni miglioreranno partizionando i dati dell'archivio analitico usando chiavi usate di frequente nei predicati di query.
  • Il partizionamento viene attivato da un processo in Azure Synapse che esegue un notebook Spark usando Collegamento a Synapse, che carica i dati dall'archivio analitico di Azure Cosmos DB e lo scrive nell'archivio partizionato synapse nell'account di archiviazione primario dell'area di lavoro Synapse.

• I pool SQL Serverless di Azure Synapse Analytics possono eseguire query sull'archivio analitico tramite visualizzazioni aggiornate automaticamente o tramite SELECT / OPENROWSET comandi.

• I pool di Spark di Azure Synapse Analytics possono eseguire query sull'archivio analitico tramite tabelle Spark aggiornate automaticamente o il spark.read comando .

• I dati possono anche essere copiati dall'archivio analitico di Azure Cosmos DB in un pool Synapse SQL dedicato usando Spark, in modo che sia possibile usare le risorse del pool SQL di Azure Synapse di cui è stato effettuato il provisioning.

• I dati dell'archivio analitico di Azure Cosmos DB possono essere sottoposti a query con Azure Synapse Spark.

  • I notebook Spark consentono alle combinazioni di dataframe Spark di aggregare e trasformare i dati analitici di Azure Cosmos DB con altri set di dati e di usare altre funzionalità avanzate di Synapse Spark, inclusa la scrittura di dati trasformati in altri archivi o il training di modelli di Machine Learning aiOps.

• Il feed di modifiche di Azure Cosmos DB può essere usato anche per gestire un archivio dati secondario separato per gli scenari analitici.

Azure Synapse

• Azure Synapse riunisce funzionalità di analisi, tra cui data warehousing SQL, Big Data Spark e Esplora dati per l'analisi dei log e delle serie temporali.

  • Azure Synapse usa servizi collegati per definire connessioni ad altri servizi, ad esempio Archiviazione di Azure.
  • I dati possono essere inseriti in Synapse Analytics tramite attività Copy da origini supportate. Ciò consente l'analisi dei dati in Synapse senza influire sull'archivio dati di origine, ma aggiunge tempi, costi e sovraccarichi di latenza a causa del trasferimento dei dati.
  • I dati possono anche essere sottoposti a query sul posto in archivi esterni supportati, evitando il sovraccarico dell'inserimento e dello spostamento dei dati. Archiviazione di Azure con Data Lake Gen2 è un archivio supportato per Synapse e I dati esportati di Log Analytics possono essere sottoposti a query tramite Synapse Spark.

• Azure Synapse Studio unisce le attività di inserimento ed esecuzione di query.

  • I dati di origine, inclusi i dati dell'archivio analitico di Azure Cosmos DB e i dati di esportazione di Log Analytics, vengono sottoposti a query ed elaborati per supportare business intelligence e altri casi d'uso analitici aggregati.

Indicazioni sulla progettazione

• Assicurarsi che i carichi di lavoro analitici non influiscono sui carichi di lavoro delle applicazioni transazionali per mantenere le prestazioni transazionali.

Analisi delle applicazioni

• Usare Azure Collegamento a Synapse con l'archivio analitico di Azure Cosmos DB per eseguire analisi sui dati operativi di Azure Cosmos DB creando un archivio dati ottimizzato, che non influisce sulle prestazioni transazionali.

  • Abilitare azure Collegamento a Synapse in account Azure Cosmos DB.
  • Creare un contenitore abilitato per l'archivio analitico o abilitare un contenitore esistente per l'archivio analitico.
  • Connettere l'area di lavoro di Azure Synapse all'archivio analitico di Azure Cosmos DB per abilitare i carichi di lavoro analitici in Azure Synapse per eseguire query sui dati di Azure Cosmos DB. Usare un stringa di connessione con una chiave di Azure Cosmos DB di sola lettura.

• Classificare in ordine di priorità l'archivio analitico di Azure Cosmos DB con Azure Collegamento a Synapse anziché usare il feed di modifiche di Azure Cosmos DB per gestire un archivio dati analitici.

  • Il feed di modifiche di Azure Cosmos DB può essere adatto per scenari analitici molto semplici.

AIOps e Analisi operativa

• Creare una singola area di lavoro di Azure Synapse con servizi collegati e set di dati per ogni account di origine Archiviazione di Azure a cui vengono inviati i dati operativi dalle risorse.

• Creare un account di Archiviazione di Azure dedicato e usarlo come account di archiviazione primario dell'area di lavoro per archiviare i dati e i metadati del catalogo dell'area di lavoro di Synapse. Configurarlo con lo spazio dei nomi gerarchico per abilitare Azure Data Lake Gen2.

  • Mantenere la separazione tra i dati analitici di origine e i metadati dell'area di lavoro synapse.
    • Non usare uno degli account Archiviazione di Azure internazionali o globali in cui vengono inviati i dati operativi.

Passaggio successivo

Esaminare le considerazioni relative alle funzionalità di rete.

Rete e connettività