GridGain Developers Hub
GitHub logo GridGain iso GridGain.com
GridGain Software Documentation

Cache Groups

For each cache deployed in the cluster, there is always overhead: the cache is split into partitions whose state must be tracked on every cluster node.

If Native Persistence is enabled, then for every partition there will be an open file on the disk that GridGain actively writes to and reads from. Thus, the more caches and partitions you have:

  • The more Java heap will be occupied by partition maps. Every cache has its own partition map.

  • The longer it might take for a new node to join the cluster.

  • The longer it might take to initiate rebalancing if a node leaves the cluster.

  • The more partition files will be kept open and the worse the performance of the checkpointing might be.

Usually, you will not spot any of these problems for deployments with dozens or several hundreds of caches. However, when it comes to thousands the impact can be noticeable.

To avoid this impact, consider using cache groups. Caches within a single cache group share various internal structures such as partitions maps, thus boosting topology events processing and decreasing overall memory usage. Note that from the API standpoint, there is no difference whether a cache is a part of a group or not.

Cache groups can be created by setting the groupName property of CacheConfiguration. Here is an example of how to assign caches to a specific group:

<bean class="org.apache.ignite.configuration.IgniteConfiguration">
  <property name="cacheConfiguration">
    <list>
      <!-- Partitioned cache for Persons data. -->
      <bean class="org.apache.ignite.configuration.CacheConfiguration">
        <property name="name" value="Person"/>
        <property name="backups" value="1"/>
        <!-- Group the cache belongs to. -->
        <property name="groupName" value="group1"/>
      </bean>
      <!-- Partitioned cache for Organizations data. -->
      <bean class="org.apache.ignite.configuration.CacheConfiguration">
        <property name="name" value="Organization"/>
        <property name="backups" value="1"/>
        <!-- Group the cache belongs to. -->
        <property name="groupName" value="group1"/>
      </bean>
    </list>
  </property>
</bean>
// Defining cluster configuration.
IgniteConfiguration cfg = new IgniteConfiguration();

// Defining Person cache configuration.
CacheConfiguration personCfg = new CacheConfiguration("Person");

personCfg.setBackups(1);

// Group the cache belongs to.
personCfg.setGroupName("group1");

// Defining Organization cache configuration.
CacheConfiguration orgCfg = new CacheConfiguration("Organization");

orgCfg.setBackups(1);

// Group the cache belongs to.
orgCfg.setGroupName("group1");

cfg.setCacheConfiguration(personCfg, orgCfg);

//Starting the node.
Ignition.start(cfg);
var cfg = new IgniteConfiguration
{
    CacheConfiguration = new[] {
        new CacheConfiguration {
            Name = "Person",
            Backups = 1,
            GroupName = "group1"
        },
        new CacheConfiguration {
            Name = "Organization",
            Backups = 1,
            GroupName = "group1"
        }
    }
};
Ignition.Start(cfg);

In the above example, the Person and Organization caches belong to group1.

The reason for grouping caches is simple — if you decide to group 1000 caches, then you will have 1000x fewer structures that store partitions' data, partition maps, and open partition files.