Questo articolo è stato scritto da Andrew Morgan di MongoDB. di Andrew Morgan di Andrew Morgan Di tanto in tanto, corrono a per un'applicazione che viene migrato da un database relazionale a MongoDB, dove il cliente condivide un diagramma architettonico che mostra un livello di cache (tipicamente Redis) seduto tra il server dell'app e MongoDB. Design Revisione Design Revisione Mi piace mantenere l'architettura il più semplice possibile - dopo tutto, ogni livello porta la sua propria complessità e costi di gestione - quindi chiederò perché lo strato di cache è lì. Non ho ancora finito una recensione del design senza raccomandare che il livello di cache venga rimosso. Quindi per rispondere alla domanda nel titolo di questo articolo - quando dovresti usare una cache con MongoDB? - la risposta è probabilmente mai. Questo articolo cerca di spiegare perché, ma se arrivi alla fine e pensi ancora che la tua applicazione ne abbia bisogno, allora vorrei discutere con te della tua applicazione. Perché sono state inventate cache come Memcached & Redis, e perché prosperano? I livelli di cache sono stati introdotti perché era troppo lento per le applicazioni per leggere i dati richiesti direttamente da un database relazionale. Ciò significa che non ci sono sviluppatori intelligenti che lavorano su Oracle, DB2, Postgres, MySQL, ecc.?Perché questi sviluppatori non potevano fare i database relazionali velocemente?La risposta è che tutti quei database sono stati scritti da grandi sviluppatori che includevano indici, cache di database interne e altre funzionalità per rendere la lettura di un record il più veloce possibile. Il problema è che l'applicazione raramente ha bisogno di leggere solo un singolo record dal database relazionale normalizzato. Invece, di solito ha bisogno di eseguire più connessioni su molte tabelle per formare un unico oggetto aziendale. Questi connessioni sono costosi (sono lenti e consumano molte risorse). Per questo motivo, l'applicazione non vuole incorrere in quel costo ogni volta che legge lo stesso oggetto aziendale. Questo è dove il livello di caching aggiunge valore - unisce i dati normalizzati, relazionali una volta e poi cache i risultati in modo che l'applicazione possa ottenere efficacemente gli stessi risultati molte volte. C'è anche il problema della distribuzione dei dati. La maggior parte dei database relazionali sono stati progettati 50 anni fa quando un'impresa avrebbe eseguito il database e qualsiasi applicazione in un unico data center. Avanti veloci a oggi, quando le imprese e i clienti sono distribuiti in tutto il mondo, con tutti che vogliono lavorare con gli stessi dati. Non si desidera che i server delle applicazioni distribuiti a livello globale subiscano la latenza e il costo di recuperare continuamente gli stessi dati da un database situato su un continente diverso. si desidera una copia dei dati situati localmente vicino a ogni server di applicazioni che ne ha bisogno. I database relazionali non sono stati progettati tenendo conto di questo requisito di distribuzione dei dati. i fornitori di RDBMS hanno cercato di boltare su varie soluzioni per lavorare intorno a questo, ma sono ben lungi dall'ottimizzare. Si noti che Redis e Memcached sono ampiamente utilizzati per la gestione delle sessioni per le applicazioni web dove la persistenza non è un requisito. In questo caso, la cache è l'unico magazzino di dati (cioè, non un livello di cache tra l'applicazione e MongoDB). Quindi, cosa c’è di sbagliato nel avere un caching tier? L'introduzione di un livello di cache è spesso una grande soluzione quando il database non può fornire le prestazioni e la latenza di cui ha bisogno l'applicazione. Tuttavia, questo livello di dati aggiuntivo comporta costi.Le ovvie sono le licenze software e hardware necessarie per fornire il servizio di cache. Meno ovvio è il carico aggiuntivo sugli sviluppatori. È un nuovo linguaggio di query (e possibilmente di programmazione) da padroneggiare. Cosa succede quando i dati nel RDBMS cambiano? Quindi, un livello di cache deve pagare la sua strada fornendo benefici tangibili sul fatto che la tua applicazione abbia accesso direttamente al database. Qual è la differenza con MongoDB? Il . MongoDB document model Modello di documento MongoDB In MongoDB, vogliamo che archiviate i vostri dati strutturati in modo da renderli efficienti nel soddisfare rapidamente le query più frequenti della vostra applicazione (o quelle con i più rigorosi SLA). MongoDB riflette la struttura degli oggetti consentendo a un singolo record (documento) di contenere oggetti incorporati (nestati). In molti casi, l'oggetto aziendale richiesto dall'applicazione sarà mappato in un unico documento MongoDB. In altri casi, potrebbe richiedere più documenti che possono essere raccolti con una singola ricerca indicizzata. MongoDB ha la sua propria LRU interna (più recentemente utilizzata) cache, quindi se il tuo documento è stato acceduto di recente, le probabilità sono che sia già in memoria. Il MongoDB supporta , ma cerchiamo di strutturare i tuoi dati per ridurre al minimo il loro utilizzo. Unione Unione L'altro valore aggiunto da un livello di cache è la localizzazione dei dati nelle architetture distribuite. ha un singolo nodo primario che gestisce tutti gli scritti, insieme ad un massimo di 49 nodi secondari, ciascuno con una copia dei dati. Per le query a latenza più bassa, è possibile posizionare i nodi secondari localmente in ciascuna delle posizioni del server dell'app. MongoDB è responsabile del mantenimento dei dati nei nodi secondari aggiornati con il nodo primario, quindi non è necessario scrivere e mantenere alcun codice di sincronizzazione aggiuntivo. Set di replica MongoDB Set di replica MongoDB Che cosa pensa AI? Le risposte create da AI generativa sono guidate dalle informazioni che sono state pubblicate da persone reali, e quindi dovrebbero rappresentare l'opinione popolare su un argomento. Ho chiesto a ChatGPT 4o questa domanda: “Spiegate perché avrei usato un livello di cache (come Redis) piuttosto che avere la mia applicazione a leggere i dati direttamente da MongoDB.” Redis funziona interamente in memoria, rendendolo significativamente più veloce di MongoDB, che si basa su disco I/O per il recupero dei dati. “Spiegate perché avrei usato un livello di cache (come Redis) piuttosto che avere la mia applicazione a leggere i dati direttamente da MongoDB.” Redis funziona interamente in memoria, rendendolo significativamente più veloce di MongoDB, che si basa su disco I/O per il recupero dei dati. Come descritto in precedenza, MongoDB ha la propria cache in-memory, quindi i documenti che si accede frequentemente saranno nella memoria, e nessun accesso al disco è richiesto. L’accesso frequente a MongoDB direttamente per gli stessi dati aumenta il carico di query, il che può rallentare il database, specialmente in condizioni di traffico di lettura pesante. L’accesso frequente a MongoDB direttamente per gli stessi dati aumenta il carico di query, il che può rallentare il database, specialmente in condizioni di traffico di lettura pesante. MongoDB è scalabile. I nodi secondari aggiuntivi possono essere aggiunti al set di replica per aggiungere larghezza di banda di query aggiuntiva. (Partitioning) può scalare la capacità dei dati o scrivere il throughput orizzontalmente. MongoDB sharding Sharding di MongoDB Le applicazioni con un elevato rapporto lettura-scrittura (ad esempio, applicazioni web, API) beneficiano della capacità di Redis di servire rapidamente i dati in cache. Le applicazioni con un elevato rapporto lettura-scrittura (ad esempio, applicazioni web, API) beneficiano della capacità di Redis di servire rapidamente i dati in cache. La cache di database di MongoDB offre gli stessi vantaggi senza lo sforzo aggiuntivo dello sviluppatore per sincronizzare le modifiche dei dati. “Accesso più rapido ai dati frequentemente usati. Redis è ideale per la cache di dati frequentemente accessibili o caldi (ad esempio, sessioni utente, configurazioni o dettagli del prodotto).” “Accesso più rapido ai dati frequentemente usati. Redis è ideale per la cache di dati frequentemente accessibili o caldi (ad esempio, sessioni utente, configurazioni o dettagli del prodotto).” Con frequente accesso, i dati caldi saranno conservati nella cache di database in-memory di MongoDB. “Lower Latency for Geo-Distributed Applications. By replicating Redis caches closer to end-users, you can avoid high network latency when querying MongoDB from distant locations.” “Lower Latency for Geo-Distributed Applications. By replicating Redis caches closer to end-users, you can avoid high network latency when querying MongoDB from distant locations.” La localizzazione dei dati può essere risolta posizionando le replicate vicino ai siti del server delle app. “Support for Expiring Data (TTL). Redis ha una funzione Time-to-Live (TTL) incorporata che rimuove automaticamente i dati in cache dopo una durata specificata.” “Support for Expiring Data (TTL). Redis ha una funzione Time-to-Live (TTL) incorporata che rimuove automaticamente i dati in cache dopo una durata specificata.” MongoDB utilizza una cache LRU, quindi tutti i documenti che non sono più richiesti verranno rimossi dalla memoria se lo spazio è necessario per i dati più recentemente richiesti. se si desidera rimuovere completamente i documenti dal database o Se volete trasferirli in un magazzino più economico. Indice di TTL Atlas Online Archive Indice di TTL Archivi Atlas Online La lettura da MongoDB ripetutamente può essere ricca di risorse, specialmente con query complesse, che portano ad un aumento dei costi di infrastruttura. La lettura da MongoDB ripetutamente può essere ricca di risorse, specialmente con query complesse, che portano ad un aumento dei costi di infrastruttura. Il tuo schema MongoDB dovrebbe essere progettato in modo che le tue query importanti non richiedano query complesse. "Use Cases for Specialized Data Structures. Redis supporta strutture avanzate di dati come liste, set, set ordinati, hash e flussi, che MongoDB non fornisce in modo nativo." "Use Cases for Specialized Data Structures. Redis supporta strutture avanzate di dati come liste, set, set ordinati, hash e flussi, che MongoDB non fornisce in modo nativo." MongoDB supporta elenchi e set. I hash possono essere rappresentati in MongoDB come una serie di documenti contenenti coppie di valori chiave (la e) il soddisfare le stesse esigenze dei flussi Redis. Modello di attribuzione MongoDB Collezioni di serie temporali MongoDB Modello di attribuzione MongoDB Collezioni di serie temporali MongoDB Un livello di cache può servire come fallback se MongoDB è temporaneamente indisponibile o sotto un carico pesante. Un livello di cache può servire come fallback se MongoDB è temporaneamente indisponibile o sotto un carico pesante. MongoDB può scalare verticalmente o orizzontalmente per soddisfare qualsiasi richiesta di carico. I set di replica MongoDB forniscono una tolleranza di errore sia per le letture che per le scritture. La scalabilità può essere automatizzata quando si utilizza MongoDB Atlas La scalabilità può essere automatizzata quando si utilizza MongoDB Atlas MongoDB può richiedere del tempo per calcolare query complesse (ad esempio, aggregazioni, connessioni) per i risultati spesso richiesti. MongoDB può richiedere del tempo per calcolare query complesse (ad esempio, aggregazioni, connessioni) per i risultati spesso richiesti. Il tuo schema MongoDB dovrebbe essere progettato per evitare la necessità di eseguire frequentemente query complesse. , evitando la necessità di eseguire ripetutamente la stessa query / aggregazione complessa. MongoDB materialized view Vista materializzata di MongoDB Se modifico il mio invito a “Spiegare perché non dovrei usare uno strato di cache (come Redis) piuttosto che avere la mia applicazione a leggere i dati da MongoDB direttamente”, ChatGPT è felice di dissuadermi dall’aggiungere lo strato di cache, citando questioni come l’aumento della complessità del sistema, problemi di coerenza dei dati, prestazioni per carichi di lavoro pesanti di scrittura, costo, flessibilità delle query, manutenzione e affidabilità, piccoli set di dati (dove il set di dati attivi si inserisce nella cache di MongoDB) e report in tempo reale. riassunto Un livello di cache può aggiungere molto valore quando il tuo RDBMS non può fornire le prestazioni di query richieste dall'applicazione. Quando si utilizza MongoDB, il database di funzionalità di record e cache viene combinato in un unico livello, risparmiando tempo e denaro per gli sviluppatori. Una cache distribuita può mitigare le carenze nel tuo RDBMS, ma MongoDB ha una distribuzione integrata. Rispondi a questo articolo se credi ancora che la tua applicazione trarrà beneficio da un livello di cache tra la tua applicazione e MongoDB. Scopri di più sulle recensioni di design di MongoDB sono un'opportunità per un esperto di progettazione da MongoDB per consigliarti su come usare al meglio MongoDB per la tua applicazione. Le recensioni sono focalizzate su come farti avere successo usando MongoDB. Non è mai troppo presto per richiedere una recensione. Design recensioni Design recensioni Questo articolo ha spiegato come progettare uno schema MongoDB che corrisponda al modo in cui la tua applicazione funziona con i dati può soddisfare i tuoi requisiti di prestazione senza bisogno di un livello di cache. La tua domanda trarrebbe beneficio da una revisione? . Schedule your design review Programma la tua revisione del design
