Aquest article va ser escrit per Andrew Morgan de MongoDB. Àngels Morgan Àngels Morgan De tant en tant, corro una per a una aplicació que es migri d'una base de dades relacional a MongoDB, on el client comparteix un diagrama arquitectònic que mostra una capa de memòria cau (normalment Redis) assegut entre el servidor de l'aplicació i MongoDB. Revisió de disseny Revisió de disseny M'agrada mantenir l'arquitectura tan simple com sigui possible - després de tot, cada capa porta la seva pròpia complexitat i costos de gestió - així que em pregunto per què hi ha la capa de memòria cau. Encara no he acabat una revisió de disseny sense recomanar que es retiri la capa de memòria cau. Així que per respondre a la pregunta en el títol d'aquest article - quan hauria d'utilitzar una memòria cau amb MongoDB? - la resposta és probablement mai. Aquest article intenta explicar per què, però si s'arriba al final i encara creu que la seva aplicació la necessita, llavors m'agradaria discutir la seva aplicació amb vostè. Per què es van inventar les memes com Memcached & Redis, i per què prosperen? Els nivells de memòria cau es van introduir perquè era massa lent per a les aplicacions per llegir les dades requerides directament d'una base de dades relacional. Això vol dir que no hi ha desenvolupadors intel·ligents que treballen en Oracle, DB2, Postgres, MySQL, etc.? Per què aquests desenvolupadors no van poder fer les bases de dades relacionals ràpidament?La resposta és que totes aquestes bases de dades van ser escrites per grans desenvolupadors que van incloure índexs, caches de bases de dades internes i altres característiques per fer llegir un registre tan ràpid com sigui possible. El problema és que l'aplicació rarament necessita llegir només un únic registre de la base de dades relacional normalitzada. En canvi, normalment necessita realitzar múltiples conjugacions a través de moltes taules per formar un sol objecte de negoci. Aquestes conjugacions són costoses (són lentes i consumeixen molts recursos). Per aquest motiu, l'aplicació no vol incórrer en aquest cost cada vegada que llegeix el mateix objecte de negoci. És aquí on la capa de memòria cau afegeix valor - uneix les dades normalitzades, relacionals una vegada i després cache els resultats perquè l'aplicació pugui obtenir els mateixos resultats de manera eficient moltes vegades. També hi ha el problema de la distribució de dades. La majoria de les bases de dades relacionals van ser dissenyades fa 50 anys quan una empresa executaria la base de dades i qualsevol aplicació en un sol centre de dades. Avançar ràpidament fins avui, quan les empreses i els clients estan distribuïts arreu del món, amb tothom que vol treballar amb les mateixes dades. No voleu que els servidors d'aplicacions distribuïts globalment pateixin la latència i el cost de recollir contínuament les mateixes dades d'una base de dades ubicada en un continent diferent. Voleu una còpia de les dades ubicades localment a prop de cada servidor d'aplicacions que ho necessiti. Les bases de dades relacionals no es van dissenyar tenint en compte aquest requisit de distribució de dades. els proveïdors de RDBMS han intentat fer servir diverses solucions per treballar al voltant d'això, però estan lluny d'optimitzar-se. Tingueu en compte que Redis i Memcached s'utilitzen àmpliament per al maneig de sessions per a aplicacions web on la persistència no és un requisit. En aquest cas, la memòria cau és l'únic emmagatzematge de dades (és a dir, no una capa de memòria entre l'aplicació i MongoDB). Què hi ha de dolent en tenir un caixer? La introducció d'una capa de memòria cau sovint és una gran solució quan la base de dades no pot proporcionar el rendiment i la latencia que necessita l'aplicació. Les òbvies són les llicències de programari i el maquinari necessaris per proporcionar el servei de caché. És un nou llenguatge de consulta (i possiblement llenguatge de programació) per dominar. Què passa quan les dades en el RDBMS canvien? Per tant, un nivell de memòria cau ha de pagar el seu camí aportant beneficis tangibles sobre tenir la seva aplicació accés a la base de dades directament. Què és diferent amb MongoDB? El . MongoDB document model Model de document MongoDB En MongoDB, volem que emmagatzemeu les vostres dades estructurades d'una manera que faci que sigui eficient per satisfer ràpidament les consultes més freqüents de la vostra aplicació (o aquelles amb els SLAs més durs). MongoDB reflecteix l'estructura d'objectes permetent que un sol registre (document) contingui objectes incrustats. En molts casos, l'objecte de negoci requerit per l'aplicació es maparà a un sol document MongoDB. En altres casos, pot requerir diversos documents que es poden recollir amb una única cerca indexada. MongoDB té la seva pròpia LRU interna (més recentment utilitzada) cache, de manera que si el seu document ha estat accedit recentment, les possibilitats són que ja estigui en la memòria. Observeu que MongoDB és compatible amb , però intentem estructurar les seves dades per minimitzar-ne l’ús. Juntes Juntes L'altre valor afegit d'una capa de memòria cau és la localització de dades en les arquitectures distribuïdes. té un sol node primari que gestiona tots els escrits, juntament amb fins a 49 nodes secundaris, cadascun amb una còpia de les dades. Per a les consultes de latència més baixa, podeu col·locar secundaris localment a cadascuna de les ubicacions del servidor de l'aplicació. MongoDB és responsable de mantenir les dades en els nodes secundaris actualitzades amb els primaris, de manera que no cal escriure i mantenir cap codi de sincronització addicional. MongoDB replica MongoDB replica Què pensa AI? Les respostes creades per la IA generativa estan impulsades per la informació que ha estat publicada per persones reals, i per tant hauria de representar l'opinió popular sobre un tema. Vaig fer a ChatGPT 4o aquesta pregunta: "Expliqui per què utilitzaria una capa de memòria cau (com Redis) en comptes de fer que la meva aplicació llegeixi dades directament de MongoDB." Redis funciona íntegrament en memòria, fent-lo significativament més ràpid que MongoDB, que es basa en I/O de disc per a la recuperació de dades. "Expliqui per què utilitzaria una capa de memòria cau (com Redis) en comptes de fer que la meva aplicació llegeixi dades directament de MongoDB." Redis funciona íntegrament en memòria, fent-lo significativament més ràpid que MongoDB, que es basa en I/O de disc per a la recuperació de dades. Com es va descriure anteriorment, MongoDB té la seva pròpia memòria cache, de manera que els documents als quals accedeix amb freqüència es troben en la memòria, i no es requereix accés al disc. L'accés freqüent a MongoDB directament per a les mateixes dades augmenta la càrrega de consultes, que pot retardar la base de dades, especialment sota un trànsit de lectura pesat. L'accés freqüent a MongoDB directament per a les mateixes dades augmenta la càrrega de consultes, que pot retardar la base de dades, especialment sota un trànsit de lectura pesat. MongoDB és escalable. Es poden afegir nodes secundaris addicionals al conjunt de replicació per afegir amplada de banda de consulta addicional. (particionament) pot escalar la capacitat de dades o escriure el rendiment horitzontalment. MongoDB amb Sharding MongoDB amb Sharding Les aplicacions amb altes ràtios de lectura-escriptura (per exemple, aplicacions web, APIs) es beneficien de la capacitat de Redis de servir dades en memòria cau ràpidament. Les aplicacions amb altes ràtios de lectura-escriptura (per exemple, aplicacions web, APIs) es beneficien de la capacitat de Redis de servir dades en memòria cau ràpidament. La memòria cau de la base de dades de MongoDB proporciona els mateixos beneficis sense l'esforç extra del desenvolupador per sincronitzar els canvis de dades. Redis és ideal per a la memòria cau de dades freqüentment accessibles o calentes (per exemple, sessions d'usuari, configuracions o detalls del producte). Redis és ideal per a la memòria cau de dades freqüentment accessibles o calentes (per exemple, sessions d'usuari, configuracions o detalls del producte). Les dades freqüentment accessibles es mantindran en la memòria cache de la base de dades de MongoDB. Mitjançant la replicació de les caches de Redis més a prop dels usuaris finals, es pot evitar una alta latència de la xarxa quan es consulta MongoDB des d'ubicacions remotes. Mitjançant la replicació de les caches de Redis més a prop dels usuaris finals, es pot evitar una alta latència de la xarxa quan es consulta MongoDB des d'ubicacions remotes. La localització de dades es pot resoldre mitjançant la col·locació de rèpliques prop dels llocs del servidor d'aplicacions. Redis té una funció Time-to-Live (TTL) integrada que elimina automàticament les dades en memòria cau després d'una durada especificada. Redis té una funció Time-to-Live (TTL) integrada que elimina automàticament les dades en memòria cau després d'una durada especificada. MongoDB utilitza una memòria cau LRU, de manera que tots els documents que ja no estan sent consultats seran eliminats de la memòria si l'espai és necessari per a les dades més recentment consultades. si voleu eliminar els documents de la base de dades completament o Si voleu moure'ls a un emmagatzematge més barat. TTL indexes Atlas Online Archive Índex TTL Arxiu Atlas Online Llegir de MongoDB repetidament pot ser intens en recursos, especialment amb consultes complexes, que condueixen a un augment dels costos d'infraestructura. Llegir de MongoDB repetidament pot ser intens en recursos, especialment amb consultes complexes, que condueixen a un augment dels costos d'infraestructura. L'esquema MongoDB ha de ser dissenyat de manera que les seves consultes importants no requereixin consultes complexes. Redis és compatible amb estructures de dades avançades com ara llistes, conjunts, conjunts ordenats, hashes i fluxos, que MongoDB no proporciona de forma nativa. Redis és compatible amb estructures de dades avançades com ara llistes, conjunts, conjunts ordenats, hashes i fluxos, que MongoDB no proporciona de forma nativa. MongoDB dóna suport a llistes i conjunts. Els hashs es poden representar en MongoDB com un conjunt de documents que contenen parells de valors clau (el ) i Les necessitats són les mateixes que les de Redis Streams. MongoDB attribute pattern Col·leccions de sèrie de temps de MongoDB Patró d'atributs MongoDB Col·leccions de sèrie de temps de MongoDB Resiliència i tolerància a errors: una capa de memòria cau pot servir com a fallback si MongoDB està temporalment indisponible o sota una càrrega pesada. Resiliència i tolerància a errors: una capa de memòria cau pot servir com a fallback si MongoDB està temporalment indisponible o sota una càrrega pesada. MongoDB pot escalar verticalment o horitzontalment per satisfer qualsevol demanda de càrrega. Els conjunts de replicació de MongoDB proporcionen tolerància a errors tant per llegir com per escriure. Scaling can be automated when using MongoDB Atlas L'escala es pot automatitzar quan s'utilitza l'Atles de MongoDB MongoDB pot prendre temps per calcular consultes complexes (per exemple, agregacions, conjugacions) per obtenir resultats sol·licitats amb freqüència. MongoDB pot prendre temps per calcular consultes complexes (per exemple, agregacions, conjugacions) per obtenir resultats sol·licitats amb freqüència. El teu esquema MongoDB ha de ser dissenyat per evitar la necessitat d'executar consultes complexes amb freqüència. , evitant la necessitat d'executar repetidament la mateixa consulta / agregació complexa. MongoDB materialized view MongoDB vista materialitzada Si canvio la meva invitació a "Expliqui per què no hauria d'utilitzar una capa de memòria cau (com Redis) en comptes de fer que la meva aplicació llegeixi dades de MongoDB directament", ChatGPT està encantat de dissuadir-me d'afegir la capa de memòria cau, citant problemes com l'augment de la complexitat del sistema, problemes de consistència de dades, rendiment per a càrregues de treball pesades en escriure, cost, flexibilitat de consulta, manteniment i fiabilitat, petits conjunts de dades (on el conjunt de dades activa s'ajusta a la memòria cau de MongoDB), i reportatge en temps real. Resum Una capa de memòria cau pot afegir molt de valor quan el seu RDBMS no pot proporcionar el rendiment de la consulta que requereix la seva aplicació. Quan s'utilitza MongoDB, la base de dades de funcionalitats de registre i memòria cau es combina en una sola capa, estalviant diners i temps per als desenvolupadors. Una memòria cau distribuïda pot mitigar les deficiències en el seu RDBMS, però MongoDB té una distribució integrada. Respon a aquest article si encara creu que la seva aplicació es beneficiaria d'una capa de memòria cau entre la seva aplicació i MongoDB. Més informació sobre les revisions de disseny de MongoDB són una oportunitat per a un expert en disseny de MongoDB per assessorar-te sobre com utilitzar millor MongoDB per a la teva aplicació. Les crítiques estan enfocades a fer-te un èxit en l'ús de MongoDB. Mai és massa aviat per demanar una revisió. Revisió de disseny Revisió de disseny Aquest article va explicar com dissenyar un esquema MongoDB que coincideixi amb la forma en què la seva aplicació funciona amb les dades pot satisfer els requisits de rendiment sense necessitar una capa de memòria cau. La seva sol·licitud es beneficiaria d'una revisió? . Schedule your design review Planifica la teva revisió de disseny
