Skip to content
All articles

Apache Ignite / GridGain: In-Memory Data Grid Fundamentals

Dean Jain

Dean Jain

Senior Staff Software Engineer · Enterprise AI, Data & Cloud Architect

· 5 min read

Apache IgniteIn-MemoryDistributed Systems
---
config:
  theme: neutral
  fontSize: 16
---
flowchart TD
    IG["Apache Ignite<br/>in-memory computing<br/> platform"]:::gov
    IG --> DG["Data Grid<br/>distributed cache + SQL,<br/> ACID"]:::server
    IG --> CG["Compute Grid<br/>distributed MapReduce"]:::obs
    IG --> SG["Service Grid<br/>host services in memory"]:::gate
    classDef gov fill:#FFFFFF,stroke:#333333,stroke-width:1px,color:#111111
    classDef server fill:#F0F0F0,stroke:#333333,stroke-width:1px,color:#111111
    classDef obs fill:#DAE8FC,stroke:#333333,stroke-width:1px,color:#111111
    classDef gate fill:#DCDCDC,stroke:#333333,stroke-width:1px,color:#111111

Figure 1: Ignite isn't one thing it's three grids on a single in-memory cluster: data, compute, and service.

Most people file Apache Ignite under “distributed cache” and move on. That undersells it. Ignite is an in-memory computing platform a NewSQL system offering ACID-compliant distributed transactions that scale, built from three cooperating grids: data, compute, and service. Its defining idea is one worth internalizing for any data-intensive system: instead of hauling data across the network to where your code runs, Ignite lets you send the compute to where the data already lives in memory. Here are the fundamentals.

Summary

  • It’s a platform, not just a cache. Three grids Data (distributed in-memory store + SQL), Compute (distributed MapReduce), and Service (host APIs in memory).
  • NewSQL: distributed, ACID transactions that scale adding nodes stores more data and scales elastically.
  • Bring compute to data. Co-located computations run where the data sits, avoiding the expensive move of data to a separate compute tier.
  • Off-heap by default, with persistence. Ignite stores data off-heap and can persist natively to disk (query memory + disk together) or to an external RDBMS/NoSQL store.
  • Mind memory. Eviction policies, swap space, and expiry are how you keep an in-memory system from OOM-ing.

1. More than a cache: the Data Grid

Start with what Ignite is best known for the Data Grid but see it for what it is: a distributed, transactional in-memory store, not just a key-value cache.

  • It distributes data across nodes in a cluster. A partitioned topology stores more data and scales out; a replicated topology copies data across nodes for high availability. You pick per cache.
  • It supports distributed ACID transactions you can perform multiple cache operations atomically, which a plain cache can’t.
  • It scales elastically add nodes to store more data and increase throughput.
  • It speaks JCache (JSR-107) APIs, and via the SQL Grid you run ANSI-99 SQL (SELECT/INSERT/UPDATE/MERGE/DELETE) directly against the cache so it behaves like a distributed SQL database that happens to live in RAM.

That combination distributed, transactional, SQL-queryable, in-memory is why “cache” undersells it. A cache stores values; the Ignite data grid is closer to a horizontally-scalable in-memory database that you can also use as a cache. And because it’s the foundation the other two grids build on, getting the data layout right (partitioned vs replicated, which data regions) shapes everything above it.

2. Compute Grid: bring the code to the data

The Compute Grid is where Ignite stops being a database and becomes a computing platform. It’s a distributed, in-memory MapReduce / fork-join engine: split a computation into sub-tasks, run them on many nodes in parallel, and aggregate the results cutting overall processing time and scaling throughput.

---
config:
  theme: neutral
  fontSize: 16
---
flowchart LR
    subgraph OLD["Traditional: move data to compute"]
        direction LR
        D1[("Data nodes")]:::server -->|"ship data over network"|CMP["Compute tier"]:::warn
    end
    subgraph IGN["Ignite: move compute to data"]
        direction LR
        T["Send computation closure"]:::gate --> N["Runs ON the node<br/>holding the data"]:::good
    end
    classDef server fill:#FFFFFF,stroke:#333333,stroke-width:1px,color:#111111
    classDef warn fill:#F0F0F0,stroke:#333333,stroke-width:1px,color:#111111
    classDef gate fill:#DAE8FC,stroke:#333333,stroke-width:1px,color:#111111
    classDef good fill:#DCDCDC,stroke:#333333,stroke-width:1px,color:#111111

Figure 2: The core idea instead of shipping data to a compute tier, Ignite ships the computation to the node that holds the data.

The payoff is the collocated computation: Ignite’s peer-class-loading lets you send a computation closure to a remote node, so the work runs where the data is instead of pulling gigabytes across the network to a separate compute cluster. For data-intensive work, moving a few kilobytes of code beats moving terabytes of data and that locality is the single biggest performance lever Ignite gives you.

Two more grids round out the platform:

  • Service Grid deploy a service/API into the cluster and let Ignite manage its lifecycle, high availability, and fault tolerance. Services can read the data grid directly and be invoked from computations, with flexible modes (node/cluster singletons, microservice-style multi-deployment). It’s how you co-locate business logic with data, not just computation.
  • Complex Event Processing (CEP) never-ending, real-time stream processing at scale: capture events from sources (Kafka, JMS, Camel) into caches, process them with Ignite SQL/text/predicate queries and stream transformers, and act by invoking a service or updating an alert. An in-memory streaming engine living right next to your data.

3. Persistence and not running out of memory

“In-memory” raises two fears what if it doesn’t fit in RAM? and what happens on a crash? Ignite answers both.

Persistence. Two modes:

  • Native disk-based persistence Ignite keeps data and indexes in memory and on disk, in the same format, so it runs distributed SQL over the full dataset (memory + disk) and only needs the hot subset in RAM. Because the on-disk and in-memory formats match, no serialization overhead when paging and after a full-cluster restart it’s operational once nodes interconnect (no slow preload).
  • Third-party persistence back it with an RDBMS or NoSQL store. Simpler to bolt onto existing systems, but it pays a serialization/deserialization cost translating between formats, and a cold restart must preload and warm memory first.

Avoiding OOM. Since Ignite is off-heap by default, you manage memory with a few levers:

---
config:
  theme: neutral
  fontSize: 16
---
flowchart TD
    M["Keep memory bounded"]:::gov
    M --> EV["Eviction<br/>off-heap LRU (RANDOM_LRU / 2_LRU)"]:::server
    M --> SW["Swap space<br/>spill RAM  disk"]:::obs
    M --> EX["⏳ Expiry policy<br/>remove entries after a TTL"]:::gate
    classDef gov fill:#FFFFFF,stroke:#333333,stroke-width:1px,color:#111111
    classDef server fill:#F0F0F0,stroke:#333333,stroke-width:1px,color:#111111
    classDef obs fill:#DAE8FC,stroke:#333333,stroke-width:1px,color:#111111
    classDef gate fill:#DCDCDC,stroke:#333333,stroke-width:1px,color:#111111

Figure 3: Three levers to keep an in-memory cluster from OOM-ing eviction, swap space, and expiry.

  • Eviction off-heap LRU policies (RANDOM_LRU, RANDOM_2_LRU) drop cold pages; optional on-heap caching (FIFO/LRU) helps for very hot read data.
  • Swap space spill from RAM to a disk location to avoid OOM when persistence isn’t enabled (note: without persistence, eviction can lose data swap avoids that).
  • Expiry policy expire entries after a set time; expired data is removed from heap/native-persistence/swap.

For throughput, the big wins are operational: use the data streamer for bulk loads (≈10× faster than single-threaded updates), batch jobs and use collection-based cache APIs instead of one-by-one calls, and prefer collocated computations so you keep exploiting data locality.

Why it matters: if you treat Ignite as “a faster Redis,” you’ll use a fraction of it. Its real power is being a unified in-memory platform where data, compute, and services co-locate so you process and serve right where the data lives, with ACID and SQL, optionally persisted to disk. Reach for it when moving data to your compute tier is the bottleneck; the architecture’s whole premise is to stop doing that.

References