Condividi tramite

Schemi progettuali dei feed di modifiche in Azure Cosmos DB

  • Articolo

SI APPLICA A: NoSQL

Il feed di modifiche di Azure Cosmos DB consente l'elaborazione efficiente di set di dati di grandi dimensioni che hanno un volume di scritture elevato. Il feed di modifiche offre anche un'alternativa all'esecuzione di query su un intero set di dati per identificare le modifiche apportate. Questo articolo tratta degli schemi progettuali dei feed di modifiche comuni, dei compromessi di progettazione e delle limitazioni del feed di modifiche.

Azure Cosmos DB è particolarmente adatto per le applicazioni IoT, di videogiochi, del settore della vendita al dettaglio e di registrazioni di operazioni. Uno schema progettuale comune in queste applicazioni prevede l'uso di modifiche ai dati per attivare azioni aggiuntive. Esempi di queste azioni includono:

  • Attivazione di una notifica o di una chiamata a un'API quando viene inserito, aggiornato o eliminato un elemento.
  • Elaborazione di flussi in tempo reale per l'elaborazione IoT o di analisi in tempo reale sui dati operativi.
  • Spostamento dati, ad esempio la sincronizzazione con una cache, un motore di ricerca, un data warehouse o un'archiviazione offline sicura.

Il feed di modifiche in Azure Cosmos DB consente di creare soluzioni efficienti e scalabili per ognuno di questi modelli, come illustrato nell'immagine seguente:

Diagramma che mostra l’uso del feed delle modifiche di Azure Cosmos DB per agevolare le analisi in tempo reale e gli scenari di calcolo guidati dagli eventi.

Elaborazione degli eventi e notifiche

Il feed di modifiche di Azure Cosmos DB può semplificare gli scenari in cui è necessario attivare una notifica o inviare una chiamata a un'API in base a un determinato evento. È possibile usare il processore dei feed di modifiche per eseguire automaticamente il polling delle modifiche nel contenitore quindi chiamare un'API esterna ogni volta che si verifica una scrittura, un aggiornamento o un'eliminazione.

È anche possibile attivare selettivamente una notifica o inviare una chiamata a un'API in base a criteri specifici. Ad esempio, se viene eseguita la lettura dal feed di modifiche usando Funzioni di Azure, è possibile inserire la logica all'interno della funzione per inviare una notifica solo se viene soddisfatta una condizione. Sebbene il codice della funzione di Azure venga eseguito per ogni modifica, la notifica viene inviata solo se la condizione viene soddisfatta.

Elaborazione del flusso in tempo reale

Il feed di modifiche di Azure Cosmos DB può essere usato per l'elaborazione del flusso in tempo reale per IoT o l'elaborazione analitica in tempo reale nei dati operativi. Ad esempio, è possibile ricevere e archiviare i dati evento da dispositivi, sensori, infrastrutture e applicazioni quindi elaborare tali eventi in tempo reale usando Spark. L'immagine seguente mostra come implementare un'architettura lambda usando il feed di modifiche di Azure Cosmos DB:

Diagramma che mostra la pipeline lambda basata su Azure Cosmos DB per l'inserimento e la query.

In molti casi, le implementazioni dell'elaborazione del flusso ricevono innanzitutto un volume elevato di dati in ingresso in una coda di messaggi temporanea, ad esempio Hub eventi di Azure o Apache Kafka. Il feed di modifiche è un'ottima alternativa grazie alla capacità di Azure Cosmos DB di supportare una frequenza elevata prolungata di inserimento di dati con latenza di lettura e scrittura ridotta garantita. I vantaggi del feed di modifiche di Azure Cosmos DB in una coda di messaggi sono i seguenti:

Salvataggio permanente dei dati

I dati scritti in Azure Cosmos DB vengono visualizzati nel feed di modifiche. I dati vengono conservati nel feed di modifiche fino a quando non vengono eliminati se vengono letti utilizzando la modalità versione più recente. Le code di messaggi in genere hanno un periodo di conservazione massimo. Ad esempio, l'Hub eventi di Azure offre una conservazione massima dei dati di 90 giorni.

Funzionalità di query

Oltre a leggere dal feed di modifiche di un contenitore Azure Cosmos DB, è anche possibile eseguire query SQL nei dati archiviati in Azure Cosmos DB. Il feed di modifiche non è una duplicazione dei dati già presenti nel contenitore, ma piuttosto un diverso meccanismo di lettura dei dati. Pertanto, se letti dal feed di modifiche, i dati saranno sempre coerenti con le query dello stesso contenitore di Azure Cosmos DB.

Disponibilità elevata

Azure Cosmos DB offre una disponibilità massima in lettura e scrittura del 99,999%. A differenza di molte code di messaggi, i dati di Azure Cosmos DB possono essere distribuiti e configurati facilmente a livello globale con un obiettivo tempo di ripristino (RTO) uguale a zero.

Dopo aver elaborato gli elementi nel feed di modifiche, è possibile creare una vista materializzata e mantenere i valori aggregati in Azure Cosmos DB. Se si usa Azure Cosmos DB per creare un gioco, è possibile usare, ad esempio, il feed di modifiche per implementare classifiche in tempo reale in base ai punteggi delle partite completate.

Spostamento dati

È anche possibile leggere dal feed di modifiche per lo spostamento dati in tempo reale.

Ad esempio, il feed di modifiche consente di eseguire in modo efficiente le attività seguenti:

  • Aggiornare una cache, un indice di ricerca o un data warehouse con i dati archiviati in Azure Cosmos DB.

  • Eseguire migrazioni senza tempi di inattività a un altro account Azure Cosmos DB o ad un altro contenitore di Azure Cosmos DB che abbia una chiave di partizione logica diversa.

  • Implementare la suddivisione in livelli e l'archiviazione dei dati a livello di applicazione. Ad esempio, è possibile archiviare i "dati ad accesso frequente" in Azure Cosmos DB ed escludere i "dati ad accesso sporadico" in altri sistemi di archiviazione, ad esempio Archiviazione BLOB di Azure.

Quando è necessario denormalizzare i dati tra partizioni e contenitori, è possibile leggere dal feed di modifiche del contenitore come origine per la replica dei dati. La replica dei dati in tempo reale con il feed di modifiche può garantire solo la coerenza finale. È possibile monitorare il ritardo del processore dei feed di modifiche nell'elaborazione delle modifiche nel contenitore Azure Cosmos DB.

Origine degli eventi

Lo schema di origine degli eventi prevede l'uso di un archivio di solo accodamento per registrare la serie completa di azioni nei dati. Il feed di modifiche di Azure Cosmos DB è un'ottima scelta come archivio dati centrale nelle architetture di origine degli eventi in cui tutti gli inserimenti dati vengono modellati come scritture (senza aggiornamenti o eliminazioni). In questo caso, ogni scrittura in Azure Cosmos DB è un "evento", per cui nel feed di modifiche sono registrati tutti gli eventi passati. Gli eventi pubblicati dall'archivio eventi centrale vengono solitamente usati per la gestione delle viste materializzate o per l'integrazione con sistemi esterni. Poiché non esiste alcun limite di tempo per la conservazione nella modalità versione più recente del feed di modifiche, è possibile riprodurre tutti gli eventi passati leggendo dall'inizio il feed di modifiche del contenitore Azure Cosmos DB. È possibile che più consumer eseguano una sottoscrizione allo stesso feed di modifiche del contenitore.

Azure Cosmos DB è un ottimo archivio dati centrale persistente di solo accodamento nello schema di origine eventi grazie ai vantaggi della scalabilità orizzontale e della disponibilità elevata. Inoltre, il processore dei feed di modifiche garantisce "almeno un'elaborazione", assicurando l'elaborazione di tutti gli eventi.

Limitazioni correnti

Il feed di modifiche dispone di più modalità, ciascuna delle quali presenta limitazioni importanti che è necessario conoscere. Esistono diverse aree da prendere in considerazione quando si progetta un'applicazione che usa il feed di modifiche in modalità versione più recente o in modalità Tutte le versioni e le eliminazioni.

Aggiornamenti intermedi

Nella modalità versione più recente, solo la modifica più recente di un determinato elemento viene inclusa nel feed di modifiche. Quando si elaborano le modifiche, viene letta la versione più recente dell'elemento disponibile. Se sono presenti più aggiornamenti dello stesso elemento in un breve periodo di tempo, è possibile che gli aggiornamenti intermedi non vengano elaborati. Se si desidera riprodurre gli aggiornamenti precedenti ad un elemento, è possibile modellare questi aggiornamenti come una serie di scritture oppure utilizzare la modalità Tutte le versioni e le eliminazioni.

Eliminazioni

La modalità versione più recente del feed di modifiche non acquisisce le eliminazioni. Se si elimina un elemento dal contenitore, l'elemento viene rimosso anche dal feed di modifiche. Per gestire queste eliminazioni viene in genere aggiunto un indicatore negli elementi che vengono eliminati. È possibile aggiungere una proprietà denominatadeleted e impostarla su true al momento dell'eliminazione. Questo aggiornamento del documento verrà visualizzato nel feed di modifiche. È possibile impostare un valore Durata (TTL) nell'elemento in modo che possa essere eliminato automaticamente in un secondo momento.

Conservazione

Il feed di modifiche nella modalità versione più recente ha una conservazione illimitata. Finché un elemento esiste nel contenitore, è disponibile nel feed di modifiche.

Ordine garantito

Tutte le modalità di feed di modifiche hanno un ordine garantito nel valore della chiave di partizione ma non tra i valori della chiave di partizione. È necessario selezionare una chiave di partizione che offra una garanzia di ordine significativa.

Si consideri, ad esempio, un'applicazione per la vendita al dettaglio che usa lo schema progettuale di origine degli eventi. In questa applicazione, diverse azioni utente sono "eventi" che vengono modellati come scritture in Azure Cosmos DB. Si supponga che alcuni eventi di esempio si siano verificati nella sequenza seguente:

  1. Il cliente aggiunge l'elemento A al carrello acquisti.
  2. Il cliente aggiunge l'elemento B al carrello acquisti.
  3. Il cliente rimuove l'elemento A dal carrello acquisti.
  4. Il cliente esegue il checkout e il contenuto del carrello acquisti viene spedito.

Viene conservata una vista materializzata del contenuto corrente del carrello acquisti per ogni cliente. L'applicazione deve garantire che gli eventi vengano elaborati nell'ordine in cui si verificano. Ad esempio, se il checkout del carrello foste stato elaborato prima della rimozione dell'elemento A, probabilmente il cliente avrebbe ricevuto l'elemento A anziché l'elemento B desiderato. Per assicurarsi che questi quattro eventi vengano elaborati nell'ordine in cui si sono verificati, è necessario che rientrino nello stesso valore della chiave di partizione. Se si seleziona il username (ogni cliente ha un nome utente univoco) come chiave di partizione, è possibile assicurarsi che questi eventi vengano visualizzati nel feed di modifiche nello stesso ordine in cui vengono scritti in Azure Cosmos DB.

Esempi

Di seguito sono riportati alcuni esempi di codici di feed di modifiche reali per la modalità della versione più recente che vanno oltre l'ambito degli esempi forniti:

Contenuto correlato