Cache < Data Grid < Database

i would like to clarify definitions for the following technologies:

• in-memory distributed cache
• in-memory data grid
• in-memory database

these three terms are, surprisingly, often used interchangeably and yet technically and historically they represent very different products and serve different, sometimes very different, use cases.

it’s also important to note that there’s no specifications or industry standards on what cache, or data grid or database should be (unlike java application servers and jee, for example). there was and still is an attempt to standardize caching via jsr107 but it has been years (almost a decade) in the making and it is hopelessly outdated by now (i’m on the expert group).

tricycle vs. bike vs. motorcycle

first of all, let me clarify that i am discussing caches, data grids and databases in the context of in-memory, distributed architectures. traditional disk-based databases and non-distributed in-memory caches or databases are out of scope for this article.

chronologically, caches, data grids and databases were developed in that order: starting from simple caching to more complex data grids and finally to distributed in-memory databases. the first distributed caches appeared in the late 1990s, data grids emerged around 2002-2003 and in-memory databases have really came to the forefront in the last 5 years.

all of these technologies are enjoying a significant boost in interest in the last couple years thanks to explosive growth in-memory computing in general fueled by 30% yoy price reduction for dram and cheaper flash storage.

despite the fact that i believe that distributed caching is rapidly going away , i still think it’s important to place it in its proper historical and technical context along with data grids and databases.

in-memory distributed caching

the primary use case for caching is to keep frequently accessed data in process memory to avoid constantly fetching this data from disk, which leads to the high availability (ha) of that data to the application running in that process space (hence, “in-memory” caching).

most of the caches were built as distributed in-memory key/value stores that supported a simple set of ‘put’ and ‘get’ operations and optionally some sort of read-through and write-through behavior for writing and reading values to and from underlying disk-based storage such as an rdbms. depending on the product, additional features like acid transactions, eviction policies, replication vs. partitioning, active backups, etc. also became available as the products matured.

these fundamental data management capabilities of distributed caches formed the foundation for the technologies that came later and were built on top of them such as in-memory data grids.

in-memory data grid

the feature of data grids that distinguishes them from distributed caches was their ability to support co-location of computations with data in a distributed context and consequently provided the ability to move computation to data. this capability was the key innovation that addressed the demands of rapidly growing data sets that made moving data to the application layer increasing impractical. most of the data grids provided some basic capabilities to move the computations to the data.

this new and very disruptive capability also marked the start of the evolution of in-memory computing away from simple caching to a bona-fide modern system of record. this evolution culminated in today’s in-memory databases.

in-memory database

the feature that distinguishes in-memory databases over data grids is the addition of distributed mpp processing based on standard sql and/or mapreduce, that allows to compute over data stored in-memory across the cluster.

just as data grids were developed in response to rapidly growing data sets and the necessity to move computations to data, in-memory databases were developed to respond to the growing complexities of data processing. it was no longer enough to have simple key-based access or rpc type processing. distributed sql, complex indexing and mapreduce-based processing across tbs of data in-memory are necessary tools for today’s demanding data processing.

adding distributed sql and/or mapreduce type processing required a complete re-thinking of data grids, as focus has shifted from pure data management to hybrid data and compute management.

full disclosure

gridgain develops an in-memory database product as part of its end-to-end in-memory computing suite .