Download Ignite

Quick Start Guide

ARCHITECTURAL BACKBONE

Memory-First + MVCC + Distributed Replication

CORE FEATURES

DATA PLACEMENT & PROCESSING

OPERATIONAL EXCELLENCE

View all

PRIMARY USE CASES

ADDITIONAL USE CASES

SUPPORTING PATTERNS

View all

Project Info

ARCHITECTURAL BACKBONE

Memory-First + MVCC + Distributed Replication

CORE FEATURES

DATA PLACEMENT & PROCESSING

OPERATIONAL EXCELLENCE

View all

PRIMARY USE CASES

ADDITIONAL USE CASES

SUPPORTING PATTERNS

Key-Value Store
With Apache Ignite

Direct key-value access patterns across Ignite 2 and Ignite 3

Start Coding

Key-Value Access Patterns

Key-value access is a major pattern in Ignite 2 (Cache API) and a supporting pattern in Ignite 3 (Table API with KeyValueView). Both versions provide direct key-based access without SQL overhead, but use different APIs reflecting their architectural evolution.

Ignite 2 provides the Cache API (IgniteCache) as the primary interface for key-value operations. Ignite 3 provides the Table API with RecordView and KeyValueView for key-value access patterns. Both support partition-aware routing for low-latency operations.

API Evolution

Ignite 3 Table API provides key-value access through RecordView and KeyValueView

Ignite 2: Cache API

Ignite 2 uses the Cache API (IgniteCache) for key-value operations. Supports get, put, remove operations with ACID guarantees. Partition-aware routing enables direct access to data without coordinator overhead. Colocation support through Affinity Key annotation.

Ignite 3: Table API

Ignite 3 provides Table API with RecordView for tuple-based access and KeyValueView for key-value patterns. Schema-driven design with compile-time type safety. Partition-aware routing through colocation keys defined in table schema. Supports same ACID guarantees with improved API design.

Side-By-Side Comparison

Simple Get/Put Operations

Ignite 2: Cache API

// Get cache instance
IgniteCache<Integer, Person> cache =
    ignite.cache("person");

// Put operation
cache.put(1, new Person("John", 30));

// Get operation
Person person = cache.get(1);

// Remove operation
cache.remove(1);

Ignite 3: Table API

// Get KeyValueView from table
KeyValueView<Integer, Person> kvView =
    table.keyValueView(Integer.class, Person.class);

// Put operation
kvView.put(null, 1, new Person("John", 30));

// Get operation
Person person = kvView.get(null, 1);

// Remove operation
kvView.remove(null, 1);

Batch Operations

Ignite 2: Cache API

// Batch put
Map<Integer, Person> batch = new HashMap<>();
batch.put(1, new Person("John", 30));
batch.put(2, new Person("Jane", 25));
cache.putAll(batch);

// Batch get
Set<Integer> keys = Set.of(1, 2);
Map<Integer, Person> results = cache.getAll(keys);

Ignite 3: Table API

// Batch put
Map<Integer, Person> batch = Map.of(
    1, new Person("John", 30),
    2, new Person("Jane", 25)
);
kvView.putAll(null, batch);

// Batch get
Collection<Integer> keys = List.of(1, 2);
Map<Integer, Person> results = kvView.getAll(null, keys);

Common Use Cases

Session Management

Store user session data with direct key-based access. Both versions support partition-aware routing for low-latency session retrieval. Any-node access eliminates sticky sessions. ACID guarantees ensure consistency across replicas.

Reference Data Caching

Cache frequently accessed reference data (product catalogs, configuration settings) with key-value patterns. Direct partition access delivers low-latency lookups. Colocation support enables local joins with related data.

User Profile Lookups

Store user profiles with userId as key for direct access patterns. Partition-aware routing ensures consistent latency across cluster. Both versions support atomic updates to profile data. Memory-first architecture delivers low-latency reads.

Shopping Cart State

Maintain shopping cart state with sessionId as key. Direct key-based access for cart operations without SQL overhead. ACID guarantees ensure cart consistency during checkout. Automatic failover prevents cart data loss.

Key Differences

API Design

Ignite 2 Cache API provides a simpler interface focused on key-value operations. Ignite 3 Table API requires table schema definition upfront but provides compile-time type safety. RecordView offers tuple-based access while KeyValueView provides key-value patterns. Both support same performance characteristics.

Schema Management

Ignite 2 Cache API supports dynamic cache creation without schema definition. Ignite 3 requires table schema definition using SQL DDL before accessing KeyValueView. Schema evolution supported in both versions. Ignite 3 schema-driven design enables better query optimization.