Download Ignite 2.16.0
 
Quick Start Guide

USE CASES

View all
MULTI-TIER STORAGE
ESSENTIAL Developer APIs
High-Performance
Computing APIs
Real-Streaming APIs
View all
Project Info
 
Events
 
 
Blog
Apache Ignite

Native Persistence

Scale beyond available memory capacity
and skip memory warm-ups on restarts
Start Coding
Native Persistence
Usually, in-memory caches and databases provide limited persistence capabilities.

For instance, some solutions create a backup copy of
the in-memory data purely for restart purposes.

Ignite persistence doesn’t have any limitations.
Our native persistence behaves like a classic
disk-based database.

Scale beyond memory
capacity

100% of data is always stored on disk. You decide how much memory to allocate to your data.

Just seconds needed
for recovery

Ignite becomes operational from disk instantaneously. There is no need to wait for the data to get preloaded on restarts.

Query in-memory
and on-disk data

If any record is missing in memory, then Ignite reads it from disk. This is supported for all the APIs including SQL.

How it works

The native persistence functions as a distributed, ACID, and SQL-compliant disk-based store. It integrates into the Ignite multi-tier storage as a disk tier.

When the native persistence is enabled, Ignite stores a superset of data on disk and caches as much as it can in memory.

For example

If your application needs to store 200 records in an Ignite cluster and the memory capacity allows caching only 150 records, then all 200 will be stored on disk, out of which 150 will be served from memory while the rest 50 records from disk whenever the application requests them.

Checkpointing And Write-Ahead Logging
Ensure Durability And Consistency Of Data

Committed transactions always survive failures

The cluster can always be recovered to the latest successfully committed transaction

Three-Step Process To Update Your Data
At In-Memory Speed But Not Losing A Bit

01

As soon as the update comes from the application side, a record is updated in memory. Then, the change is added to the write-ahead log (WAL).

The purpose is to propagate updates to disk in the fastest way possible and provide a consistent recovery mechanism that remediates full cluster failures.

02

As the WAL grows, it periodically gets checkpointed to the main storage.

Checkpointing is the process of copying dirty pages from the memory tier to the partition files on disk.

A dirty page is a page that has been updated in memory and appended to the WAL, but has not yet been written to the respective partition file on disk.

03

After a while, the information about updates in WAL can be removed, compressed or moved to archive.

So you can reuse your disk space.

You Decide Which Data To Persist

Toggle a single configuration setting to turn a cluster into a database
that scales across memory and disk

XMLJavaC#/.NET 
 <bean class="org.apache.ignite.configuration.IgniteConfiguration">
    <property name="dataStorageConfiguration">
        <bean class="org.apache.ignite.configuration.DataStorageConfiguration">
            <property name="defaultDataRegionConfiguration">
                <bean class="org.apache.ignite.configuration.DataRegionConfiguration">
                    <property name="persistenceEnabled" value="true"/>
                </bean>
            </property>
        </bean>
    </property>
</bean>
 IgniteConfiguration cfg = new IgniteConfiguration();

DataStorageConfiguration storageCfg = new DataStorageConfiguration();

// Enable Ignite Persistence
storageCfg.getDefaultDataRegionConfiguration().setPersistenceEnabled(true);

// Using the new storage configuration
cfg.setDataStorageConfiguration(storageCfg);
 var cfg = new IgniteConfiguration
{
    DataStorageConfiguration = new DataStorageConfiguration
    {
        DefaultDataRegionConfiguration = new DataRegionConfiguration
        {
            Name = "Default_Region",
            PersistenceEnabled = true
        }
    }
};