Databases
Databases, with no doubts are considered a critical part of an application. Data I/O speeds can be considered a direct factor deciding app's performance and hence the user experience.
I'd not say we need an external caching implementation on any system until it is on a considerable scale with visible performance degradation because databases themselves have tricks up their for speeding their I/O.. Didnt knew that? Damn! read this:
-> Frequently accessed data pages are cached in memory to reduce disk I/O and improve query performance.
-> Even recurrent query plans are cached by database to reduce overheads of repeated query planning!
Indeed databases are one interesting topics to look into.
Anyways getting back to what we shall discuss here, The following article will probable tell you something or two about the caching patterns followed in three-tier web architecture systems (client, server, database) or even similar systems.
What is database caching?
By its simplest definition, a technique to store frequently used data in a temporary memory.
A good caching strategy will ease the load on your database by routing the frequently used queries to read from cache before hitting our database.
A cache layer can exist at
-> Database layer (Internal)
-> Application layer (External)
-> A separate service layer (External)
So why cache? Coz we want things faster, faster, faster
Performance
Since it stores frequently accessed data separately, reduces the latency in data lookup and even the amount of work to be done by database
Availability
Not calling it as a backup plan but don't you think in case our database fails, we would have our cache with our data to not cause 100% downtime?
Scalability
I think if you understood the above points, you can perfectly imagine how caching can improve scalability of your application! Reduces workload on database, faster query responses blah blah.. yeah you got it right!
Let's move to the design patterns of caching!
The Caching Strategies
Cache-aside
Checks cache first for incoming query, if cache hit (found) responds with it else queries database -> responds -> updates caches.
A good general purpose caching strategy works for most cases.
Disadvantages? Yeah a window of inconsistency of data between db and cache.
Read-through
Sits between application and database, difference? application always reads from cache, in case of cache miss, data is populated to cache and then returned to client. The writes are always performed on database btw.
Disadvantages? Time delay of filling the cache first in case of miss and then returning the data.
Quick solution? Devs warm up the cache i.e refresh cache time to time with most in demand data, ik not the best solution out there but saves the day!
Write-through
Sites between client and database same as usual.. then the difference? maybe you can guess... yep data is first written to cache which immediately writes to database.
Benefit? New data is always available to cache.
Disadvantages can be the write latencies.
Write-back
Exactly same as write-through but but but... data is not immediately written back to db but is done at a delay.
This reduces the pressure and the load on the cache in a write-heavy workload.
It improves overall performance too if the delayed writes are batched up together (database will be happy too).
P.S. If cache fails in wrong window, you might lose your new written data which was not yet written to db.
Write-around
Usually coupled with cache-aside or read-through, one of the flows can be:
- Data read through cache.
- If miss, its read from database.
- Cache is also updated for next time.
- Best when there is less write workloads.
Conclusion
We discussed various strategies for database caching which might one day
help you scale your application to new horizons!! (Well umm maybe not horizons but to better limits). Even if you're not implementing cache now, I'd say its better to know your cards well so you can play it right when time comes.
Thanks for your time, hope you learnt something new.
Top comments (0)