Caching in MongoDb

1. What is Caching?

Caching means storing frequently accessed data in a fast-access memory (RAM), so repeated reads don’t always hit the slower storage disk.

In databases, caching helps reduce query response times and lowers the load on storage and CPU.

2. MongoDB’s Built-in Caching (WiredTiger)

WiredTiger is the default storage engine for MongoDB.

WiredTiger automatically uses a significant portion of RAM as its cache (typically about 50% of available RAM, up to a default limit).

This internal cache holds both recently accessed documents and index entries.

• Whenever your application queries for data, MongoDB will first try to serve it from this in-memory cache:

  Cache Hit: Data is found in RAM — very fast retrieval.

  Cache Miss: Data must be read from disk, which is slower.

  
  

  

  MongoDB’s Built-in Caching (WiredTiger)

3. Index Cache and Data Cache

• Data cache: Stores recently accessed documents.

• Index cache: Holds parts of frequently used indexes for quicker query planning and execution.

  
  

4. Application-Level Caching

• Applications may additionally use separate cache layers (e.g., Redis, Memcached, or even in-process memory).

• Application-level caching avoids repeat queries to MongoDB for the same data—especially useful for high-traffic or read-heavy workloads.

  

  Application-Level Caching

Practical Examples

1. WiredTiger Cache in Use

Scenario: Your dataset includes popular products. Requests for these products are frequent.

• The first time a product is requested, MongoDB loads it from disk into the cache (RAM) and returns it to the user.

• Subsequent requests for the same product are served from RAM (the cache)—this is much faster and reduces latency.

Observation:

• If most of your "working set" (the most frequently used data) fits in RAM, MongoDB will be very fast.

• If your working set is bigger than available RAM, MongoDB will need to read more data from disk, leading to slower performance.

  
  

2. Application-Level Caching Example (with Redis)

Suppose you’re building an app in Node.js. Instead of always querying MongoDB, you check Redis first:

const redis = require("redis"); const mongoose = require("mongoose"); const client = redis.createClient(); async function getData(id) {   const cacheKey = `data:${id}`;   return new Promise((resolve, reject) => {     client.get(cacheKey, async (err, data) => {       if (err) return reject(err);       if (data) return resolve(JSON.parse(data)); // Cache hit       const result = await mongoose.model("products").findById(id);       client.setex(cacheKey, 3600, JSON.stringify(result)); // Save to cache       resolve(result);     });   }); }

Only the first query for a product hits MongoDB; subsequent queries are served from Redis, reducing load and boosting speed.

3. Tuning Cache and Monitoring

• MongoDB lets you adjust the WiredTiger cache size (--wiredTigerCacheSizeGB) depending on your server’s RAM and workload needs.

• Monitoring tools (like mongostat or Atlas monitoring) help you see cache hit ratios and adjust memory allocation if necessary.

  
  

Key Points & Best Practices

• Ensure enough RAM for your working set to get maximum cache benefit.

• Use a cache server (like Redis) for data that is read very frequently and not updated all the time.

• Monitor page faults (indicate cache misses) and adjust server memory if needed.

• For highly dynamic data, use short cache expiry or avoid caching.

• Use caching for expensive or slow aggregation queries that don’t need real-time freshness.

  
  

In summary:MongoDB's built-in cache (WiredTiger) boosts read speed dramatically if your frequently-accessed data fits in memory. For even faster performance and to offload reads, use an external cache like Redis. Understanding and monitoring how your cache is used helps you tune your database and application for top performance