Condividi tramite

Modelli di progettazione dei feed di modifiche in Azure Cosmos DB per NoSQL

Il feed di modifiche di Azure Cosmos DB consente di elaborare in modo efficiente set di dati di grandi dimensioni con volumi di scrittura elevati. Offre un'alternativa all'esecuzione di query su interi set di dati per identificare le modifiche. Questo articolo illustra i modelli di progettazione comuni dei feed di modifiche, i relativi compromessi e le limitazioni per creare soluzioni scalabili.

Scenari

Azure Cosmos DB è ideale per applicazioni IoT, di gioco, di vendita al dettaglio e di registrazione operativa. Uno schema progettuale comune in queste applicazioni prevede l'uso di modifiche ai dati per attivare azioni aggiuntive. Tali azioni includono:

  • Attivazione di una notifica o di una chiamata a un'API quando viene inserito, aggiornato o eliminato un elemento.
  • Elaborazione dei flussi in tempo reale per IoT o analisi 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 questi modelli, come illustrato nell'immagine seguente:

Diagramma che illustra come il feed di modifiche di Azure Cosmos DB alimenta gli scenari di analisi in tempo reale e di elaborazione basata su eventi.

Elaborazione degli eventi e notifiche

Il feed di modifiche di Azure Cosmos DB semplifica gli scenari che attivano una notifica o chiamano un'API in base a un evento specifico. Usare il processore del feed di modifiche per eseguire automaticamente il polling del contenitore per le modifiche e chiamare un'API esterna per ogni scrittura, aggiornamento o eliminazione.

Attivare in modo selettivo una notifica o chiamare un'API in base a criteri specifici. Ad esempio, se si legge dal feed di modifiche usando Funzioni di Azure, aggiungere logica alla funzione per inviare una notifica solo se viene soddisfatta una condizione. Anche se il codice della funzione di Azure viene 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 consente di eseguire l'elaborazione dei flussi in tempo reale per IoT o analisi in tempo reale sui dati operativi. Ad esempio, si ricevono e archiviano i dati degli eventi da dispositivi, sensori, infrastruttura e applicazioni ed elabora questi eventi in tempo reale usando Spark. L'immagine seguente illustra come implementare un'architettura lambda usando il feed di modifiche di Azure Cosmos DB:

Diagramma che mostra una pipeline lambda basate su Azure Cosmos DB per l'inserimento e le 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.

Salvataggio permanente dei dati

I dati scritti in Azure Cosmos DB vengono visualizzati nel feed di modifiche. Nella modalità versione più recente, i dati rimangono nel feed di modifiche fino all'eliminazione. Le code di messaggi hanno in genere 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 Di Azure Cosmos DB, eseguire query SQL sui 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 fino a 99,999% disponibilità di lettura e scrittura. A differenza di molte code di messaggi, i dati di Azure Cosmos DB possono essere distribuiti a livello globale e configurati con un obiettivo di tempo di ripristino (RTO) pari 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. Ad esempio, usare il feed di modifiche di Azure Cosmos DB per implementare classifiche in tempo reale in base ai punteggi delle partite completate.

Spostamento dati

Leggere dal feed di modifiche per lo spostamento dei 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, archiviare i "dati ad accesso frequente" in Azure Cosmos DB ed escludere "dati ad accesso sporadico" ad altri sistemi di archiviazione come 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 garantisce 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

Il modello di origine eventi usa un archivio di sola accodamento per registrare la serie completa di azioni sui 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 eccellente archivio dati permanente di sola accodamento centrale nel modello di origine eventi grazie ai punti di forza 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 utilizza il feed delle 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. Per riprodurre singoli aggiornamenti a un elemento, modellare questi aggiornamenti come una serie di scritture o usare tutte le versioni e la modalità di eliminazione.

Eliminazioni

La modalità versione più recente del feed di modifiche non acquisisce le eliminazioni. Quando si elimina un elemento dal contenitore, l'elemento viene rimosso dal feed di modifiche. Il metodo più comune per gestire le operazioni di eliminazione consiste nell'aggiungere un marcatore software agli elementi 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 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 la transazione del carrello doveva essere elaborata prima della rimozione dell'elemento A, è probabile che l'articolo A sia stato spedito al cliente invece dell'elemento B che il cliente voleva. Per assicurarsi che questi quattro eventi vengano elaborati in ordine, devono rientrare 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 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

  • Last updated on