What is Database Caching ?
Caching is storing data temporarily in a high-speed storage layer (for example, in a computer RAM) to serve data faster when clients make the same future requests. This enhances the re-use of previously computed data instead of fetching it each time from the disk.
Why do we need caching ?
- Improved application performance
Reading data from an in-memory cache is much faster than accessing data from a disk-driven data store. And with faster access to data, the overall application experience significantly improves. - Reduced database usage and costs
Caching leads to fewer database queries, improving performance and reducing costs by limiting the need to scale database infrastructure and decreasing throughput charges. - Scalable and predictable performance
Caching also offers the flexibility you need whether you’re scaling out or scaling up your applications and data stores. Then your application can let many users access the same files simultaneously, without increasing the load on back-end databases. And if an application often experiences spikes in usage and high throughput, in-memory caches can mitigate latency.
Types of caching
- Cache-aside
In this strategy, cache outside the application. The application will first request the data from the cache. If the data exists, the app will retrieve the data directly. If not, the app will request data from the database and write it to the cache so that the data can be retrieved from the cache again next time.
Pros :
- The cache contains only data that the application actually requests, which helps keep the cache size cost-effective.
- Implementing this approach is straightforward and produces immediate performance gains, whether you use an application framework that encapsulates lazy caching or your own custom application logic.
Cons :
- When the data is requested the first time, it always results in the cache miss and requires the extra time of loading data the cache.
- Read-through/write-through cache
Read-through caches keep themselves up to date, while with write-through caching, the application writes data to the cache and then to the database. Both caches sit in line with the database, and the application treats them as the main data store. If a ‘cache miss’ occurs, the cache is responsible to retrieve data from the database, update itself and return data to the application. Read-through caches help simplify applications where the same data is requested over and over, but the cache itself is more complex, while the two step write-through process can create latency.
Pros :
- Decrease load on the data source when there are a lot of reads, because cache provider can sync access to cache keys, so in the end we will have only one cache miss.
- Systems using read-through strategy can also be resilient to cache failures. If the cache goes down, the cache provider can still operate by going directly to the data source.
- Advanced data consistency guarantee.
Cons :
- When the data is requested the first time, it always results in the cache miss and requires the extra time of loading data the cache. To deal with this developers use ‘warming’ or ‘pre-heating’ the cache by issuing queries manually.
- Just like cache-aside, data can also become inconsistent between cache and the data source.
- Increased write latency.
- Write-behind/write-back cache
In this scenario, the application writes data to the cache, which is immediately acknowledged, and then the cache itself writes the data back to the database in the background / asynchronously.
Pros :
- It’s resilient to data source failures and can tolerate some data source downtime.
- If batching or coalescing is supported, it can reduce overall writes to the data source, which decreases the load and reduces costs.
Cons :
- If there’s a cache failure, the data may be lost permanently
Thanks for reading.
#NeverEndingImprovement
references :
https://blog.logrocket.com/caching-strategies-to-speed-up-your-api/
https://zubialevich.blogspot.com/2018/08/caching-strategies.html
