Data Grid – Cache Evolved

October 17, 2012

Administration, Data Grid, NOSQL

A data grid is one part cache and one part NOSQL. This post will discuss clustered caches, their limitations, and how data grids have incorporated NOSQL concepts in order to overcome them. It concludes with a couple of use cases related to application server clusters and data grids.

Cache

The purpose of a cache is to reduce data access time in order to improve application performance. For example, accessing data from system memory (RAM) is faster than accessing data from a solid state drive (SSD) or a hard disk drive (HDD) via a database.

A typical use case is to cache data from a database during a request so that data is accessed from the cache instead of the database in later requests.

Within an application server cluster, the purpose of a cache is to both improve application performance and support high availability (HA) & failover. A clustered cache relies on replication to support HA / failover, and it relies on invalidation to improve application performance without compromising data integrity & consistency.

Replication

HTTP session state is replicated so that in the event of a server failure, requests can be forwarded to a different server without interruption.

Example

  1. A request is received on Application Server #1 to add an item to the user’s shopping cart.
    1. The application creates a user session.
    2. The user session is cached.
    3. The user session is replicated to the cache in Application Server #2.
  2. Application Server #1 fails.
  3. A request in received on Application Server #2 to proceed to check out.
    1. The application accesses the user session in the cache.

Invalidation

If a clustered cache does not rely on replication, then data integrity / consistency may be compromised. If an object in the cache is updated in one application server, the object in the cache in the other application server becomes stale. It is out of date. To ensure that data integrity / consistency is not comprised, a clustered cache relies on invalidation in the absence of replication. As a result, the stale object is invalidated in the cache in the other application server.

Example

  1. A request is received on Application Server #1 to update a blog post.
    1. The blog post in the cache is updated.
    2. Updates to the blog post are persisted to the database.
    3. The blog post is invalidated in the cache in Application Server #2.
  2. A request is received on Application Server #2 to view the blog post.
    1. The application accesses the blog post from the cache.
      The blog post is no longer in the cache.
    2. The application accesses the blog post from the database.

Limitations

A replicated cache does not scale out. The capacity of a replicated cache is limited to the capacity of the cache in any one application / application server instance. If the capacity of the cache in any one application / application server instance is 1,000 objects, then the capacity of the replicated cache is 1,000 objects. Adding additional application / application server instances will not result in an increase of the capacity of the replicated cache.

An invalidated cache does not fully realize the application performance improvement of a cache. If an object is cached in one application / application server instance, it may not be cached in the other application / application server instances. If a cached object is updated in one application / application server instance, it will be invalidated in the cache of the other application / application server instances. The only way reduce the number of cache misses is to tie a user to an application / application server instance (e.g. session pinning). However, that negates the application performance improvements of load balancing.

A clustered cache is embedded in the application / application server cluster. As such, it is coupled to the lifespan of the application / application server cluster. If all of the instances of an application / application server cluster are stopped, the clustered cache is stopped. That is to say, a clustered cache is not deployed independently of the application / application server cluster.

NOSQL

In order to overcome the limitations of clustered caches, data grids have incorporated NOSQL concepts.

Distribution

A replicated cache does not scale out, a data grid does. In fact, a data grid scales linearly. This is because the data is distributed (partitioned) such that each node is the primary owner of a subset of the data (partition). For example, if there are 4 nodes available and the capacity of each node is 1,000 objects, the capacity of a replicated cache with these nodes would be 1,000 objects whereas the capacity of a data grid with these nodes would be 4,000 objects. While adding a fifth node to the replicated cache would not increase the capacity of the replicated cache, adding a fifth node to the data grid would increase the capacity of the data grid by 1,000 objects to 5,000 objects.

Example

  1. The application caches 8 objects.
    1. Objects 1, 4, and 7 are distributed to the cache in App Server #1.
    2. Objects 2, 5, and 8 are cached locally.
    3. Objects 3 and 6 are distributed to the cache in App Server #3.

While an invalidated cache may be prone to cache misses, a distributed cache is not. If the previous diagram depicted an invalidation cache and the application accessed object 1 in Node B, it would result in a cache miss. Because it is a data grid, Node B would access object 1 from Node A resulting in a cache hit. Whereas an invalidated cache requires that a user is tied to an application / application server instance (e.g. session pinning) and thus negating the application performance improvements of load balancing, a data grid does not.

Client / Server

Whereas a clustered cache is embedded within the application / application server cluster, a data grid may or may not be. A data grid can be deployed independently of the application / application server cluster. As a result, the data grid is no longer coupled to the lifespan of the application / application server cluster. If every instance of an application / application server cluster failed, the data grid would remain unaffected. Further, administrators can manage the data grid independently of the application / application server cluster.

In addition, this allows for better allocation of system resources as the application, the application server, and the data grid no longer have to contend for system resources. In fact, the data grid can be deployed with different system resources than the application server. For example, the application server cluster may contain 6 instances while the data grid contains 24 instances. The instances in the application / application server cluster may have a faster CPU than the instances in the data grid while the instances in the data grid have more memory than the instances in the application / application server cluster.

Use Cases

The data grid can be deployed independently of the application sever cluster in order to externalize the session cache and thus increase the number of user sessions that the application server cluster can handle.

The data grid can be deployed independently of multiple application server clusters in order to create a shared cache rather than multiple, embedded caches.

This post is the first in a series introducing the concepts of data grids and JBoss Data Grid itself.

  1. Data Grid – Cache Evolved
  2. We, Data Grid
  3. Data Grid, JBoss Data Grid
, ,

About Shane K Johnson

Technical Marketing Manager, Red Hat Inc.

View all posts by Shane K Johnson

3 Comments on “Data Grid – Cache Evolved”

  1. Galder Says:

    Nice write up Shane!

    Reply

Trackbacks/Pingbacks

  1. Heti érdekességek 18. « LES - October 18, 2012

    […] Data Grid – Cache Evolved  by Shane K Johnson […]

  2. When is ModeShape a good fit « ModeShape - October 18, 2012

    […] database, to leveraging the performance, scalability, and durability of an in-memory and elastic data grid. In may seem counter-intuitive, but storing your data in RAM is extremely fast as long as multiple […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: