Considerazioni sulla piattaforma dati per carichi di lavoro cruciali in Azure

La selezione di una piattaforma dati dell'applicazione efficace è un'ulteriore area decisionale fondamentale, che ha implicazioni di vasta portata in altre aree di progettazione. Azure offre in definitiva una vasta gamma di piattaforme di dati relazionali, non relazionali e analitiche, che differiscono notevolmente in funzionalità. È quindi essenziale che i requisiti chiave non funzionali siano pienamente considerati insieme ad altri fattori decisionali, ad esempio coerenza, operabilità, costo e complessità. Ad esempio, la possibilità di operare in una configurazione di scrittura multi-area 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 raccomandazioni 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 mission-critical?

Quattro vs di Big Data

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

• Volume: la 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.
• Elocity V: velocità con cui i dati vengono elaborati, come batch o flussi continui, ovvero la frequenza 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

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

  • Il volume di dati deve includere i dati stessi e gli indici, i log, i dati di telemetria e altri set di dati applicabili.
  • Le applicazioni business critical e cruciali in genere generano e archiviano volumi elevati (GB e TB) su base giornaliera.
  • Possono verificarsi implicazioni significative sui costi associati all'espansione dei dati.

• Il volume dei dati può variare a causa della modifica delle circostanze aziendali o delle procedure di pulizia.

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

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

  • Comporterà tempi di inattività? e se così, per quanto tempo?
  • Quali sono le procedure di mitigazione? e la mitigazione richiederà modifiche all'applicazione?
  • Ci sarà un rischio di perdita di dati?

• Le funzionalità come Time to Live (TTL) possono essere usate per gestire la crescita 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 che sono di tipo read-heavy o write-heavy.
    • Ad esempio, i carichi di lavoro analitici devono in genere soddisfare una velocità effettiva di lettura di grandi dimensioni.
  • Qual è la velocità effettiva necessaria? E come aumenta la velocità effettiva?
  • Quali sono i requisiti di latenza dei dati in P50/P99 nei 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 completamente compresi.
  • I modelli di persistenza e messaggistica a livello di carico, ad esempio CQRS e 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 di elasticità sufficiente per gestire la domanda variabile mantenendo 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 sovraprovisioning dei livelli di capacità.
    • Sia la velocità effettiva di lettura che di scrittura devono essere ridimensionate in base ai requisiti dell'applicazione e al carico.
    • Le operazioni di scalabilità verticale e orizzontale possono essere applicate per rispondere alle modifiche dei livelli di carico.

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

  • Ci sarà 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, se necessario, per quanto tempo?

• La raccomandazione fondamentale per la progettazione dell'applicazione per l'uso di una distribuzione geografica 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 tradizionale di blocco.
    • Ridurre al minimo la latenza di scrittura verrà a 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 in cui necessario e ciò potrebbe influire sui livelli di prestazioni e sulla scalabilità.

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

• Un livello di memorizzazione nella cache può essere usato per aumentare la velocità effettiva di lettura per migliorare l'esperienza utente e i tempi di risposta client end-to-end.

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

Varietà

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

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

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

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

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

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

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

  • I modelli di progettazione come SAGA possono essere applicati per gestire coerenza e dipendenze tra archivi dati diversi.
    • Le query dirette tra database possono imporre vincoli di co-location.
  • L'uso di più tecnologie dati aggiungerà un grado di sovraccarico di gestione per mantenere tecnologie incluse.

• I set di funzionalità per ogni servizio di Azure differiscono tra 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 influiscono fortemente sulle decisioni della piattaforma dati.

  • Livelli di query, ad esempio stored procedure e mapping relazionali a oggetti.
  • Funzionalità di query neutrale del 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 poliglot per vari tipi di strutture dati.

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

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

Veridicità

• Diversi fattori devono essere considerati 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 dati è presente un compromesso tra coerenza e latenza, come espresso nei teoremi CAP e PACELC .

  • Quando i lettori e i writer sono distribuiti in modo distinto, un'applicazione deve scegliere di restituire la versione più veloce disponibile di un elemento dati, anche se non aggiornata rispetto a una scrittura appena completata (aggiornamento) di tale elemento 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 richiesta dati individuale.
  • 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, è possibile che l'applicazione supporti 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 modifica, viene creato un conflitto che deve essere risolto.

  • È possibile applicare criteri di risoluzione dei conflitti standardizzati, ad esempio "Last Write Wins" o una strategia personalizzata con logica personalizzata.

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

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

• Azure supporta 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 nell'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 in movimento tra i data center di Azure nella rete backbone Microsoft.

  • I pacchetti vengono crittografati e decrittografati nei dispositivi prima di essere inviati, impedendo attacchi fisici "man-in-the-middle" o snooping/wiretapping.

• 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 l'integrità della piattaforma di monitoraggio e l'accesso ai dati.

  • Come verrà applicato l'avviso per le condizioni esterne ai limiti operativi accettabili?

Consigli sulla progettazione

Volume

• Assicurarsi che i volumi di dati futuri associati alla crescita organica non vengano superate 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 rispetto ai limiti della piattaforma dati.
  • Se si verifica un rischio di raggiungimento dei limiti in circostanze eccezionali, assicurarsi che le mitigazioni operative siano disponibili per evitare tempi di inattività e perdita di dati.

• Monitorare il volume dei dati e convalidarlo su 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 scalabilità, i dati sottostanti potrebbero essere replicati che richiederanno tempo e probabilmente introducono una penalità delle prestazioni durante la replica. Assicurarsi quindi che queste operazioni vengano eseguite al di fuori dell'orario di lavoro critico, se possibile.

• Definire i livelli di 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 classificazione dei set di dati in livelli "hot", "warm" e "cold" ('archive').
    • Ad esempio, le implementazioni di riferimento fondamentali usano Azure Cosmos DB per archiviare dati "ad accesso frequente" attivamente usati dall'applicazione, mentre Archiviazione di Azure viene usata per i dati delle operazioni "a freddo" a scopo analitico.

• Configurare le procedure di pulizia per ottimizzare la crescita dei dati e guidare 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 alcun valore analitico a lungo termine.
    • Verificare che i dati precedenti possano essere a livelli in modo sicuro nell'archiviazione secondaria o eliminati in modo definitivo, senza un impatto negativo sull'applicazione.
  • Offload di dati non critici nell'archiviazione a freddo secondario, ma mantiene tale dati per il valore analitico e per soddisfare i requisiti di controllo.
  • Raccogliere dati di telemetria e statistiche di utilizzo della piattaforma dati per consentire ai team DevOps di valutare continuamente i requisiti di pulizia e gli archivi dati di dimensioni corrette.

• In linea con una progettazione di applicazioni di microservizio, considerare 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 in modo intrinseco per supportare la velocità effettiva elevata, con carichi di lavoro separati in contesti diversi per ottimizzare le prestazioni usando soluzioni di dati ottimizzate per lo scenario.

  • 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 della messaggistica asincrona senza blocco, 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 la scalabilità agile per supportare la velocità effettiva delle variabili e i livelli di carico.

  • Se i livelli di carico sono altamente volatili, prendere in considerazione il sovraprovisioning dei livelli di capacità per garantire la velocità effettiva e le prestazioni vengono mantenute.
  • Testare e convalidare l'impatto sui carichi di lavoro delle applicazioni compositi quando la velocità effettiva non può essere gestita.

• 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 servizi e del set di applicazioni.
  • Il ridimensionamento deve avviare e completare 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é condurre azioni operative manuali.
    • Valutare se i trigger automatizzati possono essere applicati come parte degli investimenti di ingegneria successivi.

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

• La velocità effettiva in eccesso deve essere gestita correttamente dalla piattaforma dati o dal livello 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 criteri appropriati per la scadenza della cache e il mantenimento della casa per evitare la crescita dei dati di runaway.
    • Scadere gli elementi della cache quando i dati di backup cambiano.
    • Se la scadenza della cache è strettamente basata su TTL (Time-To-Live), l'impatto e l'esperienza del cliente di gestire dati obsoleti deve essere compreso.

Varietà

• In allineamento con il principio di una progettazione nativa del cloud e di Azure, è consigliabile assegnare priorità ai servizi di Azure gestiti per ridurre la complessità operativa e di gestione e sfruttare gli investimenti futuri della piattaforma Microsoft.

• In allineamento con il principio di progettazione dell'applicazione di architetture di microservizi con associazione libera, 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.
    • Prendere in considerazione il modello di progettazione SAGA in cui esistono dipendenze tra archivi dati.

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

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

Veridicità

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

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

• Se i requisiti di coerenza consentono, usare una progettazione della piattaforma dati di scrittura in più aree per ottimizzare la disponibilità e l'affidabilità globali 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 di poter replicare una modifica e quindi creare un conflitto.
    • Usare i criteri di risoluzione dei conflitti standardizzati, ad esempio "Last one wins" dove possibile
      • Se è necessaria una strategia personalizzata con logica personalizzata, assicurarsi che le procedure ci/CD DevOps vengano applicate per gestire la logica personalizzata.

• Testare e convalidare le funzionalità di backup e ripristino e le operazioni di failover tramite test di caos nei 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 è previsto 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 integra con un'implementazione organizzativa più ampia, è fondamentale applicare un approccio incentrato sull'applicazione per il provisioning e l'operazione dei componenti della piattaforma dati in una progettazione dell'applicazione.

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, ridimensionare la piattaforma dati insieme ad altri componenti dell'applicazione in base a un modello di capacità sarà probabilmente necessario, potenzialmente tramite il provisioning di unità di scalabilità aggiuntive. Questo approccio sarà infine vincolato se esiste una dipendenza difficile di un team operativo centralizzato per risolvere i problemi correlati alla piattaforma dati in isolamento.

In definitiva, l'uso di servizi dati centralizzati (ovvero DBaaS centrale IT) introduce colli di bottiglia operativi che impediscono significativamente l'agilità attraverso un'esperienza di gestione in gran parte non crittografata e deve essere evitata in un contesto critico o aziendale.

Altri riferimenti

Altre linee guida sulla piattaforma dati sono disponibili all'interno della Guida all'architettura di applicazione Azure.

• 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 multi-area distribuito a livello globale

Per soddisfare completamente le aspirazioni attive attive distribuite a livello globale di una progettazione dell'applicazione, è consigliabile considerare una piattaforma dati di scrittura multi-area distribuita, in cui le modifiche alle repliche scrivibili separate vengono sincronizzate e unite tra tutte le repliche, con risoluzione dei conflitti, se necessario.

Importante

I microservizi potrebbero non richiedere tutti un archivio dati di scrittura multi-area distribuito, pertanto è consigliabile considerare il contesto architettonico 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 su più aree e coerenza tonnibile out-of-the-box. Le considerazioni e i consigli di progettazione all'interno di questa sezione saranno pertanto incentrati sull'utilizzo ottimale di Azure Cosmos DB.

Considerazioni relative alla progettazione

Azure Cosmos DB

• Azure Cosmos DB archivia i dati all'interno di contenitori, indicizzati, archivi transazionali basati su righe progettati per consentire letture transazionali veloci e scritture 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.

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

• Azure Cosmos DB supporta le modalità di connettività gateway e diretta, in cui Direct facilita la connettività tramite TCP ai nodi di replica di Azure Cosmos DB per migliorare le prestazioni con un minor numero di hop di rete, mentre il gateway offre 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.

• Nelle aree abilitate per la zona di disponibilità, Azure Cosmos DB offre il supporto della ridondanza della zona (AZ) per la disponibilità elevata e la resilienza agli errori zonali 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 dati vengano posizionate in più AZ per proteggere da errori zonali.

  • Il protocollo di consenso di Paxos viene applicato per ottenere il quorum tra 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 di una singola area non disponibile.

  • La replica può essere configurata con scritture a area singola o scritture in più aree.
    • Con le scritture in una singola area, viene usata un'area primaria "hub" per gestire tutte le scritture e se questa area 'hub' non è disponibile, un'operazione di failover deve verificarsi per promuovere un'altra area come scrivibile.
    • Con le scritture in più aree, le applicazioni possono scrivere in qualsiasi area di distribuzione configurata, che replica 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, gli aggiornamenti (inserimento, sostituzione, eliminazione) possono verificarsi conflitti 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 dell'orologio di sincronizzazione temporale usando una proprietà timestamp _ts definita dal sistema come percorso di risoluzione dei conflitti. Se un elemento con il valore più alto per il percorso di risoluzione dei conflitti diventa il 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 commit.
    • Con conflitti di eliminazione, la versione eliminata vince 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 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 tipo merge registrata 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.
    • Un criterio di risoluzione dei conflitti personalizzato è disponibile solo con Azure Cosmos DB per NoSQL e può essere impostato solo in fase di creazione del contenitore.

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

  • La piattaforma fornisce un buffer di messaggi per i conflitti di scrittura all'interno dell'area dell'hub per il livello di carico e fornire la 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 singola dipendenza dell'area per la risoluzione dei conflitti in una configurazione di scrittura in più aree, usando un approccio di Paxos a 2 fasi per raggiungere il quorum a livello globale e all'interno di un'area.

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

  • Un ordinamento di priorità è configurato per altre aree di distribuzione satellite a scopo di failover.

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

• Quando viene distribuito 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'RTO fornito dalla piattaforma Azure Cosmos DB è di circa 10-15 minuti, catturando il tempo trascorso per eseguire un failover a livello regionale del servizio Azure Cosmos DB se si verifica un'emergenza irreversibile che influisce sull'area dell'hub.

  • Questo RTO è rilevante anche in un contesto di scrittura in più aree, dato la dipendenza da un'unica area 'hub' per la risoluzione dei conflitti.
    • Se l'area 'hub' non è disponibile, le scritture effettuate in altre aree avranno esito negativo dopo il riempimento del buffer dei messaggi poiché 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'RTO a ~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 di 0 per un livello di coerenza rilassato con scritture in più aree o un RPO pari a 0 per una coerenza forte 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%.
  • Il tasso di errore medio viene definito come somma dei tassi di errore per ogni ora nel 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 suddivise da richieste totali durante un determinato intervallo di un'ora.

• 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 in un'unica 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 rilassati.

• Esistono due tipi di velocità effettiva che possono essere sottoposte a provisioning in Azure Cosmos DB, standard e scalabilità automatica, misurate usando unità richiesta al secondo (UR/s).

  • La velocità effettiva standard alloca le risorse necessarie per garantire un valore ur/s specificato.
    • Standard viene fatturato ogni ora per la velocità effettiva di cui è stato effettuato il provisioning.
  • La scalabilità automatica definisce un valore massimo di velocità effettiva 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 utilizzata.

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

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

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

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

Sola area di lettura/scrittura	Scrittura singola area - Lettura doppia area	Lettura/scrittura doppia area
1 UR	2 UR	4 UR

Il delta tra scrittura a area singola e scrittura in più aree è effettivamente minore del rapporto 1:2 riflesso 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 dell'UR come con la configurazione di scrittura in più aree.

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

• Session è il livello di coerenza predefinito e più ampiamente usato poiché 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 forniscono funzionalità sovrapposte.

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

  • Limitare l'accesso del piano di controllo tramite chiavi o token di risorsa disabilita le operazioni del piano di controllo per i client che usano GLI SDK di Azure Cosmos DB e pertanto deve essere valutato e testato accuratamente.
  • L'impostazione disableKeyBasedMetadataWriteAccess può essere configurata tramite le definizioni IaC del modello di Resource Manager o tramite un Criteri di Azure predefinito.

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

  • Gli amministratori dell'applicazione 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.
  • Esistono diversi ruoli RBAC predefiniti disponibili per l'assegnazione di ruoli e i ruoli di controllo degli accessi in base al ruolo personalizzati possono essere usati anche per formare combinazioni di privilegi specifici.
    • Cosmos DB Account Reader consente l'accesso in sola lettura alla risorsa Azure Cosmos DB.
    • Il collaboratore dell'account DocumentDB consente la gestione degli account Azure Cosmos DB, tra cui chiavi e assegnazioni di ruolo, ma non abilita l'accesso al piano dati.
    • Operatore Cosmos DB, simile al collaboratore dell'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 eliminazione non corrette tramite Blocchi risorse.

  • I blocchi delle risorse possono essere impostati a livello di account, database o contenitore.
  • Un set di blocco risorse in 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 sul piano dati, ad esempio la creazione, la modifica o l'eliminazione dei dati.
  • Se l'accesso al piano di controllo non è limitato con disableKeyBasedMetadataWriteAccess, i client potranno eseguire operazioni del piano di controllo usando le chiavi dell'account.

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

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

• Il feed di modifiche può essere usato per mantenere un archivio dati separato dal contenitore primario usato dall'applicazione, con aggiornamenti in corso 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 la 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 sarà impreciso e inflessibile dei dati eliminati.

  • Un modello di eliminazione temporanea può essere implementato 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; invece di archiviare record di dati eliminati temporanea, sarà necessario eliminare la versione esistente del record di dati nell'archivio di destinazione.
  • Un breve modello di eliminazione temporanea viene in genere usato 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 durante la propagazione dell'eliminazione 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 usare UR/s.

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

  • Periodica è 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 di backup periodico predefinito è di otto ore e l'intervallo di backup predefinito è di quattro ore, ovvero 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 massimo di conservazione si estende a un mese con un intervallo minimo di backup di un'ora.
      • Per configurare la ridondanza dell'archiviazione di backup, è necessaria un'assegnazione di ruolo al ruolo di Lettura 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 Geo-Redundant Storage (GRS) separati che non sono accessibili direttamente.
      • L'archiviazione di backup esiste all'interno dell'area 'hub' primaria e viene replicata nell'area associata tramite la replica di archiviazione sottostante.
      • La configurazione di ridondanza dell'account di archiviazione di backup sottostante è configurabile in Archiviazione con ridondanza della zona o Locally-Redundant archiviazione.
    • 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 a 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 la velocità effettiva viene eseguito il provisioning 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 continua consente un ripristino in qualsiasi momento entro gli 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 esiste l'account Azure Cosmos DB.
      • I backup continui vengono archiviati nella stessa area di Azure di ogni replica di Azure Cosmos DB usando Locally-Redundant Archiviazione (LRS) o 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 modelli di Resource Manager.
    • Esistono diverse limitazioni con Il backup continuo.
      • La modalità di backup continua non è attualmente disponibile in una configurazione di scrittura in più aree.
      • È possibile configurare solo Azure Cosmos DB per NoSQL e Azure Cosmos DB per MongoDB per il backup continuo in questo momento.
      • Se un contenitore ha configurato TTL, i dati ripristinati che hanno superato il relativo 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.

• Gli account Azure Cosmos DB esistenti possono essere migrati da periodici a continui, 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 della configurazione per la velocità effettiva con 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 sessione), stored procedure, trigger, UDF o impostazioni multi-area.
    • I clienti sono responsabili della ridistribuzione delle funzionalità e delle impostazioni di configurazione. Questi non vengono ripristinati tramite il backup di Azure Cosmos DB.
  • Azure Synapse i dati dell'archivio analitico link non sono inclusi anche 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 dati.
    • Le procedure di pulizia devono essere implementate per impedire lo sprawl del backup.
  • Archiviazione di Azure o una tecnologia di dati alternativa può essere usata, ad esempio un contenitore Azure Cosmos DB alternativo.
    • Archiviazione di Azure e Azure Cosmos DB offrono integrazioni native con servizi di Azure, ad esempio Funzioni di Azure e Azure Data Factory.

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

  • Feed di modifiche di Azure Cosmos DB per scrivere dati in una struttura di archiviazione separata.
    • Un processo di applicazione di Azure o equivalente usa il processore del feed di modifiche per associare al feed di modifiche e elaborare gli elementi nell'archiviazione.
  • È possibile implementare backup personalizzati sia continui che periodici (in batch) usando il feed di modifiche.
  • Il feed di modifiche di Azure Cosmos DB non riflette ancora le eliminazioni, pertanto è necessario applicare un modello di eliminazione temporanea usando una proprietà booleana e TTL.
    • Questo modello non sarà necessario quando il feed di modifiche fornisce aggiornamenti con fedeltà completa.
  • Azure Data Factory Connettore per Azure Cosmos DB (Azure Cosmos DB per i connettori API NoSQL o MongoDB) per copiare i dati.
    • Azure Data Factory (ADF) supporta l'esecuzione manuale e la pianificazione, la finestra Tumbling e i trigger basati su eventi.
      • Fornisce il supporto sia per l'archiviazione che per griglia di eventi.
    • ADF è principalmente adatto per le implementazioni di backup personalizzate periodice a causa della sua orchestrazione orientata al batch.
      • È meno adatto per le implementazioni di backup continue con eventi frequenti a causa del sovraccarico dell'esecuzione dell'orchestrazione.
    • ADF 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 a livello di area significativa per Azure Cosmos DB avrà un effetto a catena tra vari servizi di Azure all'interno di tale area. L'impatto preciso di un determinato servizio dipenderà in modo significativo dal modo in cui la progettazione del servizio sottostante usa Azure Cosmos DB.

Consigli 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 ridondanza massima.

  • Configurare l'applicazione per assegnare priorità all'uso della replica locale di Azure Cosmos DB per le scritture e le letture per ottimizzare il carico, le prestazioni e l'utilizzo di UR/s a livello di area.
  • La configurazione di scrittura in più aree prevede un costo significativo e deve essere prioritaria solo per gli scenari di carico di lavoro che richiedono l'affidabilità massima.

• Per 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 di lettura distribuite a livello globale, poiché offre un livello elevato di affidabilità della piattaforma dati (99,999% del contratto di servizio per la lettura, il 99,995% per le operazioni di scrittura) a un prezzo più accattivante.

  • Configurare l'applicazione per usare la replica di lettura di Azure Cosmos DB locale 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 a area singola.

  • Considerare la distanza rispetto ad altre aree di distribuzione e la latenza associata nella selezione di un'area primaria e delle 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 poiché 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 la lingua selezionata e l'SDK per garantire una configurazione e prestazioni ottimali.

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

Il contratto di servizio di Azure Cosmos DB viene calcolato con la media delle richieste non riuscite, che potrebbero non allinearsi direttamente a un budget di errore del livello di affidabilità del 99,999%. Quando si progetta per il 99,999% SLO, è 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 sia posizionata se si verifica un 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 in modo iterativo e convalidare la strategia di partizionamento per garantire prestazioni ottimali.

• Selezionare una chiave di partizione ottimale.

  • La chiave di partizione non può essere modificata dopo la creazione all'interno della raccolta.
  • La chiave di partizione deve essere un valore di 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 l'utilizzo delle UR e l'archiviazione dei dati in tutte le partizioni logiche per garantire l'utilizzo e la distribuzione dell'archiviazione delle UR in tutte le partizioni fisiche.
  • Eseguire query di lettura sulla colonna partizionata per ridurre l'utilizzo e latenza delle UR.

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

  • Indicizza solo i campi necessari per filtrare all'interno di query; indici di progettazione per i predicati più usati.

• Sfruttare le funzionalità di gestione, tentativi e affidabilità predefinite di Azure Cosmos DB SDK.

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

• Usare le 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 dei metadati basati su chiavi di Azure Cosmos DB applicando l'Criteri di Azure predefinita.

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

  • 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 di cui è stato effettuato il provisioning.

  • Prendere in considerazione la velocità effettiva con provisioning automatico 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 velocità effettiva.

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

• Per le distribuzioni di aree di scrittura singole, è consigliabile configurare Azure Cosmos DB per il failover automatico.

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

  • Prendere in considerazione i modelli, ad esempio la separazione dei comandi e la separazione delle responsabilità delle query e l'origine eventi.

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

  • Considerare l'uso dei backup di Azure Cosmos DB negli 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 praticare 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 stabilire nuovamente 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 baseline di sicurezza di Azure per Backup e ripristino di Azure Cosmos DB.

  • BR-1: Assicurare backup regolari automatici
  • BR-3: Convalidare tutti i backup che includono chiavi gestite dal cliente
  • BR-4, Attenuare il rischio di perdite di chiavi

• Per i carichi di lavoro analitici che richiedono la disponibilità in più aree, usare Azure Cosmos DB Analytics Store, 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 direttamente applicabile. In questi casi, è fondamentale che le tecnologie relazionali usate siano progettate e configurate per sostenere le aspirazioni attive a più aree di una progettazione di un'applicazione.

Azure offre molte piattaforme di dati relazionali gestite, tra cui database Azure SQL e database di Azure per soluzioni relazionali osS comuni, tra cui MySQL, PostgreSQL e MariaDB. Le considerazioni e i consigli di progettazione all'interno di questa sezione si concentreranno quindi sull'utilizzo ottimale dei tipi di database di Azure SQL e del sistema operativo database di Azure per ottimizzare l'affidabilità e la disponibilità globale.

Considerazioni relative alla progettazione

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

• Il partizionamento può essere applicato 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 viene spesso applicato nelle piattaforme SaaS multi-tenant per isolare gruppi di tenant in costrutti di piattaforma dati distinti.

Database SQL di Azure

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

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

• Azure SQL Database offre disponibilità elevata e replica geografica a livello di area predefinita per distribuire repliche di lettura tra aree di Azure.

  • Con la replica geografica, le repliche di database secondarie rimangono di sola lettura finché non viene avviato un failover.
  • Fino a quattro secondarie sono supportate nelle stesse aree o 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 eseguito manualmente in procedure operative automatizzate.

• Azure SQL database fornisce gruppi di failover automatico, che replicano i database in un server secondario e consentono il failover trasparente in caso di errore.

  • I gruppi di failover automatico supportano la replica geografica di tutti i database nel gruppo a 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 scaricare il traffico di lettura.

• Le repliche di database a livello di servizio Premium o business critical possono essere distribuite in zone di disponibilità senza costi aggiuntivi.

  • L'anello di controllo viene duplicato anche in più zone come tre anelli del gateway (GW).
    • Il routing a un anello 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.

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

  • Azure SQL livelli business critical o Premium del database non configurati per le distribuzioni ridondanti della zona hanno un contratto di servizio di disponibilità pari al 99,99%.

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

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

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

• I costi di calcolo associati al database di Azure SQL possono essere ridotti usando uno sconto per le prenotazioni.

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

• Il ripristino geografico può essere usato 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 99,95% quando è abilitata la modalità disponibilità elevata.

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

  • La distribuzione di righe di tabella in più server PostgreSQL è fondamentale per garantire query scalabili in Hyperscale (Citus).
  • Più nodi possono contenere collettivamente più dati di 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 del runbook per garantire l'elasticità in risposta alla modifica dei modelli di traffico.

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

• Non è previsto alcun costo aggiuntivo 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 al consumo di GB/mese.

• 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 di prenotazione Hyperscale (Citus).

Consigli sulla progettazione

• Valutare la partizione per partizionare i database relazionali in base a contesti di applicazione e dati 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 di tecnologia relazionale possono impedire significativamente piattaforme dati distribuite a livello globale.
  • Il partizionamento non è appropriato per tutti gli scenari dell'applicazione, quindi è necessaria una valutazione contestualizzata.

• Assegnare priorità all'uso di Azure SQL Database in cui esistono requisiti relazionali a causa della sua maturità nella piattaforma Azure e di una vasta 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 Zone-Redundant per distribuire le 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 Gruppi di failover automatico per fornire un failover trasparente a un'area secondaria, con replica geografica applicata per fornire la replica a aree di distribuzione aggiuntive per l'ottimizzazione e la ridondanza del database di lettura.

  • Per gli scenari dell'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'avviso allineato al modello di integrità dell'applicazione, per eseguire i failover alle istanze con replica geografica se un errore influisce sul gruppo di failover automatico e secondario.

Importante

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

• 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 di Azure SQL per informazioni operative quasi in tempo reale in Azure SQL database 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 del database per osservare l'integrità rispetto ai requisiti aziendali e all'utilizzo delle risorse, usando il monitoraggio e gli avvisi per guidare l'azione operativa automatizzata, se appropriato.

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

• Ottimizzare query, tabelle e database usando Query Performance Insights 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à del database Azure SQL.

• Definire la priorità dell'uso delle chiavi gestite dal servizio durante l'applicazione di Transparent Data Encryption (TDE) lato server per la crittografia inattiva.

  • Se è necessaria la crittografia delle chiavi gestite dal cliente o del 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 errori di configurazione gravi.

Database di Azure per PostgreSQL

• Il server flessibile è consigliabile 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à 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 di prenotazione Hyperscale (Citus) per offrire potenziali ottimizzazioni dei costi.

Memorizzazione nella cache per i dati del livello frequente

Un livello di memorizzazione nella cache in memoria può essere applicato per migliorare una piattaforma dati aumentando significativamente la velocità effettiva di lettura e migliorando i tempi di risposta client end-to-end per scenari di dati a livello frequente.

Azure offre diversi servizi con funzionalità applicabili per la memorizzazione nella cache delle strutture dei dati chiave, con cache di Azure per Redis posizionati per l'astrazione e l'ottimizzazione dell'accesso in lettura alla piattaforma dati. Questa sezione si concentra quindi sull'utilizzo ottimale delle 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 delle tecnologie dati sottostanti può comunque essere accessibile tramite il livello di memorizzazione nella cache.

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

Cache di Azure per Redis

• La cache Redis è un sistema di archiviazione con chiave NoSQL open source NoSQL.

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

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

• Il livello Enterprise Flash viene eseguito in una combinazione di RAM e archiviazione di memoria non volatile e, mentre questo introduce una piccola penalità delle prestazioni, consente anche dimensioni di cache molto grandi, fino a 13 TB con clustering.

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

• La funzionalità Aggiornamenti pianificata non include aggiornamenti o aggiornamenti di Azure applicati al sistema operativo vm sottostante.

• È previsto un aumento dell'utilizzo della CPU durante un'operazione di scalabilità orizzontale mentre i dati vengono migrati a nuove istanze.

Consigli sulla progettazione

• Prendere in considerazione un livello di memorizzazione nella cache ottimizzato per gli 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 della cache e la pulizia per evitare la crescita dei dati runaway.

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

Cache di Azure per Redis

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

  • Per gli scenari con volumi di dati estremamente grandi, è necessario 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 cpu elevata, 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 Redis multiplexer.

• Configurare gli aggiornamenti pianificati per specificare i giorni e i tempi di applicazione degli aggiornamenti del server Redis alla cache.

Scenari analitici

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

I carichi di lavoro analitici e transazionali richiedono diverse funzionalità e ottimizzazioni della piattaforma dati per prestazioni accettabili nei rispettivi contesti.

Descrizione	Analitico	Transazionale
Caso d'uso	Analizzare volumi molto grandi di dati ("Big Data")	Elaborare volumi molto grandi di singole transazioni
Ottimizzato per	Leggere query e aggregazioni su molti record	Query CRUD (Create/Read/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 a concorrenza bassa - 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 servizi di Azure come Azure Cosmos DB per facilitare l'analisi dei Big Data. Le considerazioni e le raccomandazioni relative alla progettazione all'interno di questa sezione sono quindi incentrate sull'utilizzo ottimale di Azure Synapse e Azure Cosmos DB per gli scenari analitici.

Considerazioni sulla progettazione

• In genere, gli scenari analitici su larga scala sono facilitati tramite l'estrazione di 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, dump e ricaricamento o 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 si aggregheranno in genere tra partizioni su grandi volumi di dati, consumando 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 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 del feed di modifiche o ETL.
  • 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 esiste alcun impatto sulle prestazioni sui carichi di lavoro transazionali. L'archivio analitico non richiede l'allocazione di UR aggiuntive in un database o in 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.
    • Non appena viene completata la 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 Synapse Collegamento, è possibile eseguire query sull'archivio analitico di Azure Cosmos DB direttamente da Azure Synapse. Ciò consente l'elaborazione HTAP (Hybrid Transactional-Analytical Processing) ibrida da 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 migliorano 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.

• Azure Synapse pool SQL Serverless di Analisi può eseguire query sull'archivio analitico tramite viste aggiornate automaticamente o tramite SELECT / OPENROWSET comandi.

• Azure Synapse pool di Spark di Analisi può 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 il provisioning Azure Synapse risorse del pool SQL.

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

Archivio Archivio

• 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 i servizi collegati per definire le 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 latenza dovuti al trasferimento dei dati.
  • I dati possono anche essere sottoposti a query sul posto in archivi esterni supportati, evitando il sovraccarico di inserimento e 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 e 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.

Consigli 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 Synapse Collegamento 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 collegamento Azure Synapse per gli 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 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.

• Assegnare priorità all'archivio analitico di Azure Cosmos DB con collegamento Azure Synapse anziché usare il feed di modifiche di Azure Cosmos DB per mantenere un archivio dati analitici.

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

AIOps e Operational Analytics

• Creare una singola area di lavoro Azure Synapse con servizi collegati e set di dati per ogni account di archiviazione di Azure di origine 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 dati dell'area di lavoro Synapse e i metadati.
    • Non usare uno degli account di archiviazione di Azure a livello di area o globale in cui vengono inviati i dati operativi.

Passaggio successivo

Esaminare le considerazioni per le considerazioni sulla rete.

Rete e connettività