Denne artikel er skrevet af Andrew Morgan fra MongoDB.

Fra tid til anden løber jeg enDesign gennemgangfor en applikation, der migreres fra en relationel database til MongoDB, hvor kunden deler et arkitektonisk diagram, der viser et cachinglag (typisk Redis), der sidder mellem app-serveren og MongoDB.

Jeg kan godt lide at holde arkitekturen så enkel som muligt - trods alt bringer hvert lag sin egen kompleksitet og administrationsomkostninger - så jeg vil spørge, hvorfor cachinglaget er der.

Jeg har endnu ikke afsluttet en designanalyse uden at anbefale, at cache-niveauet fjernes.

Så for at besvare spørgsmålet i titlen på denne artikel - hvornår skal du bruge en cache med MongoDB? - svaret er sandsynligvis aldrig.

Hvorfor blev caches som Memcached & Redis opfundet, og hvorfor trives de?

Caching-niveauer blev indført, fordi det var for langsomt for applikationer at læse de krævede data direkte fra en relationel database.

Betyder det, at der ikke er smarte udviklere, der arbejder på Oracle, DB2, Postgres, MySQL osv.?Hvorfor kunne disse udviklere ikke lave relationelle databaser hurtigt?

Problemet er, at applikationen sjældent behøver at læse kun en enkelt rekord fra den normaliserede relationelle database. I stedet skal den typisk udføre flere joins på tværs af mange tabeller for at danne et enkelt forretningsobjekt. Disse joins er dyre (de er langsomme og forbruger mange ressourcer). Af denne grund ønsker applikationen ikke at pådrage sig den omkostning, hver gang de læser det samme forretningsobjekt. Det er her, caching-niveauet tilføjer værdi - tilslut de normaliserede, relationelle data en gang og derefter cache resultaterne, så applikationen effektivt kan hente de samme resultater mange gange.

Der er også problemet med datadistribution. De fleste relationelle databaser blev designet for 50 år siden, da en virksomhed ville køre databasen og eventuelle applikationer i et enkelt datacenter. Hurtigt frem til i dag, når virksomheder og kunder er spredt over hele verden, med alle, der ønsker at arbejde med de samme data. Du ønsker ikke, at globalt distribuerede app-servere skal lide forsinkelsen og omkostningerne ved kontinuerligt at hente de samme data fra en database beliggende på et andet kontinent.

RDBMS-leverandører har forsøgt at bolte på forskellige løsninger til at arbejde omkring dette, men de er langt fra optimale.

Bemærk, at Redis og Memcached er almindeligt anvendt til sessionshåndtering for webapplikationer, hvor vedholdenhed ikke er et krav. I dette tilfælde er cachen den eneste datalagring (dvs. ikke et cache lag mellem applikationen og MongoDB).

Så hvad er der galt med at have en caching tier?

Introduktion af et cachelag er ofte en god løsning, når databasen ikke kan levere den ydeevne og latency, som din applikation har brug for.

Men dette ekstra datalager kommer med omkostninger.De indlysende er de software-licenser og hardware, der kræves for at levere caching-tjenesten.

Mindre indlysende er den ekstra belastning på udviklerne. Det er et nyt forespørgselssprog (og muligvis programmeringssprog) at mestre. Hvad sker der, når dataene i RDBMS ændres?

Så et cache-niveau skal betale sig ved at levere håndgribelige fordele over at have din ansøgning adgang til databasen direkte.

Hvad er forskellen på MongoDB?

DenMongoDB dokumentmodel.

I MongoDB vil vi have dig til at gemme dine data struktureret på en måde, der gør det effektivt at hurtigt opfylde dine applikations hyppigste forespørgsler (eller dem med de hårdeste SLA'er). MongoDB afspejler strukturen af objekter ved at lade en enkelt rekord (dokument) indeholde indlejrede (nestede) objekter.

I mange tilfælde vil det forretningsobjekt, der kræves af applikationen, blive kortlagt til et enkelt MongoDB-dokument.

MongoDB har sin egen interne LRU (mindst nyligt brugt) cache, så hvis dit dokument har været tilgængeligt for nylig, er chancerne, at det allerede er i hukommelsen.

Bemærk, at MongoDB understøtterJoins, men vi forsøger at strukturere dine data for at minimere deres brug.

Den anden værdiforøgelse fra et cachinglag er datalokalitet i distribuerede arkitekturer. MongoDB har dette indbygget.MongoDB replika sæthar en enkelt primær knudepunkt, der håndterer alle skrivninger, sammen med op til 49 sekundære knudepunkter – hver med en kopi af dataene. For de laveste latensforespørgsler kan du placere sekundærer lokalt på hver af dine app-serverlokationer. MongoDB er ansvarlig for at holde dataene i de sekundære knudepunkter opdateret med den primære, så du ikke behøver at skrive og vedligeholde nogen ekstra synkroniseringskode.

Hvad tænker AI?

Svarene skabt af generativ AI er drevet af de oplysninger, der er blevet offentliggjort af rigtige mennesker, og så det skal repræsentere populær mening om et emne.

Jeg stillede ChatGPT 4o dette spørgsmål:

"Forklar, hvorfor jeg ville bruge et cache lag (såsom Redis) i stedet for at have min ansøgning læse data fra MongoDB direkte."

Redis fungerer udelukkende i hukommelsen, hvilket gør det betydeligt hurtigere end MongoDB, som er afhængig af disk I/O til dataindsamling.

"Forklar, hvorfor jeg ville bruge et cache lag (såsom Redis) i stedet for at have min ansøgning læse data fra MongoDB direkte."

Redis fungerer udelukkende i hukommelsen, hvilket gør det betydeligt hurtigere end MongoDB, som er afhængig af disk I/O til dataindsamling.

Som beskrevet ovenfor har MongoDB sin egen cache i hukommelsen, så de dokumenter, du ofte får adgang til, vil være i hukommelsen, og der kræves ingen diskadgang.

Hyppig adgang til MongoDB direkte til de samme data øger forespørgselsbelastningen, hvilket kan bremse databasen, især under tung læsningstrafik.

Hyppig adgang til MongoDB direkte til de samme data øger forespørgselsbelastningen, hvilket kan bremse databasen, især under tung læsningstrafik.

MongoDB er skalerbar. Ekstra sekundære noder kan tilføjes til replika-sættet for at tilføje ekstra forespørgselsbåndbredde.MongoDB sharding(partitionering) kan skalere data kapacitet eller skrive gennemstrømning horisontalt.

Applikationer med høje læse-til-skrive-forhold (f.eks. webapps, API'er) drager fordel af Redis' evne til hurtigt at servicere cachede data.

Applikationer med høje læse-til-skrive-forhold (f.eks. webapps, API'er) drager fordel af Redis' evne til hurtigt at servicere cachede data.

MongoDB's database cache giver de samme fordele uden den ekstra udviklerindsats for at synkronisere dataændringer.

Redis er ideel til caching af hyppigt tilgængelige eller varme data (f.eks. brugersessioner, konfigurationer eller produktoplysninger).

Redis er ideel til caching af hyppigt tilgængelige eller varme data (f.eks. brugersessioner, konfigurationer eller produktoplysninger).

Ofte tilgængelige, varme data vil blive opbevaret i MongoDB's in-memory database cache.

Ved at replikere Redis caches tættere på slutbrugere, kan du undgå høj netværkslatens, når du forespørger MongoDB fra fjerne steder.

Ved at replikere Redis caches tættere på slutbrugere, kan du undgå høj netværkslatens, når du forespørger MongoDB fra fjerne steder.

Data lokalisering kan løses ved at placere replikaer i nærheden af dine app server sites.

Redis har en indbygget Time-to-Live (TTL) funktion, der automatisk fjerner cachede data efter en angivet varighed.

Redis har en indbygget Time-to-Live (TTL) funktion, der automatisk fjerner cachede data efter en angivet varighed.

MongoDB bruger en LRU-cache, så eventuelle dokumenter, der ikke længere bliver efterspurgt, fjernes fra hukommelsen, hvis der er brug for plads til nyere efterspurgte data.Indeks af TTLhvis du vil fjerne dokumenterne fra databasen helt ellerAtlas online arkivHvis du ønsker at flytte dem til billigere opbevaring.

Læsning fra MongoDB gentagne gange kan være ressourceintensiv, især med komplekse forespørgsler, hvilket fører til øgede infrastrukturomkostninger.

Læsning fra MongoDB gentagne gange kan være ressourceintensiv, især med komplekse forespørgsler, hvilket fører til øgede infrastrukturomkostninger.

Din MongoDB-skema skal være designet, så dine vigtige forespørgsler ikke kræver komplekse forespørgsler.

Redis understøtter avancerede datastrukturer som lister, sæt, sorterede sæt, hashes og streams, som MongoDB ikke leverer nativt.

Redis understøtter avancerede datastrukturer som lister, sæt, sorterede sæt, hashes og streams, som MongoDB ikke leverer nativt.

MongoDB understøtter lister og sæt. Hashes kan repræsenteres i MongoDB som en række dokumenter, der indeholder nøgleværdipar (denMongoDB attributter mønster) afMongoDB tidsserie samlingerDet samme gør sig gældende for Redis Streams.

"Resilience and Fault Tolerance.En cache lag kan tjene som en faldback, hvis MongoDB er midlertidigt utilgængelig eller under tung belastning."

"Resilience and Fault Tolerance.En cache lag kan tjene som en faldback, hvis MongoDB er midlertidigt utilgængelig eller under tung belastning."

MongoDB kan skaleres vertikalt eller horisontalt for at opfylde alle belastningskrav.Scaling can be automated when using MongoDB AtlasMongoDB replika sæt giver fejl tolerance for både læser og skriver.

MongoDB kan tage tid at beregne komplekse forespørgsler (f.eks. aggregeringer, joins) for ofte anmodede resultater.

MongoDB kan tage tid at beregne komplekse forespørgsler (f.eks. aggregeringer, joins) for ofte anmodede resultater.

Din MongoDB-skema skal være designet til at undgå behovet for at køre komplekse forespørgsler ofte.MongoDB materialiseret visningUndgå behovet for gentagne gange at udføre den samme komplekse forespørgsel/aggregation.

Hvis jeg ændrer min forespørgsel til "Forklar, hvorfor jeg ikke bør bruge et cache-lag (som Redis) i stedet for at have min ansøgning læse data fra MongoDB direkte," ChatGPT er glad for at afskrække mig fra at tilføje cache-laget, citerer spørgsmål som øget systemkompleksitet, data konsistens problemer, ydeevne for skrive-tunge arbejdsbyrder, omkostninger, forespørgsel fleksibilitet, vedligeholdelse og pålidelighed, små datasæt (hvor det aktive datasæt passer ind i MongoDB's cache), og realtidsrapportering.

Sammendrag

Et cachelag kan tilføje meget værdi, når dit RDBMS ikke kan levere den forespørgselsydning, som dit program kræver.Når du bruger MongoDB, kombineres databasen af poster og cachefunktioner i et enkelt lag, hvilket sparer dig penge og udviklertid.

En distribueret cache kan afhjælpe mangler i dit RDBMS, men MongoDB har en indbygget distribution.

Svar på denne artikel, hvis du stadig tror, at din ansøgning vil drage fordel af et cache lag mellem din ansøgning og MongoDB.

Læs mere om MongoDB design anmeldelser

Design reviewser en chance for en designekspert fra MongoDB at rådgive dig om, hvordan du bedst kan bruge MongoDB til din ansøgning. Anmeldelserne er fokuseret på at gøre dig succesfuld ved at bruge MongoDB. Det er aldrig for tidligt at anmode om en anmeldelse.

Denne artikel forklarede, hvordan design af en MongoDB-skema, der matcher, hvordan din applikation fungerer med data, kan opfylde dine ydeevne krav uden behov for et cache-lag.

Vil din ansøgning drage fordel af en gennemgang?Planlæg din design gennemgang.