Ik weet niet wie dat zei, maar MongoDB heeft wel een manier om query's te cachen, in feite gebruikt het de LRU van het besturingssysteem om te cachen, omdat het zelf geen geheugenbeheer uitvoert.
Zolang uw werkset in de LRU past zonder dat het besturingssysteem deze hoeft uit te wisselen of constant te wisselen, zou u deze query meestal uit het geheugen moeten lezen. Dus ja, MongoDB kan cachen, maar technisch gezien niet; het besturingssysteem wel.
Caching-mechanismen om dit soort problemen op te lossen zijn hetzelfde voor de meeste techs, of ze nu door MongoDB of SQL zijn. Dit is natuurlijk alleen van belang als het een probleem is, je bent waarschijnlijk aan het micro-optimaliseren als je het mij vraagt; tenzij u verkeer van het type Facebook of Google of YouTube ontvangt.
Het caching-onderwerp gaat over een enorm onderwerp dat varieert van caching-query's in ofwel vooraf geaggregeerde MongoDB/Memcache/Redis enz. tot caching van HTML en andere webbronnen om zo min mogelijk werk aan de serverzijde te maken.
Uw scenario klinkt, zoals ik al zei, alsof u verkeerd denkt over de verspilde computerkracht. Zelfs als je deze query in een andere verzameling/technologie zou opslaan, zou je waarschijnlijk dezelfde hoeveelheid kracht en middelen gebruiken om het resultaat van die technologie op te halen dan wanneer je je er niet druk om zou maken. Die veronderstelling komt er echter op neer dat je de juiste indexen, schema's, instellingen enz. hebt.
Ik raad je aan enkele links te lezen over goed schema-ontwerp en het maken van indexen:
- http://docs.mongodb.org/manual/core/indexes/
- https://docs .mongodb.com/manual/core/data-model-operations/#large-number-of-collections
Ja, ik denk dat door je zorgen te maken over het cachen van query's, je voortijdig optimaliseert, vooral als je niet wilt opstijgen, wat elke keer 90% van de belasting van je server zou zijn; het laden van de pagina zelf.
Ik zou me concentreren op je schema en indexen en je dan zorgen maken over caching als je het echt nodig hebt.