For those forced to read Plato’s Republic, you may remember the allegory of the cave, where people are chained to the wall. They can only see shadows of figures and hear voices that echo off the walls. This copy becomes their reality. In reading through the GridGain® and Redis® feature comparison, it’s easy to get lost in the 13 pages of detailed differences. But it’s important that you don’t, because architecturally these are very different products. One manages a copy of the data in memory, and the other is the data in memory. Let’s understand this first. Then I’ll summarize how to look through the details.
Working with a Copy or the Real Data
Redis is a distributed “cache-aside” cache and key-value store, and a good one. It’s used to keep a copy of application data in memory – either to offload reads from a backend system or just to store application data. A developer has to write code to change the app, map any data to the key-value store, and keep the cached data in synch with a backend database. If you’re OK with a cache and managing the challenges of having a copy of the data – and not the real thing, or just having your own key-value store – Redis works well.
GridGain, the commercially available version of Apache® Ignite™, makes the data in memory the real thing, the official system of record for applications. Three core capabilities make this possible. GridGain is an in-memory computing platform that acts as an inline in-memory data grid, supports ANSI-99 SQL including DDL and DML, and supports ACID transactions.
For SQL applications, you can replace the application’s JDBC or ODBC drivers and pass all SQL calls to GridGain. GridGain also supports NoSQL databases including Cassandra and MongoDB. You can also code against GridGain’s API in a host of languages and map to SQL or a key-value store.
Once you’re connected and have done an initial load, GridGain becomes your official data in memory that manages persistence to your backend system or to GridGain’s native persistence. All queries and transactions flow inline to GridGain. Transactions are passed to the backend system. This includes transactions with pessimistic locking, which is what most existing applications do. Upon each successful commit, GridGain is automatically updated and can persist any data to an existing database or its own distributed persistence.
Redis is used differently with transactions. When used as a cache for a third-party database, it shouldn’t get involved. You need to look up the most recent value, then perform the transaction directly against the database, and then manually update the Redis cache. When used as a database, Redis is optimistic only, and only supports transactions within a single shard. It doesn’t support distributed, cross-shard transactions.
Inline, SQL and ACID transaction support combined provide a simpler architecture, with more reliable performance and improved scalability. It’s a more reliable performance because GridGain offloads all queries from the backend system. Redis and other cache-aside cache have to do periodic refreshes, which means a periodic long wait time for data.
GridGain is more scalable because it addresses both of the scalability challenges companies are facing. The first challenge is offloading the increasing transaction and inquiry loads driven by digital business and more self-service. GridGain eliminates the need for cache refreshes, which reduces network traffic and load on the backend system.
But more importantly, GridGain also solves the second scalability challenge, which is how to use all the new “Big Data” to deliver new services and improve experiences or business outcomes. It is becoming impossible to move all this data to the applications each time you need them. The only answer is to collocate processing with the data on the same machine.
GridGain is a distributed, massively parallel processing (MPP) platform that collocates data and processing. Beyond being able to do this as an in-memory data grid, GridGain can also store other data in the same cluster as a distributed database that persists the data with the computing. It can have petabytes of RAM in a cluster and also keep a subset of data in RAM and store much more on disk as well.
Using the Detailed GridGain and Redis Feature Comparison
Now that you understand the overall difference, read through the GridGain® and Redis® feature comparison. The summary explains the differences in how GridGain and Redis are used, and the major differences in capabilities. The large table summarizes the differences across 25 categories of capabilities and over 150 line items of features that companies evaluate when looking at in-memory computing technologies.
In short, Redis is used as a distributed cache and key-value store. Unlike Redis, GridGain is also used as an in-memory data grid, in-memory distributed SQL database, and for many MPP-style applications across transactions, analytics, hybrid transactional/analytical processing (HTAP), streaming analytics, and machine learning.
Unlike Redis, GridGain provides inline third-party database caching and persistence, ANSI-99 SQL, ACID transaction support, and MPP-style computing. It’s also designed to be more of a configure-not-code solution, though it supports coding very well. And it has features that make it more easily scalable and available, including dynamic rebalancing of data across nodes and immediate availability on restart when used with native persistence.
The large table first summarizes the use cases and then goes through detailed sections. If you want to understand the major differences I’d recommend looking at the following sections:
- Use Cases, Third party Database Support, Native Persistence, and Distributed SQL: GridGain has built-in support for SQL, which means it’s very well suited to add speed and scale to existing SQL-based applications or be used as a high volume low latency (distributed) SQL database.
- ACID Compliant Transactions and Locks: Not all ACID is created equal. Make sure you understand your application needs for ACID transactions, especially pessimistic locking.
- Distributed Data Structures: Make sure you understand which data types you need to support. With Redis, you can now add plugins to add new data types, but you need to write those plug-ins or find them.
- Out-of-the-box Integration: Make sure to identify all the technologies you plan to use, to understand the amount of work it will take to put them together across development and lifecycle management.
- Distributed Architecture, Data Rebalancing, Data SnapShots, Distributed Computing: Once you’re comfortable with the functionality, make sure you understand how you’re going to make either technology perform and scale.
If you made it through this blog and Plato’s Republic, you can easily make it through GridGain® and Redis® feature comparison.