Jeg ved ikke, hvem der sagde det, men MongoDB har en måde at cache forespørgsler på, faktisk bruger den OS'ens LRU til at cache, da den ikke selv udfører hukommelsesstyring.
Så længe dit arbejdssæt passer ind i LRU'en uden at OS behøver at bladre det ud eller skifte konstant, bør du på de fleste tidspunkter læse denne forespørgsel fra hukommelsen. Så ja, MongoDB kan cache, men teknisk set gør den det ikke; OS gør.
Caching-mekanismer til at løse denne slags problemer er de samme på tværs af de fleste teknologier, uanset om de er af MongoDB eller SQL. Det betyder selvfølgelig kun hvis det er et problem, du mikrooptimerer sikkert hvis du spørger mig; medmindre du får trafik af typen Facebook eller Google eller Youtube.
Caching-emnet går ind på et stort emne, der spænder fra cache-forespørgsler i enten præ-aggregeret MongoDB/Memcache/Redis osv. til caching af HTML og andre webressourcer for at få så lidt arbejde som muligt på serverenden.
Dit scenarie, personligt som jeg sagde, lyder som om du tænker forkert om den spildte computerkraft. Selv hvis du skulle cache denne forespørgsel i en anden samling/teknologi, ville du sandsynligvis bruge den samme mængde strøm og ressourcer på at hente resultatet fra den teknologi, end hvis du bare ikke gad. Men den antagelse kommer ned til, at du har de rigtige indekser, skema, opsætning osv.
Jeg anbefaler, at du læser nogle links om godt skemadesign og indeksoprettelse:
- http://docs.mongodb.org/manual/core/indexes/
- https://docs .mongodb.com/manual/core/data-model-operations/#large-number-of-collections
Ja, jeg tror, at du ved at prøve at bekymre dig om forespørgselscache optimerer for tidligt, især hvis du ikke ønsker at tage afsted, hvad der ville være 90% af belastningen på din server hver gang; indlæser selve siden.
Jeg ville fokusere på dit skema og dit indeks og derefter bekymre mig om caching, hvis du virkelig har brug for det.