# Apache Ignite — Distributed In-Memory Computing Platform

> A distributed database and computing platform that combines in-memory speed with disk persistence, providing distributed SQL, key-value storage, and compute grid capabilities.

## Install

Save in your project root:

# Apache Ignite — Distributed In-Memory Computing Platform

## Quick Use
```bash
# Download and start a node
wget https://dlcdn.apache.org/ignite/3.0.0/apache-ignite-3.0.0.zip
unzip apache-ignite-3.0.0.zip
cd apache-ignite-3.0.0
bin/ignite3db start

# Connect via CLI and create a table
bin/ignite3 sql "CREATE TABLE city (id INT PRIMARY KEY, name VARCHAR, population INT)"
bin/ignite3 sql "INSERT INTO city VALUES (1, 'Tokyo', 13960000)"
bin/ignite3 sql "SELECT * FROM city"
```

## Introduction
Apache Ignite is a distributed platform that unifies in-memory caching, SQL querying, key-value access, and distributed computing in a single system. Data is partitioned across cluster nodes and kept in memory for microsecond-level access, with optional disk persistence for durability. Ignite serves as both a distributed cache layer in front of existing databases and a standalone distributed database with full ANSI SQL support.

## What Apache Ignite Does
- Distributes data across cluster nodes with automatic partitioning and rebalancing
- Provides ANSI SQL queries with distributed joins, indexes, and DML support
- Offers key-value, compute grid, and service grid APIs in Java, C#, C++, and Python
- Persists data to disk with write-ahead logging for crash recovery
- Supports ACID transactions across partitions with two-phase commit

## Architecture Overview
Ignite organizes data into caches (tables) that are hash-partitioned across nodes. Each partition has configurable backup copies for fault tolerance. The SQL engine compiles queries into distributed execution plans that push computation to data-owning nodes and merge results at the coordinator. The native persistence layer stores data pages on disk with a WAL for crash recovery, allowing datasets larger than available RAM while keeping hot data in memory.

## Self-Hosting & Configuration
- Start a cluster with the CLI or embed Ignite as a library in Java applications
- Configure caches, replication factor, and memory regions in XML or programmatically
- Enable native persistence with `dataStorageConfiguration` to survive full cluster restarts
- Set up thin client connections for Python, Node.js, or C# access to the cluster
- Use the REST API or control script for monitoring and cluster management

## Key Features
- Co-located compute pushes processing to where data resides, reducing network overhead
- Transparent read-through and write-through integration with RDBMS and NoSQL stores
- Continuous queries notify applications of data changes in real time
- Machine learning library for distributed training directly on in-memory data
- Multi-model access: SQL, key-value, and compute through a unified API

## Comparison with Similar Tools
- **Redis** — single-threaded in-memory store; Ignite is distributed with SQL and compute grid
- **Hazelcast** — similar in-memory grid; Ignite adds full SQL engine and native persistence
- **Apache Spark** — batch/stream processing; Ignite provides mutable in-memory storage and ACID transactions
- **CockroachDB** — distributed SQL on disk; Ignite keeps data in memory for lower latency
- **Memcached** — simple cache with no persistence; Ignite offers SQL, transactions, and disk durability

## FAQ
**Q: Does Ignite require all data to fit in memory?**
A: No. With native persistence enabled, Ignite stores data on disk and caches hot pages in memory, supporting datasets larger than total cluster RAM.

**Q: Can I use Ignite as a cache in front of PostgreSQL?**
A: Yes. Configure a CacheStore with read-through and write-through to PostgreSQL, and Ignite transparently loads and persists data.

**Q: What languages are supported?**
A: Java has the richest API. Thin clients are available for Python, C#, C++, Node.js, and Go with key-value and SQL access.

**Q: How does Ignite handle node failures?**
A: Backup copies on other nodes serve requests for failed partitions. The cluster automatically rebalances data when nodes join or leave.

## Sources
- https://github.com/apache/ignite
- https://ignite.apache.org/docs/latest/

---
Source: https://tokrepo.com/en/workflows/3ca06303-3d5b-11f1-9bc6-00163e2b0d79
Author: AI Open Source