{"id":42651,"date":"2016-11-26T10:40:33","date_gmt":"2016-11-26T05:10:33","guid":{"rendered":"http:\/\/www.tothenew.com\/blog\/?p=42651"},"modified":"2017-01-26T16:22:48","modified_gmt":"2017-01-26T10:52:48","slug":"caching-what-why-and-how-with-hazelcast","status":"publish","type":"post","link":"https:\/\/www.tothenew.com\/blog\/caching-what-why-and-how-with-hazelcast\/","title":{"rendered":"Caching: What, Why and How with Hazelcast"},"content":{"rendered":"

In modern user facing and real-time applications<\/a>, performance is the top concern with usually having data at its core. What if you were able to\u00a0offload some work from the database and at the same time increase the performance and response times of your application<\/a>?<\/strong><\/span><\/p>\n

Most of the time data handling is done by relational databases which provide access to data. Applications talk directly to the database which at times can have a hot-swappable backup machine. In most cases, the only solution to\u00a0increase the application performance is to scal<\/span>e it vertically, i.e, increase more RAM, add more CPU power, etc. and that comes at a cost.<\/span><\/p>\n

What is Software Caching?<\/strong><\/p>\n

In computing<\/a>, a cache is a hardware or software component that stores data for server\u00a0future data requests faster. The data stored in a cache can be the result of an earlier computation, or the duplicate of data stored elsewhere.<\/p>\n

Why it is needed?<\/strong><\/p>\n

We all are\u00a0aware of the cache used by CPU\/hardware that helps to process faster. What if this concept can be taken to the application\/software level.\u00a0This is where Caching helps.<\/span><\/p>\n

There are practices prevalent in the industry to use such kind of solutions in many forms, they may be known as key-value stores (Redis, etc.), in-memory databases (Gridgain, etc.) and many more. In fact, one type of software cache that we all might have used someday is Hibernate\u2019s second level caching.<\/p>\n

How Caching is done?<\/strong><\/p>\n

Below are few possibilities of handling such scenarios at an architectural level:<\/span><\/p>\n

1. You would either let the application consult the cache first for data and if it is a miss, then the same application consults the backing store for the data. A schematic diagram is shown below.<\/span><\/strong><\/p>\n

\"Cache<\/p>\n

2. Or else, you would take that functionality out from the application into a separate application\/process and the application will transparently get data from the 3rd application which will be responsible for fetching data from cache\/database and keeping the cache in sync with the backing store. This particular approach is termed as Read-Through\/Write-Through approach. Refer\u00a0Diagram below.<\/span><\/strong><\/p>\n

\"Cache<\/p>\n

The first approach fails when the database is saturated, or the application performs mostly the “put” operations (writes). Further, this approach is of no use because it offloads the database only from the “get” loads (reads). Even if the applications are read-intensive, there can be consistency problems in case if\u00a0data changes. This is when concepts like time-to-live (TTL) or write-through comes in.<\/p>\n

Also, in the case of TTL, if the access is less frequent than the TTL value, the result will always be a cache miss.\u00a0<\/span><\/strong><\/p>\n

Above discussion\/concerns regarding caching can be summarized\u00a0as under:<\/b><\/p>\n