GridGain Systems provides an in-memory data grid (IMDG) that offers extremely low latency access to application data stored fully in memory. Key features of GridGain's IMDG include support for distributed ACID transactions, scalable data partitioning, integration with in-memory compute grids, and datacenter replication to ensure high availability. The IMDG allows applications to work directly with domain objects and provides SQL querying capabilities for fast analysis of in-memory data.

1. Technical Brief
In-Memory Data Grid
GridGain Systems, November 2012
Overview
Many companies that would not have considered using in-memory technology in
the past due to its cost are now changing their core systems’ architectures to
accommodate it. They want to take advantage of the low-latency transaction
processing in-memory technology offers. With the price of 1GB of RAM less than a
one dollar and RAM prices dropping 30% every 18 months it has become
economically affordable to load entire operational datasets into memory and
achieve dramatic performance improvements.
Companies are using this, for example, to perform calculations or create live
dashboards that give management immediate insight into crucial operational data
from their systems. Currently, users often have to wait until the end of a reporting
period for batch jobs to process the accumulated data and generate the desired
reports.
Modern in-memory technology connects to existing data stores such as Hadoop or
traditional data warehouses and makes this data available in RAM, where it can
then be queried or used in processing tasks with an unprecedented performance.
The power of such insight in real-time lets companies react exponentially faster

2. and more flexible than what current systems allow.
This paper is meant to help readers understand what the key features of modern
in-memory products are and how they affect the eventual integration and
performance. Two key components are the underlying basis for the core
capabilities of in-memory technology: in-memory compute and data grids. This
paper concentrates on the in-memory data grids.
What is an In-Memory Data Grid?
The goal of an In-Memory Data Grid (IMDG) is to provide extremely low latency
access to, and high availability of, application data by keeping it in memory and to
do so in a highly parallelized way. By loading terabytes of data into memory, an
IMDG is able to support most of the Big Data processing requirements. At a very
high level an IMDG is a distributed key-value object store similar in its interface to a
typical concurrent hash map. You store and retrieve objects using keys.
Unlike systems where keys and values are limited to byte arrays or strings, an
IMDG can have any application domain object as either a value or a key. This
provides tremendous flexibility: exactly the same object your business logic is
using can be kept in the data grid - without the extra step of marshaling and de-
marshaling. It also simplifies the use of the data grid because you can in most
cases interface with the distributed data store like with a simple hash map.
Being able to work with domain objects directly is one of the main differences
between IMDGs and In-Memory Databases (IMDB). With the latter, users still need
to perform Object-To-Relational Mapping (ORM) which typically adds significant
performance overhead and complexity. With in-memory data grids this is avoided.
How Do In-Memory Data Grids Differ From
Other Solutions?
An IMDG, in general, is significantly different from products such as NoSql
databases, IMDBs or NewSql databases. For example, here are just some of the
GridGain's IMDG features that make it unique:
Support for true distributed ACID transactions with highly optimized 2PC
protocol implementation
Scalable Data Partitioning across a cluster including both partitioned or
fully replicated scenarios
Ability to work directly with application domain objects rather than with

3. primitive types or "documents"
Tight integration with In-Memory Compute Grid (IMCG)
Zero Deployment for both IMCG and IMDG
Pluggable segmentation (a.k.a. "brain split" problem) resolution
Pluggable expiration policies (including built-in LRU, LIRS, random and time-
based)
Read-through and write-through with pluggable durable store
Synchronous and asynchronous operations throughout
Pluggable data overflow storage
Master/master data replication and invalidation in both synchronous and
asynchronous modes
Write-behind cache store support
Automatic, manual and delayed pre-loading on topology changes
Support for fully active replicas (backups)
Support for structured and unstructured data
Pluggable indexing support
Essentially IMDGs in their purest form can be viewed as distributed hash maps with
each key cached on a particular cluster node - the bigger the cluster, the more
data you can cache. The trick to this architecture is to make sure that the
processing occurs on those cluster nodes where the required data is cached. By
doing this all cache operations become local and there is no, or minimal, data
movement within the cluster. In fact, when using a well-designed IMDG there
should be absolutely no data movement on stable topologies. The only time when
some of the data is moved is when new nodes join or some existing nodes leave,
hence causing some data repartitioning within the cluster.
The picture below shows a classic IMDG with a key set of {k1, k2, k3} where each
key belongs to a different node. The external database component is optional. If
present, then IMDGs will usually automatically read data from the database or write
data to it (a.k.a. read-through and write-through logic):

4. Even though IMDGs usually share some common basic functionality, there are many
features and implementation details that are different between vendors. When
evaluating an IMDG product, pay attention to eviction policies, (pre)loading
techniques, concurrent repartitioning or its memory overhead, for example. Also
pay attention to the ability to query data at runtime. Some IMDGs, such as
GridGain for example, allow users to query in-memory data using standard SQL,
including support for distributed joins, which is pretty rare.
The typical use of IMDGs is to partition data across the cluster and then send
collocated computations to the nodes where the data is. Since computations are
usually part of Compute Grids and have to be properly deployed, load-balanced,
failed-over or scheduled, the integration between Compute Grids and IMDGs is very
important to obtain the best performance. Especially when both In-Memory
Compute and Data Grids are optimized to work together and utilize the same APIs,
it is faster for developers to deploy system that offers the highest performance
reliably.
Distributed ACID Transactions
One of the distinguishing characteristic of IMDGs is support for Distributed ACID
Transactions . Generally, a 2-phase-commit (2PC) protocol is used to ensure data
consistency within a cluster. Different IMDGs will have different underlying locking
mechanisms, but more advanced implementations provide concurrent locking

5. mechanisms (like MVCC - Multi-Version Concurrency Control), reduce network
chattiness to a minimum, and specifically optimize its main algorithms for in-
memory processing - guaranteeing transactional ACID consistency with very high
performance.
Guaranteed data consistency is one of the main differences between IMDGs and
NoSQL databases.
NoSQL databases are usually designed with an Eventual Consistency (EC) approach
where data is allowed to be inconsistent for a period of time as long as it will
eventually become consistent. Generally, the writes on EC-based systems are
somewhat fast, but reads are slow (to be more precise: as fast as writes are).
Latest IMDGs with an optimized 2PC protocol should at least match, if not
outperform, EC-based systems on writes, and be significantly faster on reads. It is
interesting to note that the industry has made a full circle moving from a then-
slow 2PC approach to the EC approach, and now from EC to an optimized 2PC,
which often is significantly faster.
Different products have optimized the 2PC protocol in different ways, but
generally the purpose of all optimizations is to increase concurrency, minimize
network overhead, and reduce the number of locks a transaction requires to
complete. As an example, Google’s distributed global database, Spanner, is based
on a transactional 2PC approach simply because 2PC provided a faster and more
straightforward way to guarantee data consistency and a high throughput.
GridGain introduced "HyperLocking" technology that enabled effective single and
group distributed locking that is at the core of its transactional performance.
Distributed data grid transactions in GridGain span data cached on local as well as
remote nodes. While automatic enlisting into JEE/JTA transactions is supported,
GridGain data grid also allows users to create more light-weight cache transactions
which are often more convenient to use. GridGain cache transactions support all
ACID properties that you would expect from any transaction, including support for
Optimistic and Pessimistic concurrency levels and Read-Committed, Repeatable-
Read, and Serializable isolation levels. If a persistent data store is configured, then
the transactions will also automatically span the data store.
Multiversion Concurrency Control (MVCC)
GridGain’s in-memory data grid concurrency is based on advanced implementation
of MVCC (Multi Version Concurrency Control) – the same technology used by
practically all database management systems. It provides practically a lock free
concurrency management by maintaining multiple version of data instead of using
locks with a wide scope. Thus, MVCC in GridGain provides a backbone for high
performance and overall system throughput for systems under load.

6. In-Memory SQL Queries
What use would be from caching all the data in memory if you could not query it?
The in-memory platform should offer a variety of different ways to query its data,
such as standard SQL-based queries or Lucene-based text queries.
The JDBC driver implementation lets you to query distributed data from the
GridGain cache using standard SQL queries and the standard JDBC API. It will
automatically get only the fields you actually need from the objects stored in
cache.
The GridGain SQL query type lets you perform distributed cache queries using
standard SQL syntax. There are almost no restrictions as to which SQL syntax can
be used. All inner, outer, or full joins are supported, as well as rich set of SQL
grammar and functions. The ability to join different classes of objects stored in
cache or across different caches makes GridGain queries a very powerful tool. All
indices are usually kept in memory resulting in very low latencies for the execution
of queries.
Text queries are available when you are working with unstructured text data.
GridGain can index such data with the Lucene or H2Text engine to let you query
large volumes of text efficiently.
If there is no need to return result to the caller, all query results can be visited

7. directly on the remote nodes. Then all the logic is performed directly on the
remotely queried nodes without sending any queried data to the caller. This way
analytics can be run directly on structured or unstructured data with in-memory
speed and low latencies. At the same time GridGain provides applications and
developers a familiar way to retrieve and analyze the data.
Here’s the quick example. Notice how Java code looks 100% identical as if you talk
to a standard SQL database – yet you are working in in-memory data platform:
// Register JDBC driver.
Class.forName("org.gridgain.jdbc.GridJdbcDriver");
// Open JDBC connection.
conn = DriverManager.getConnection(
"jdbc:gridgain:/ / localhost/" + CACHE_NAME,
configuration()
);
// Create prepared statement.
PreparedStatement stmt = conn.prepareStatement(
"select name, age from Person where age >= ?"
);
// Configure prepared statement.
stmt.setInt(1, minAge);
// Get result set.
ResultSet rs = stmt.executeQuery();
BigMemory Support
Traditionally JVM has been very good with Garbage Collection (GC). However, when
running with large amounts of memory available, GC pauses can get very long. This
generally happens because GC now has a lot more memory to manage and often
cannot cope without stopping your application completely (a.k.a. lock-the-world
pauses) and allowing itself to catch up. In our internal tests with heap size set to
60G or 90G GC pauses some times were as long as 5 minutes. Traditionally this
problem was solved by starting multiple JVMs on the same physical box, but that
does not always work very well as some applications want to collocate large
amounts of data in one JVM for faster processing.

8. To mitigate large GC pauses, GridGain supports BigMemory with data allocated off-
heap instead of on-heap. Thus, the JVM GC does not know about it and does not
slow down. You can start your Java application with a relatively small heap, e.g.
below 512M, and then let GridGain utilize hundreds of gigabytes of memory as off-
heap data cache. Whenever data is first accessed, it gets cached in the on-heap
memory. Then, after a certain period of non-use, it gets placed into off-heap
memory cache. If your off-heap memory gets full, the least used data can be
optionally evicted to the disk overflow store, also called swap store.
One of the distinguishing characteristics of GridGain off-heap memory is that the
on-heap memory foot print is constant and does not grow with the size of your
data. Also, an off-heap cache entry has very little overhead, which means that you
can fit more data in memory. Another interesting feature of GridGain is that both
primary and secondary indices for SQL can be optionally kept in off-heap memory
as well.
Datacenter Replication
When working with multiple data centers it is important to make sure that if one
data center goes down, another data center is fully capable of picking up its load
and data. Data center replication is meant to solve exactly this problem. When
data center replication is turned on, GridGain data grid will automatically make sure

9. that each data center is consistently backing up its data to other data centers
(there can be one ore more).
GridGain supports both active-active and active-passive modes for
replication. In active-active mode both data centers are fully operational online and
act as a backup copy of each other. In active-passive node, only one data center is
active and another data center serves only as a backup for the active data center.
Datacenter replication can be either transactional or eventually-consistent. In
transactional mode, a data grid transaction will be considered complete only when
all the data has be replicated to another datacenter. If the replication step failed,
then the whole transaction will be rolled back on both datacenters. In eventually
consistent mode transaction will usually complete before the replication finished. In
this mode the data is usually concurrently buffered on one data center and then
gets flushed to another data center either when buffer fills up or when certain time
period elapses. Eventually consistent mode is generally a lot faster, but it also
introduces a lag between updates on one data center and data being replicated to
another.
If one of the datacenters goes offline, then another will immediately take
responsibility for it. Whenever the crashed data center goes back online then it will
receive all the updates it has missed from another data center.
In-Memory Compute Grid Integration
Integration between IMCG and IMDG is based on idea of affinity routing .
Affinity routing is one of the key concepts behind Compute and Data Grid
technologies (whether they are in-memory or disk based). In general, affinity

10. routing allows to co-locate a job and the data set this job needs to process.
The idea is pretty simple: if job and data are not co-located, then job will arrive on
some remote node and will have to fetch necessary data from yet another node
where data is stored. Once processed this data will most likely will have to be
discarded (since it’s already stored and backed up elsewhere). This process
induces expensive network trip plus all associated marshaling and demarshaling. At
scale – this behavior can bring almost any system to a halt.
Affinity co-location solves this problem by co-locating job with its necessary data
set. We say that there is an affinity between a processing (i.e. job) and the data
that this processing requires – and therefore we can route the job based on this
affinity to a node where data is stored to avoid unnecessary network trips and
extra marshaling and demarshaling.
GridGain provides advanced capabilities for affinity co-location: from a simple
single-method call to sophisticated APIs supporting complex affinity keys and non-
trivial topologies.
Summary
In-memory data grids are used throughout a wide spectrum of industries in

11. applications as diverse as risk analytics, trading systems, bioinformatics,
ecommerce or online gaming. Essentially, every project that struggles with
scalability and performance can benefit from in-memory processing and an in-
memory data grid architecture. When you consider different products, make sure
you have the advanced features outlined in this paper. This way you can find an
optimal solution for your needs and ensure right at the onset that your solution
will actually scale flawlessly in those critical moments when you need it to scale.