Clarifying the In-Memory Conundrum
In-Memory Computing has been available in the market since the late 1990s. Some of the first commercial solutions were launched by GigaSpaces in 2000, and later by Tangosol in 2001 (Tangosol was acquired by Oracle in 2007).
The Increase in network speed, computer power, and memory capacity made memory-based solutions a viable way to handle high-performance data-heavy tasks.
The first use cases revolved around Command and Control, and Trading systems. Since then, the industry grew and today many vendors offer in-memory technology, mainly in the Java space but also in .NET, C++, and other programming languages.
Although the technology has been available and ubiquitously deployed, many people still get confused by in-memory computing terminology and the various disciplines it encapsulates including terms like In-Memory Data Grids (IMDG), In-Memory Databases (IMDB) and In-Memory Computing.
Are they one and the same?
The answer is No. So let’s break it down for you.
In-Memory Database
In-Memory Database (IMDB) is a full-featured standalone database management system that primarily relies on RAM (Random Access Memory) for computer data storage. In other words, rather than employing a disk storage mechanism, it uses RAM.
The rationale is simple: The Hard Disk Drive (HDD) which is based on magnetic storage technology first introduced by IBM in 1956 is an order of magnitude slower than RAM. IMDBs are designed to first achieve minimal response time by eliminating the need to access the disk, and second for data scalability.
They are however limited in terms of application scalability. Some IMDBS require customers to rip & replace their existing databases. They may also be limited to the types of data models stored. Depending on how data is stored, which can be a row or columnar store, In-Memory databases can provide a fast response time for write or read-intensive workflows.
In-Memory Data Grid
In-Memory Data Grid (IMDG) is a simple to deploy, highly distributed, and cost-effective solution for accelerating and scaling services and applications.
It is a high throughput and low latency data fabric that minimizes access to high-latency, hard-disk-drive-based or solid-state-drive-based data storage.
The application and the data co-locate in the same memory space, reducing data movement over the network and providing both data and application scalability. Some in-memory data grids actually support any data model which can be directly ingested to the data grid (multimodel store) from real-time data sources or copied from an RDBMS, NoSQL, or other data storage infrastructure into RAM where processing is much faster.
Some data grids also provide a unified API to access data from external databases and data lakes, and in essence expand the data managed to petabytes, while accelerating queries and analytics.
This is a unique capability, and you can read more about accessing external databases.
In-Memory Computing
Gartner states that “the IMDG is a key technology enabler for in-memory computing (IMC), a computing style in which the primary data store for applications (the database of record) is in the central (or main) memory of the (distributed) computing environment running the applications”.
This design is optimized for negligible data access latency, even when large data volumes need to be queried for real-time analytics.
See the following use case with a digital bank for more.
So What’s the Difference?
While In-Memory Data Grids share many of the features of In-Memory Databases, there are important differences.
One significant difference is that with an In-Memory Data Grid you can co-locate the business logic (application) with the data. With an In-Memory Database, the engine running the business logic or models resides on an application (or client) while the data resides on the server-side. This is not semantic. In the latter case, the data must travel over the network, which is significantly slower than running in the same memory space (with the added network overhead).
This also affects the scalability factor. While IMDBs can handle data scalability, In-Memory Data Grids’ distributed design allows complete scalability of both data and application load by simply adding a new node to the cluster.
Other differences have to do with the data type. While IMDBs usually handle structured data, some IMDGs also support semi-structured and unstructured data. And finally, some IMDGs seamlessly integrate with machine and deep learning frameworks.
Image: In-Memory Data Grid Architecture for unlimited scale
Table: Comparing In-Memory Database vs. In-Memory Data Grid vs. GigaSpaces In-Memory Computing Platform
Not all In-Memory Data Grids Are Created Equal
When considering an in-memory data grid, it’s imperative to pay attention to several important features that may differ from one in-memory data grid to another.
Consistency
Some in-memory data grids offer strong consistency which means that read always returns the most updated data. Others only offer eventual consistency, meaning that reading data following an update might return the data prior to the update. Even after a successful write, data may be lost.
Eventual consistency is good for non-critical use cases. However, for critical applications such, booking, ordering, billing or money transfers strong consistency is required.
ACID
ACID (atomicity, consistency, isolation, durability) is a set of database transaction properties intended to guarantee validity even in the event of errors, or power failures.
A sequence of data operations that satisfies the ACID properties is called a transaction.
For example, a transfer of funds from one bank account to another, even involving multiple changes such as debiting one account and crediting another, is a single transaction. Some IMDGs support ACID transactions, some don’t.
Balancing cost and performance
Some in-memory data grids are limited to RAM only, or in other words, they only support hot storage but not warm storage like SSD (Solid State Drive) or cold storage such as cloud object-store. As your data volumes grow, intelligent data life-cycle management that can move data according to customized business logic will accelerate access to data on SSD and external databases, data lakes, and warehouses so that you can balance your cost and performance.
Another way to balance cost and performance is by auto-scaling. With this approach, a cluster can automatically scale up and down based on the workload. This way you only use and pay for the resources that are actually needed, and there is no need for overprovisioning.
The index is yet another main factor to impact performance. Some IMDGs offer only primary key access. This makes them not suitable for users who need to perform complex queries on the data.
Image: Example of tiered storage and integration with external databases
BI and visualization tools
If you plan to use BI tools such as Tableau, make sure your in-memory data grid offers native connectors or support standard database APIs such as JDBC or ODBC.
This has a double benefit: you’ll accelerate report generation, and also enable your BI reports to reflect fresh – operational data for a real-time view and analysis.
SQL
SQL is the de-facto query language of business analysts. If your in-memory data grid has its own proprietary query language, your analysts will need to learn a new language.
But the implications may go beyond just the learning curve. For example, some proprietary query languages don’t support distributed JOIN clauses.
This limits the application’s ability to run complex queries and calculations.
Multi-Model Store
Many data grids are limited to one type of data – key-value or object or document stores. This means that when the need arises to handle other types of data such as semi-structured, unstructured such as text, or images, you will need to deploy and maintain additional platforms that can handle that.
In order to future-proof your technology stack, make sure your data grid solution supports multiple types of data: structured, semi-structured, and unstructured.
Machine Learning and Event-Driven Analytics
In-Memory Data Grids’ fast performance and scale are a perfect combination to power complex real-time machine learning queries. But only if they include a complete framework to support it. Some In-Memory Data Grids come with a complete Spark distribution including ML, SQL, Streaming, and GraphX.
With others, you’ll need to install all these components separately and rely on limited integrations. Including a Spark distribution (rather than just a connector) allows for speed optimization and redundancy.
Predicate pushdown, aggregation pushdown, and column pruning filter and aggregate data to the distributed data store, in lieu of loading all of the data to Spark, thereby increasing resource efficiency and speed.
