I database moderni devono avere la capacità di acquisire e reagire ai dati mentre fluiscono in tempo reale. Questo spiega perché MongoDB ha una funzione chiamata MongoDB Change Streams responsabile dell'acquisizione e della risposta ai dati in tempo reale. Change Streams è una funzionalità introdotta per lo streaming di informazioni dall'applicazione al database in tempo reale. Si basa su un framework di aggregazione che monitora le raccolte e consente il verificarsi di modifiche nel database e nella raccolta di database. Inoltre, MongoDB Change Stream può acquisire dati dai sensori IOT e aggiornare report come le modifiche ai dati operativi in un'azienda. Questo blog aprirà il discorso su MongoDB Change Stream e modificherà i consigli in produzione.
MongoDB Change Streams e Dropping Collection
La ridenominazione o l'eliminazione di un database o di una raccolta comporterà la chiusura del cursore se è presente un flusso di modifiche aperto che lavora sulla raccolta eliminata. La ridenominazione o l'eliminazione di una raccolta fa sì che il cursore con FullDocument:updateLookup restituisca null su un determinato documento di ricerca. Si verifica un errore se si tenta di riprendere dopo aver eliminato un database con un flusso di modifiche in esecuzione.
Inoltre, tutte le modifiche ai dati apportate prima di rinominare una raccolta con un flusso di modifiche in esecuzione vengono perse. Il limite di documenti per il flusso di modifiche è ancora 16 MB BSON; pertanto non sono accettati documenti di dimensioni superiori a 16 MB. Se si tenta di lavorare con un documento di dimensioni superiori a 16 MB, la notifica non riesce e il documento viene sostituito con un altro documento che soddisfa il limite impostato.
Quando una raccolta o un database con flussi di modifiche aperti su di esso viene eliminata o rinominata, i cursori del flusso di modifiche tendono a chiudersi man mano che avanzano a quel punto nell'oplog. Se modifichi i cursori di flusso con il documento completo, l'opzione updateLookup potrebbe restituire null al documento di ricerca.
Pertanto, un tentativo di riprendere i flussi di modifiche rispetto a una raccolta che è stata eliminata risulterà in un errore. Qualsiasi occorrenza di modifiche ai dati nella raccolta tra l'ultimo evento del flusso di modifiche acquisito e l'evento di rilascio della raccolta viene persa.
La modifica dei documenti di risposta dello stream deve rispettare il limite di 16 MB di documenti BSON. A seconda delle dimensioni dei documenti nella raccolta rispetto ai quali si sta aprendo il flusso di modifiche, le notifiche potrebbero non riuscire se il documento di notifica risultante supera i 16 MB. Un buon esempio sono le operazioni di aggiornamento sui flussi di modifiche impostate per restituire un documento completamente aggiornato o sostituire/inserire processi con il documento al limite o leggermente al di sotto del limite.
Set di repliche e flusso di modifiche MongoDB
Un set di repliche MongoDB è una raccolta di processi in MongoDB il cui set di dati non cambia; cioè, il set di dati rimane lo stesso. Nel caso di set di repliche con membri arbitro, è probabile che i flussi di modifiche rimangano inattivi se non sono disponibili membri sufficienti con i dati in modo che la maggioranza non possa eseguire le operazioni. Ad esempio, possiamo considerare un set di repliche con tre membri con due nodi contenenti dati insieme a un arbitro. Nel caso in cui il secondario sia inattivo, ad esempio a causa di un errore o di un aggiornamento o di una manutenzione, sarà impossibile che le operazioni di scrittura vengano commesse a maggioranza. Il flusso di modifiche rimarrà aperto ma non invierà notifiche. Nello scenario in questione, l'applicazione potrebbe recuperare il ritardo con tutte le operazioni che hanno avuto luogo nel periodo di inattività, purché l'ultima operazione ricevuta dall'applicazione sia ancora nell'oplog di quel particolare set di repliche. Inoltre, il comando rs.printReplicationInfo() viene utilizzato per recuperare i dati da oplog; i dati recuperati includono una gamma di operazioni e dimensioni di oplog.
Se il tempo di inattività è stimato in modo significativo, ad esempio per eseguire un aggiornamento o in caso di disastro, aumentare la dimensione dell'oplog sarà l'opzione migliore per mantenere le operazioni per un periodo maggiore di il tempo di fermo approssimativo. Per recuperare le informazioni sullo stato dell'oplog, il comando utilizzato è printReplicationInfo(). Il comando recupererà non solo le informazioni sullo stato dell'oplog, ma anche la dimensione dell'oplog e l'intervallo di tempo delle operazioni.
MongoDB Modifica la disponibilità dei flussi
È possibile ottenere flussi di modifiche MongoDB per set di repliche e cluster partizionati:Read Concern Abilitazione "maggioranza", Motore di archiviazione e Versione protocollo set di repliche. Abilitazione della "maggioranza" di lettura:a partire da MongoDB versione 4.2 e successive, i flussi di modifiche sono accessibili nonostante le circostanze prevalenti del supporto della preoccupazione di lettura "maggioranza", il che significa che il supporto della maggioranza di preoccupazione di lettura può essere abilitato o disabilitato. In MongoDB versione 4.0 e versioni precedenti, i flussi di modifiche sono disponibili solo se il supporto per problemi di lettura "maggioranza" è attivato.
- Motore di archiviazione:il motore di archiviazione WiredTiger è il tipo di motore di archiviazione utilizzato dai set di repliche e dai cluster partizionati.
- Versione del protocollo del set di repliche:i set di repliche e i cluster partizionati devono sempre utilizzare la versione 1 del protocollo del set di repliche (pv1).
Cluster partizionati MongoDB
I cluster frammentati in MongoDB sono costituiti da frammenti, mongo e server di configurazione. Uno shard è costituito da un sottoinsieme di dati partizionati. Nel caso di MongoDB 3.6, gli shard vengono utilizzati come set di repliche. Mongos fornisce un'interfaccia tra i cluster partizionati e le applicazioni client; mongos svolge il ruolo di un router di query. Da MongoDB versione 4.4 e successive, mongos supporta letture coperte per ridurre le latenze. I server di configurazione sono le posizioni di archiviazione per le impostazioni di configurazione del cluster e i metadati.
I flussi di modifiche utilizzano un orologio logico globale per fornire un ordinamento globale delle modifiche tra gli shard. MongoDB garantisce che l'ordine delle modifiche venga mantenuto e che le notifiche del flusso di modifiche possano essere interpretate in modo sicuro nell'ordine in cui sono state ricevute. Ad esempio, il cursore del flusso di modifiche aperto su un cluster di 3 shard restituisce le notifiche di modifica relative all'ordine totale delle modifiche nei tre shard.
Per garantire l'ordine totale delle modifiche, Mongos controlla con ogni shard per vedere se ha visto modifiche più recenti per ogni notifica di modifica. È probabile che i cluster frammentati con uno o più frammenti con poca o nessuna attività di raccolta o "freddi" abbiano effetti negativi sul tempo di risposta del flusso di modifiche poiché i mongo devono ancora verificare con quei frammenti freddi per garantire l'ordine totale delle modifiche. Questo effetto può essere più evidente quando gli shard sono distribuiti geograficamente o quando i carichi di lavoro con la maggior parte delle operazioni si verificano su un sottoinsieme di shard in un cluster. Se la raccolta frammentata ha un alto livello di attività, i mongo potrebbero non riuscire a tenere traccia delle modifiche in tutti i frammenti. Prendi in considerazione l'utilizzo di filtri di notifica per questo tipo di raccolta, ad esempio passando la pipeline $match, che è configurata per filtrare solo le operazioni di inserimento.
Nel caso di raccolte partizionate, è probabile che le operazioni di aggiornamento multi:corrette causino flussi di modifiche aperti sulla raccolta per inviare notifiche per documenti orfani. A partire dal momento in cui una raccolta non partizionata viene partizionata fino al momento in cui il flusso di modifiche arriva al primo blocco di migrazione, documentKey nel documento di notifica del flusso di modifiche include solo l'ID del documento e non la chiave shard completa.
Conclusione
Lo scopo dei flussi di modifiche è rendere possibile la modifica dei dati dell'applicazione in tempo reale, senza il rischio di stalking dell'oplog e senza alcuna traccia di complessità. Le applicazioni MongoDB utilizzano i flussi di modifiche per firmare le modifiche ai dati su un database, una raccolta o la distribuzione e reagire immediatamente. Poiché i flussi di modifiche utilizzano il framework di aggregazione, le applicazioni possono filtrare le modifiche specifiche e convertire le notifiche da sole.
