Ignite provides three different modes of cache operation:
LOCAL. A cache mode is configured for each cache. Cache modes are defined in
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 is the most scalable distributed 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.
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, 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 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.
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. --> ... </bean> </property> </bean>
CacheConfiguration cacheCfg = new CacheConfiguration("myCache"); cacheCfg.setCacheMode(CacheMode.PARTITIONED); IgniteConfiguration cfg = new IgniteConfiguration(); cfg.setCacheConfiguration(cacheCfg); // Start Ignite node. Ignition.start(cfg);