Posted by: Sasirekha R
cache, Cloud, Elastic Caching Platform, eXtreme Scale, Forrester, grid, IBM, latency, NoSQL, Scalability, shard
Understanding Elastic Caching Plaftorms – IBM eXtreme Scale
Data Caching is a standard technique used for improving application performance. Local caching, though the fastest, is not able to scale and caching multiple copies of the same data in local caches raises a complication of keeping the copies in sync (and it gets all the more difficult to manage when the number of nodes involved is in hundreds).
By Elastic Caching, a caching layer to cache data (involving a cluster with large number of caching nodes) is added to the web architecture. Elastic caching can handle large amounts of data (and not limited by the memory in a single server) and provide massive scalability. With Cloud Computing – which can be said to be about Elastic Infrastructure, makes Elastic Caching platforms necessary.
Forrester defines Elastic Caching Platforms as: Software infrastructure that provides application developers with data caching services that are distributed across two or more server nodes that:
1. Consistently perform as volumes grow.
2. Can be scaled without downtime and
3. Provide a range of fault-tolerance levels
According to Forrester, “Elastic Caching Platforms are Key/Value (KV) stores on Steriods“. Available elastic caching platforms include IBM eXtremeScale, Gigaspaces, Terracotta, Microsoft Velocity, Hazelcast, NCache, and Infinispan. In addition to providing the benefits of NoSQL – Low latency, Scaling out, these products have better reliability and security features.
Let me elaborate on IBM’s WebSphere eXtreme Scale – that provides a high-performance, scalable cache framework using Grid technology – and is referred to as a “Data Grid“. Using a large amount of loosely-coupled cooperative caches to store data, the data grid provides for provisioning and accessing information in grid style. Data intensive computing tasks can be executed in parallel in the grid.
WebSphere eXtreme Scale is designed to scale to thousands of grid containers. Large amounts of data can be splits into manageable chunks and distributed across the grid containers. Clients can directly access the partition that holds the relevant data. High availability of cached data is ensured by holding multiple copies of the same data (or replicas). A single instance of a partition is a shard. Using zone support that allows rule based shard placement, it can be ensured that replicas reside in physically different locations (for disaster handling).
Linear scale outs are possible as there is very limited communication between the grid containers:
1. Availability of containers is managed by communication that occurs within a group (say around 20 containers in each group).
2. Data is replicated across containers holding the same data using peer-to-peer replication.
WebSphere eXtreme Scale provides built-in transaction support so that all changes made to the cached data are committed or rolled back in an atomic way. The changes to objects are tracked in a difference map. In case of commit, the changes are applied to the all the copies of the cached objects. Replication can be synchronous (commit only after all the replicas are changed) or asynchronous (replicas are updated after commit). Locking (Optimistic or Pessimistic) is used to ensure that the data has not been changed in between. In case of rollback, the difference map is discarded and the existing locks are released. Transaction support also ensures that multiple individual operations that work in tandem are treated as a single unit of work.
Key Internal components of eXtreme Scale are:
- Session – Sessions are single threaded and can be connected directly by a user or through a front-end application.
- Map – Map is an interface that stores data as key/value pairs (KVPs) associating an object with a key.
- ObjectMap – A type of map that is used to store a value for a key. The value can either be an object instance with its corresponding class file in the JVM or a tuple that represents the attributes of an object.
- BackingMap – A BackingMap contains cached objects that have been stored in the grid. Any serializable entity attributes are persisted to the BackingMap. BackingMaps and ObjectMaps communicate remotely to persist data.
Unlike in-memory databases (IMDB) that keep the data in memory and tend to replace the database, WebSphere eXtreme Scale complements the database by providing a caching fabric (where the objects are stored in-memory closer to the application) that manifests itself as a grid layer before the database. The disadvantage is that the data has to be converted to objects (using a persistence framework – that has a performance overhead) before placing them in the grid and converted again before placing them in the database. As data is represented as single entity, the data grid does not support SQL. Instead, eXtreme Scale supports Object Grid Query Language (OGQL) which is similar to Java Persistence Query Language (JPQL).
Grid data can be accessed using two APIs – ObjectMap API and EntityManager API:
1. ObjectMap API allows typical CRUD operations to the grid cache. ObjectMaps provide a simple and intuitive approach to store data and ideal for objects with no relationships. Access is easy and fast as it is stored as key/value pairs and accessed using primary key. Using ObjectMap API is similar to that of Java maps (java.util.map).
2. In EntityManager API, objects are represented as entities which allows relationships. Relationships are defined in a schema or through Java annotations. EntityManager API converts entity objects to and from tuples before storing or reading them from the Map.
EntityManager API provides a performance advantage as it uses tuple sets of only primitive and does not rely on serialization. It is easier to use as it follows the well adopted POJO-style programming (Plain Old Java Object). The limitations is that applications cannot share a cache if they use different objects for the same data.
In addition to standard authentication and authorization, IBM eXtreme Scale provides system and transport security. System security controls access and operational management of the data grid. Transport security ensuring secure communications between the remote clients and grid servers is achieved by reliable multicast messaging (RMM). SSL is not supported and it is assumed that the grid is in a secured infrastructure (behind domain and protocol level firewalls).
Scenarios where eXtreme Scale integrates into generic application architecture include:
- A side cache scenario where the grid is located beside the application. When the data is accessed, the grid is checked first and if not available the data is accessed using the existing mechanisms and stored in the grid. It requires special caching logic code to be introduced. In this, the data centric lower application layers are more likely to be an integration point.
- Second level cache augmenting caching components available in Persistence frameworks. WebSphere eXtreme Scale provides out of the box support for the OpenJPA and Hibernate.
- WebSphere eXtreme Scale used as a natural extension of an existing data waccess layer. The grid provides the results to the client applications that access it directly using APIs making the caching and data access logic transparent to the application. Loaders can be implemented to ensure that all the rows are located in the grid, providing extremely fast and scalable access.
- DataGrid computing – where the application is specifically designed to use an in-memory database providing full scale grid style computing with extreme scalability and high availability. In this, the grid become the system of record and the back-end is only used as data store for handling outages, and to support reporting and data warehouse access.
WebSphere eXtreme Scale has been proven to run with more than 1000 Java virtual machines (JVMs) participating in a data grid managing half a terabyte of data. The grid – being self-managed – provides a scalable infrastructure for data. The infrastructure can expand as the needs of the application grow by simply adding new JVMs. Similarly, when a JVM is removed, the catalog server attempts to redistribute the shards (single instance of a partition) that best fit the available JVMs (in effect scale in is supported) using Waterflow algorithm.
Forrester comment “Elastic caching and cloud computing are a match made in heaven for app scaling in the cloud” is quite appropriate. In addition to improving performance and scalability, the fact that using elastic cache platforms can reduce RDBM licenses and maintenance resulting in significant cost savings makes it a worthy proposition.