Apache Ignite Documentation

GridGain Developer Hub - Apache Ignitetm

Welcome to the Apache Ignite developer hub run by GridGain. Here you'll find comprehensive guides and documentation to help you start working with Apache Ignite as quickly as possible, as well as support if you get stuck.


GridGain also provides Community Edition which is a distribution of Apache Ignite made available by GridGain. It is the fastest and easiest way to get started with Apache Ignite. The Community Edition is generally more stable than the Apache Ignite release available from the Apache Ignite website and may contain extra bug fixes and features that have not made it yet into the release on the Apache website.


Let's jump right in!


Documentation     Ask a Question     Download


Javadoc     Scaladoc     Examples

Partitioning and Replication

Setup different distribution models, backup copies, and near caches.


Ignite provides three different modes of cache operation: PARTITIONED, REPLICATED, and LOCAL. A cache mode is configured for each cache. Cache modes are defined in CacheMode enumeration.


Data Partitioning Internals

Want to know how Ignite distributes and assigns partitions internally and what happens during the rebalancing? Go to this wiki page for more information.

Partitioned Mode

PARTITIONED mode is the most scalable distributed cache mode. This is also the default cache mode. In this mode, the overall data set is divided equally into partitions and all partitions are split equally between participating nodes, essentially creating one huge distributed store for data. This approach allows you to store as much data as can be fit in the total memory (RAM and disk) available across all nodes. Essentially, the more nodes you have, the more data you can store.

Unlike REPLICATED mode, where updates are expensive because every node in the cluster needs to be updated, with PARTITIONED mode, updates become cheap because only one primary node (and optionally 1 or more backup nodes) need to be updated for every key. However, reads become somewhat more expensive because only certain nodes have the data cached.

In order to avoid extra data movement, it is important to always access the data exactly on the node that has that data cached. This approach is called affinity collocation and is strongly recommended when working with partitioned caches.


Partitioned caches are ideal when working with large data sets and updates are frequent.

The picture below illustrates a simple view of a partitioned cache. Essentially we have key A assigned to a node running in JVM1, key B assigned to a node running in JVM3, etc...

See configuration below for an example on how to configure cache mode.

Replicated Mode

In REPLICATED mode, all the data is replicated to every node in the cluster. This cache mode provides the utmost availability of data as it is available on every node. However, in this mode every data update must be propagated to all other nodes which can impact the performance and scalability.

In Ignite, replicated caches are implemented in a way similar to partitioned caches where every key has a primary copy and is also backed up on all other nodes in the cluster. For example, in the diagram below, the node running in JVM1 is a primary node for key A, but it also stores backup copies for all other keys as well (B, C, D).

As the same data is stored on all cluster nodes, the size of a replicated cache is limited by the amount of memory (RAM and disk) available on the node. This mode is ideal for scenarios where cache reads are a lot more frequent than cache writes, and data sets are small. If your system does cache lookups over 80% of the time, then you should consider using REPLICATED cache mode.


Replicated caches should be used when data sets are small and updates are infrequent.

Local Mode

LOCAL mode is the most light weight mode of cache operation, as no data is distributed to other cache nodes. It is ideal for scenarios where data is either read-only, or can be periodically refreshed at some expiration frequency. It also works very well with read-through behavior where data is loaded from persistent storage on misses. Other than distribution, local caches still have all the features of a distributed cache, such as automatic data eviction, expiration, disk swapping, data querying, and transactions.

Like other cache modes, local caches are started and stopped cluster-wide. If you destroy a local cache on one node, it will be destroyed on all nodes.


Cache modes are configured for each cache by setting the cacheMode property of CacheConfiguration like so:

<bean class="org.apache.ignite.configuration.IgniteConfiguration">
    <property name="cacheConfiguration">
        <bean class="org.apache.ignite.configuration.CacheConfiguration">
            <!-- Set a cache name. -->
            <property name="name" value="cacheName"/>
            <!-- Set cache mode. -->
            <property name="cacheMode" value="PARTITIONED"/>
            <!-- Other cache configurations. -->
CacheConfiguration cacheCfg = new CacheConfiguration("myCache");


IgniteConfiguration cfg = new IgniteConfiguration();


// Start Ignite node.

Updated 6 months ago

Partitioning and Replication

Setup different distribution models, backup copies, and near caches.

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.