This is an automated email from the ASF dual-hosted git repository.
isapego pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/ignite-website.git
The following commit(s) were added to refs/heads/master by this push:
new 5f5b84aee7 IGNITE- 27183 Publish part 2 of AI3 blog series (#290)
5f5b84aee7 is described below
commit 5f5b84aee7d839668956d62326b3b511d0799442
Author: jinxxxoid <[email protected]>
AuthorDate: Tue Dec 2 20:59:45 2025 +0400
IGNITE- 27183 Publish part 2 of AI3 blog series (#290)
---
_src/_blog/apache-ignite-3-architecture-part-2.pug | 281 ++++++++++++++
...ml => apache-ignite-3-architecture-part-2.html} | 417 ++++++++++++---------
blog/apache/index.html | 49 +--
blog/ignite/index.html | 52 +--
blog/index.html | 53 +--
index.html | 1 +
6 files changed, 577 insertions(+), 276 deletions(-)
diff --git a/_src/_blog/apache-ignite-3-architecture-part-2.pug
b/_src/_blog/apache-ignite-3-architecture-part-2.pug
new file mode 100644
index 0000000000..9f2c4795f9
--- /dev/null
+++ b/_src/_blog/apache-ignite-3-architecture-part-2.pug
@@ -0,0 +1,281 @@
+---
+title: "Apache Ignite Architecture Series: Part 2 - Memory-First Architecture:
The Foundation for High-Velocity Event Processing"
+author: "Michael Aglietti"
+date: 2025-12-02
+tags:
+ - apache
+ - ignite
+---
+
+p Traditional databases force a choice: fast memory access or durable storage.
High-velocity applications processing 10,000+ events per second hit a wall when
disk I/O adds 5-15ms to every transaction.
+
+<!-- end -->
+
+p #[strong Apache Ignite eliminates this trade-off with memory-first
architecture that delivers microsecond response times while maintaining full
durability.]
+
+p Event data lives in memory for immediate access. Persistence happens
asynchronously in the background. By moving operations into memory, typical
7–25 ms disk operations drop into the sub-millisecond range while retaining
ACID guarantees.
+
+p #[strong Performance transformation: significant speed improvements with
enterprise durability.]
+
+hr
+br
+|
+h3 The Event Processing Performance Challenge
+
+p #[strong Traditional Database Performance Under Load]
+
+p When applications process high event volumes, disk-based databases create
predictable performance degradation:
+
+p #[strong Single Event Processing (Traditional Database):]
+
+pre
+ code.
+ // Event processing with traditional disk-based database
+ long startTime = System.nanoTime();
+ // 1. Check event cache (memory hit ~50μs, miss ~2ms disk fetch)
+ EventData event = cache.get(eventId);
+ if (event == null) {
+ event = database.query("SELECT * FROM events WHERE id = ?", eventId);
// Disk I/O: 2-10ms
+ cache.put(eventId, event, 300); // Cache update: ~100μs
+ }
+ // 2. Transaction processing (requires disk durability)
+ database.executeTransaction(tx -> { // WAL write + fsync: 5-15ms
+ tx.execute("INSERT INTO event_log VALUES (?, ?)", eventId, timestamp);
+ tx.execute("UPDATE event_counters SET count = count + 1");
+ });
+ long totalTime = System.nanoTime() - startTime;
+ // Result: 7-25ms per event (dominated by disk I/O)
+
+p #[strong Compound Effect at Scale:]
+
+p #[strong Mathematical impossibility at scale:]
+ul
+ li 1,000 events/sec × 15ms avg = 15 seconds processing time needed per second
+ li 5,000 events/sec × 15ms avg = 75 seconds processing time needed per second
+ li 10,000 events/sec × 15ms avg = 150 seconds processing time needed per
second
+
+p #[strong The constraint]: Disk I/O creates a performance ceiling on
throughput regardless of CPU or memory.
+
+hr
+br
+|
+h3 #[strong Memory-First Performance Results]
+
+p #[strong Concrete performance improvement with Apache Ignite memory-first
architecture:]
+
+pre
+ code.
+ // Event processing with memory-first architecture
+ long startTime = System.nanoTime();
+ // All operations happen in memory with microsecond access times
+ try (IgniteClient client =
IgniteClient.builder().addresses("cluster:10800").build()) {
+ client.transactions().runInTransaction(tx -> {
+ // 1. Event data access (memory-based operations)
+ EventData event = eventsTable.get(tx, eventId);
+ // 2. Transaction processing (memory-based with async durability)
+ client.sql().execute(tx, "INSERT INTO event_log VALUES (?, ?)",
eventId, timestamp);
+ client.sql().execute(tx, "UPDATE event_counters SET count = count
+ 1");
+ // Transaction commits immediately to memory
+ // Disk persistence happens asynchronously in background
+ });
+ }
+ long totalTime = System.nanoTime() - startTime;
+ // Result: ~200-500 microseconds per event (20x+ faster than disk-based)
+
+br
+
+p #[strong Real-world performance characteristics:]
+ul
+ li #[strong 10,000 events/sec processing]: 0.5 seconds total vs 150 seconds
with disk I/O
+ li #[strong Peak throughput]: 50,000+ events per sec achievable vs 1,000
events per sec disk limit
+ li #[strong Consistent performance]: Sub-millisecond response times even
during traffic spikes
+ li #[strong Resource utilization]: Memory bandwidth becomes the scaling
factor, not disk I/O waits
+
+hr
+
+h3 Architecture Comparison: Disk-First vs Memory-First
+
+pre.mermaid.
+ flowchart LR
+ subgraph "Disk-First Architecture"
+ App1[Application]
+ Cache1[Memory Cache<br/>Limited Size]
+ DB1[(Disk Database<br/>Primary Storage)]
+ App1 -->|1 - Check Cache| Cache1
+ Cache1 -->|2 - Cache Miss<br/>2-10ms| DB1
+ DB1 -->|3 - Disk Read<br/>5-15ms| Cache1
+ Cache1 -->|4 - Return Data| App1
+ App1 -->|5 - Write Operation| DB1
+ DB1 -->|6 - WAL + fsync<br/>5-15ms| Storage1[Disk Storage]
+ DB1 -->|7 - Invalidate| Cache1
+ end
+
+pre.mermaid.
+ flowchart LR
+ subgraph "Memory-First Architecture"
+ App2[Application]
+ Memory2[Memory Storage<br/>Primary Tier]
+ Async2[Async Persistence<br/>Background Process]
+ App2 -->|1 - All Operations<br/>Memory Speed| Memory2
+ Memory2 -->|2 - Immediate Response<br/><1ms| App2
+ Memory2 -.->|3 - Background<br/>Async Write| Async2
+ Async2 -.->|4 - Durability<br/>No Blocking| Storage2[Disk Storage]
+ end
+
+p #[strong The Fundamental Difference:]
+ul
+ li #[strong Traditional]: Memory serves disk (cache-aside pattern with cache
misses)
+ li #[strong Memory-First]: Disk serves memory (async persistence without
blocking)
+ li #[strong Performance Impact]: 5-15ms disk waits become <1ms memory
operations
+ li #[strong Scalability]: Memory bandwidth scales linearly vs disk I/O
bottlenecks
+
+hr
+br
+
+h3 Memory-First Architecture Principles
+
+h3 Off-Heap Memory Management
+
+p Apache Ignite manages memory regions directly outside the JVM heap to
eliminate garbage collection interference.
+
+p #[strong Performance Benefits:]
+ul
+ li #[strong Predictable Access Times]: No Java GC pauses during event
processing bursts
+ li #[strong Large Memory Utilization]: Event data can consume large amounts
of RAM without heap issues
+ li #[strong Direct Memory Operations]: Reduced serialization/deserialization
overhead
+
+h3 Dual Engine Strategy for Event Requirements
+
+p Apache Ignite provides two storage engines optimized for different
performance requirements:
+
+h4 Memory-Only Storage (aimem)
+ul
+ li #[strong Purpose]: Session data, real-time analytics, temporary
processing results
+ li #[strong Performance]: Memory-speed operations without disk I/O overhead
+ li #[strong Trade-off]: Maximum speed in exchange for volatility
+
+h4 Memory-First Persistence (aipersist)
+ul
+ li #[strong Purpose]: Financial transactions, audit logs, business-critical
events
+ li #[strong Performance]: Memory-speed access with asynchronous persistence
+ li #[strong Trade-off]: Near-memory speed with full durability protection
+
+p #[strong The Evolution Solution]: Instead of choosing between fast caches
and durable databases, you get both performance characteristics in the same
platform based on your specific data requirements.
+
+hr
+br
+|
+h3 Event Processing Performance Characteristics
+
+h3 Memory-First Operations
+
+p Event processing benefits from memory-first operations that reduce
traditional I/O bottlenecks:
+
+p #[strong Architecture Benefits]:
+ul
+ li Events stored in off-heap memory regions for fast access
+ li Multi-version storage enables concurrent read/write operations
+ li Asynchronous checkpointing maintains durability without blocking
processing
+ li B+ tree structures optimize both sequential and random access patterns
+
+p #[strong Performance Advantage]: Event data processing operates on
memory-resident data with minimal serialization overhead.
+
+h3 Asynchronous Persistence for Event Durability
+
+p The checkpoint manager ensures event durability without blocking event
processing.
+
+h4 Background Checkpoint Process
+ul
+ li #[strong Collection Phase]: Identify modified pages during low-activity
periods
+ li #[strong Write Phase]: Persist changes to storage without blocking
ongoing operations
+ li #[strong Coordination]: Manage recovery markers for failure scenarios
+
+p #[strong Key Advantage]: Event processing continues at memory speeds while
persistence happens in background threads.
+
+hr
+br
+|
+h3 B+ Tree Organization for Event Data
+
+p Event-Optimized Data Structures
+
+p Apache Ignite organizes event data through specialized B+ tree variations
optimized for time-series and event-driven access patterns:
+
+p #[strong Event Processing Optimizations]:
+ul
+ li Time-based ordering for streaming access patterns
+ li Range scan optimization for time window queries
+ li Cache-friendly layout for sequential event processing
+ li Multi-version support for consistent read operations
+
+h3 MVCC Integration for Event Consistency
+
+p Event processing maintains consistency through multi-version concurrency
control:
+
+p #[strong Event Processing Benefits]:
+ul
+ li #[strong Consistent Analytics]: Read events at specific points in time
without blocking new events
+ li #[strong High-Frequency Writes]: Events process concurrently with
analytical queries
+ li #[strong Recovery Guarantees]: Event ordering maintained across failures
+
+hr
+br
+
+h3 Performance Characteristics at Event Scale
+
+h3 Memory-First Performance Profile
+
+p #[strong Event Processing Characteristics]:
+ul
+ li #[strong Write Operations]: Events commit to memory efficiently
+ li #[strong Read Operations]: Event queries complete quickly from memory
+ li #[strong Range Scans]: Time-window analytics benefit from memory-resident
data
+ li #[strong Concurrent Processing]: Memory-first design supports mixed
read/write loads
+
+p #[strong Scaling Characteristics]:
+ul
+ li #[strong Linear Memory Scaling]: Performance grows with available memory
+ li #[strong CPU Utilization]: Event processing can saturate multiple cores
+ li #[strong Network Optimization]: Collocated processing eliminates network
bottlenecks
+
+h3 Real-World Event Processing Examples
+
+p #[strong Real-World Performance Impact:]
+
+p #[strong Financial Trading Platforms]: High-frequency trades process at
memory speeds instead of waiting for disk writes. Portfolio updates, risk
calculations, and compliance checks happen concurrently without I/O bottlenecks.
+
+p #[strong IoT Event Processing]: Sensor data ingestion scales to
device-native rates without sampling or queuing delays. Anomaly detection runs
on live data streams rather than batch-processed snapshots.
+
+p #[strong Gaming Backends]: Player actions process immediately while
leaderboards, achievements, and session state update concurrently. No delays
between action and world state changes.
+
+hr
+br
+|
+h2 Foundation for High-Velocity Applications
+br
+p Memory-first architecture creates the performance foundation that makes
high-velocity event processing practical:
+
+p #[strong Eliminates Traditional Bottlenecks]:
+ul
+ li Disk I/O wait times removed from event processing path
+ li Garbage collection interference eliminated through off-heap design
+ li Network serialization overhead reduced through efficient memory management
+
+p #[strong Enables New Application Patterns]:
+ul
+ li Real-time analytics on live transactional event streams
+ li Sub-millisecond response capabilities for high-frequency processing
+ li IoT processing at sensor data rates without data sampling
+
+p #[strong Maintains Enterprise Requirements]:
+ul
+ li ACID transaction guarantees for critical events
+ li Durability through asynchronous checkpointing
+ li Recovery capabilities for event stream continuity
+
+p The memory-first foundation transforms what's possible for high-velocity
applications. Instead of architecting around disk I/O constraints, you can
design for the performance characteristics your business requirements actually
need.
+
+hr
+br
+|
+p #[em Come back next Tuesday for Part 3, where we explain how flexible schema
management lets systems evolve without downtime or complex coordination, and
why these capabilities are essential for high-velocity applications that cannot
afford processing interruptions.]
\ No newline at end of file
diff --git a/blog/ignite/index.html
b/blog/apache-ignite-3-architecture-part-2.html
similarity index 61%
copy from blog/ignite/index.html
copy to blog/apache-ignite-3-architecture-part-2.html
index b632ccfde4..ca19ae087d 100644
--- a/blog/ignite/index.html
+++ b/blog/apache-ignite-3-architecture-part-2.html
@@ -3,16 +3,11 @@
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0,
maximum-scale=1" />
- <title>Entries tagged [ignite]</title>
- <meta property="og:title" content="Entries tagged [ignite]" />
- <link rel="canonical" href="https://ignite.apache.org/blog"; />
- <meta property="og:type" content="article" />
- <meta property="og:url" content="https://ignite.apache.org/blog"; />
- <meta property="og:image" content="/img/og-pic.png" />
+ <title>Apache Ignite Architecture Series: Part 2 - Memory-First
Architecture: The Foundation for High-Velocity Event Processing</title>
<link rel="stylesheet"
href="/js/vendor/hystmodal/hystmodal.min.css?ver=0.9" />
<link rel="stylesheet" href="/css/utils.css?ver=0.9" />
<link rel="stylesheet" href="/css/site.css?ver=0.9" />
- <link rel="stylesheet" href="/css/blog.css?ver=0.9" />
+ <link rel="stylesheet" href="../css/blog.css?ver=0.9" />
<link rel="stylesheet" href="/css/media.css?ver=0.9" media="only screen
and (max-width:1199px)" />
<link rel="icon" type="image/png" href="/img/favicon.png" />
<!-- Matomo -->
@@ -337,195 +332,257 @@
<div class="dropmenu__back"></div>
<header class="hdrfloat hdr__white jsHdrFloatBase"></header>
<div class="container blog">
- <section class="blog__header"><h1>Entries tagged [ignite]</h1></section>
+ <section class="blog__header post_page__header">
+ <a href="/blog/">← Apache Ignite Blog</a>
+ <h1>Apache Ignite Architecture Series: Part 2 - Memory-First
Architecture: The Foundation for High-Velocity Event Processing</h1>
+ <p>
+ December 2, 2025 by <strong>Michael Aglietti. Share in </strong><a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/undefined";>Facebook</a><span>,
</span
+ ><a href="http://twitter.com/home?status=Apache Ignite Architecture
Series: Part 2 - Memory-First Architecture: The Foundation for High-Velocity
Event Processing%20https://ignite.apache.org/blog/undefined";>Twitter</a>
+ </p>
+ </section>
<div class="blog__content">
<main class="blog_main">
<section class="blog__posts">
<article class="post">
- <div class="post__header">
- <h2><a
href="/blog/apache-ignite-3-architecture-part-1.html">Apache Ignite 3
Architecture Series: Part 1 — When Multi-System Complexity Compounds at
Scale</a></h2>
- <div>
- November 25, 2025 by Michael Aglietti. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/apache-ignite-3-architecture-part-1.html";>Facebook</a><span>,
</span
- ><a href="http://twitter.com/home?status=Apache Ignite 3
Architecture Series: Part 1 — When Multi-System Complexity Compounds at
Scale%20https://ignite.apache.org/blog/apache-ignite-3-architecture-part-1.html";>Twitter</a>
- </div>
- </div>
- <div class="post__content">
- <p>
- Apache Ignite 3 shows what really happens once your <em>good
enough</em> multi-system setup starts cracking under high-volume load. This
piece breaks down why the old stack stalls at scale and how a unified,
memory-first
- architecture removes the latency tax entirely.
- </p>
- </div>
- <div class="post__footer"><a class="more"
href="/blog/apache-ignite-3-architecture-part-1.html">↓ Read all</a></div>
- </article>
- <article class="post">
- <div class="post__header">
- <h2><a
href="/blog/schema-design-for-distributed-systems-ai3.html"> Schema Design for
Distributed Systems: Why Data Placement Matters</a></h2>
- <div>
- November 18, 2025 by Michael Aglietti. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/schema-design-for-distributed-systems-ai3.html";>Facebook</a><span>,
</span
- ><a href="http://twitter.com/home?status= Schema Design for
Distributed Systems: Why Data Placement
Matters%20https://ignite.apache.org/blog/schema-design-for-distributed-systems-ai3.html";>Twitter</a>
- </div>
- </div>
- <div class="post__content"><p>Discover how Apache Ignite 3 keeps
related data together with schema-driven colocation, cutting cross-node traffic
and making distributed queries fast, local and predictable.</p></div>
- <div class="post__footer"><a class="more"
href="/blog/schema-design-for-distributed-systems-ai3.html">↓ Read all</a></div>
- </article>
- <article class="post">
- <div class="post__header">
- <h2><a
href="/blog/getting-to-know-apache-ignite-3.html">Getting to Know Apache Ignite
3: A Schema-Driven Distributed Computing Platform</a></h2>
- <div>
- November 11, 2025 by Michael Aglietti. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/getting-to-know-apache-ignite-3.html";>Facebook</a><span>,
</span
- ><a href="http://twitter.com/home?status=Getting to Know
Apache Ignite 3: A Schema-Driven Distributed Computing
Platform%20https://ignite.apache.org/blog/getting-to-know-apache-ignite-3.html";>Twitter</a>
- </div>
- </div>
- <div class="post__content">
- <p>
- Apache Ignite 3 is a memory-first distributed SQL database
platform that consolidates transactions, analytics, and compute workloads
previously requiring separate systems. Built from the ground up, it represents
a complete
- departure from traditional caching solutions toward a
unified distributed computing platform with microsecond latencies and
collocated processing capabilities.
- </p>
- </div>
- <div class="post__footer"><a class="more"
href="/blog/getting-to-know-apache-ignite-3.html">↓ Read all</a></div>
- </article>
- <article class="post">
- <div class="post__header">
- <h2><a href="/blog/whats-new-in-apache-ignite-3-1.html">Apache
Ignite 3.1: Performance, Multi-Language Client Support, and Production
Hardening</a></h2>
- <div>
- November 3, 2025 by Evgeniy Stanilovskiy. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/whats-new-in-apache-ignite-3-1.html";>Facebook</a><span>,
</span
- ><a href="http://twitter.com/home?status=Apache Ignite 3.1:
Performance, Multi-Language Client Support, and Production
Hardening%20https://ignite.apache.org/blog/whats-new-in-apache-ignite-3-1.html";>Twitter</a>
- </div>
- </div>
- <div class="post__content">
- <p>
- Apache Ignite 3.1 improves the three areas that matter most
when running distributed systems: performance at scale, language flexibility,
and operational visibility. The release also fixes hundreds of bugs related to
data
- corruption, race conditions, and edge cases discovered since
3.0.
- </p>
- </div>
- <div class="post__footer"><a class="more"
href="/blog/whats-new-in-apache-ignite-3-1.html">↓ Read all</a></div>
- </article>
- <article class="post">
- <div class="post__header">
- <h2><a href="/blog/whats-new-in-apache-ignite-3-0.html">What's
New in Apache Ignite 3.0</a></h2>
- <div>
- February 24, 2025 by Stanislav Lukyanov. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/whats-new-in-apache-ignite-3-0.html";>Facebook</a><span>,
</span
- ><a href="http://twitter.com/home?status=What's New in
Apache Ignite
3.0%20https://ignite.apache.org/blog/whats-new-in-apache-ignite-3-0.html";>Twitter</a>
- </div>
- </div>
- <div class="post__content">
- <p>
- Apache Ignite 3.0 is the latest milestone in Apache Ignite
evolution that enhances developer experience, platform resilience, and
efficiency. In this article, we’ll explore the key new features and
improvements in Apache
- Ignite 3.0.
- </p>
- </div>
- <div class="post__footer"><a class="more"
href="/blog/whats-new-in-apache-ignite-3-0.html">↓ Read all</a></div>
- </article>
- <article class="post">
- <div class="post__header">
- <h2><a href="/blog/apache-ignite-2-17-0.html">Apache Ignite
2.17 Release: What’s New</a></h2>
- <div>
- February 13, 2025 by Nikita Amelchev. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/apache-ignite-2-17-0.html";>Facebook</a><span>,
</span
- ><a href="http://twitter.com/home?status=Apache Ignite 2.17
Release: What’s
New%20https://ignite.apache.org/blog/apache-ignite-2-17-0.html";>Twitter</a>
- </div>
- </div>
- <div class="post__content">
- <p>
- We are happy to announce the release of <a
href="https://ignite.apache.org/";>Apache Ignite </a>2.17.0! In this latest
version, the Ignite community has introduced a range of new features and
improvements to deliver a more
- efficient, flexible, and future-proof platform. Below, we’ll
cover the key highlights that you can look forward to when upgrading to the new
release.
- </p>
- </div>
- <div class="post__footer"><a class="more"
href="/blog/apache-ignite-2-17-0.html">↓ Read all</a></div>
- </article>
- <article class="post">
- <div class="post__header">
- <h2><a
href="/blog/apache-ignite-net-intel-cet-fix.html">Ignite on .NET 9 and Intel
CET</a></h2>
- <div>
- November 22, 2024 by Pavel Tupitsyn. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/apache-ignite-net-intel-cet-fix.html";>Facebook</a><span>,
</span
- ><a href="http://twitter.com/home?status=Ignite on .NET 9
and Intel
CET%20https://ignite.apache.org/blog/apache-ignite-net-intel-cet-fix.html";>Twitter</a>
- </div>
- </div>
- <div class="post__content">
- <p>Old JDK code meets new Intel security feature, JVM + CLR in
one process, and a mysterious crash.</p>
- <p><a href="https://ptupitsyn.github.io/Ignite-on-NET-9/";>Read
More...</a></p>
- </div>
- </article>
- <article class="post">
- <div class="post__header">
- <h2><a href="/blog/apache-ignite-2-16-0.html">Apache Ignite
2.16.0: Cache dumps, Calcite engine stabilization, JDK 14+ bug fixes</a></h2>
- <div>
- December 25, 2023 by Nikita Amelchev. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/apache-ignite-2-16-0.html";>Facebook</a><span>,
</span
- ><a href="http://twitter.com/home?status=Apache Ignite
2.16.0: Cache dumps, Calcite engine stabilization, JDK 14+ bug
fixes%20https://ignite.apache.org/blog/apache-ignite-2-16-0.html";>Twitter</a>
- </div>
- </div>
- <div class="post__content">
+ <div>
+ <p>Traditional databases force a choice: fast memory access or
durable storage. High-velocity applications processing 10,000+ events per
second hit a wall when disk I/O adds 5-15ms to every transaction.</p>
+ <!-- end -->
+ <p><strong>Apache Ignite eliminates this trade-off with
memory-first architecture that delivers microsecond response times while
maintaining full durability.</strong></p>
<p>
- As of December 25, 2023, <a
href="https://ignite.apache.org/";>Apache Ignite </a>2.16 has been released. You
can directly check the full list of resolved <a
href="https://s.apache.org/j3brc";>Important JIRA tasks </a>but
- let's briefly overview some valuable improvements.
+ Event data lives in memory for immediate access. Persistence
happens asynchronously in the background. By moving operations into memory,
typical 7–25 ms disk operations drop into the sub-millisecond range while
retaining
+ ACID guarantees.
</p>
- <h3 id="cache-dumps">Cache dumps</h3>
- <p>
- Ignite has persistent cache <a
href="https://ignite.apache.org/docs/latest/snapshots/snapshots";>snapshots
</a>and this feature is highly appreciated by Ignite users. This release
introduces another way to make a copy of
- user data - a cache dump.
- </p>
- <p>
- The cache dump is essentially a file that contains all
entries of a cache group at the time of dump creation. Dump is consistent like
a snapshot, which means all entries that existed in the cluster at the moment
of dump
- creation will be included in the dump file. Meta information
of dumped caches and binary meta are also included in the dump.
- </p>
- <p>Main differences from cache snapshots:</p>
+ <p><strong>Performance transformation: significant speed
improvements with enterprise durability.</strong></p>
+ <hr />
+ <br />
+ <h3>The Event Processing Performance Challenge</h3>
+ <p><strong> Traditional Database Performance Under
Load</strong></p>
+ <p>When applications process high event volumes, disk-based
databases create predictable performance degradation:</p>
+ <p><strong>Single Event Processing (Traditional
Database):</strong></p>
+ <pre><code>// Event processing with traditional disk-based
database
+long startTime = System.nanoTime();
+// 1. Check event cache (memory hit ~50μs, miss ~2ms disk fetch)
+EventData event = cache.get(eventId);
+if (event == null) {
+ event = database.query("SELECT * FROM events WHERE id = ?", eventId); //
Disk I/O: 2-10ms
+ cache.put(eventId, event, 300); // Cache update: ~100μs
+}
+// 2. Transaction processing (requires disk durability)
+database.executeTransaction(tx -> { // WAL write + fsync: 5-15ms
+ tx.execute("INSERT INTO event_log VALUES (?, ?)", eventId, timestamp);
+ tx.execute("UPDATE event_counters SET count = count + 1");
+});
+long totalTime = System.nanoTime() - startTime;
+// Result: 7-25ms per event (dominated by disk I/O)
+</code></pre>
+ <p><strong>Compound Effect at Scale:</strong></p>
+ <p><strong>Mathematical impossibility at scale:</strong></p>
<ul>
- <li>Supports in-memory caches that a snapshot feature does
not support.</li>
- <li>Takes up less disk space. The dump contains only the
cache entries as-is.</li>
- <li>Can be used for offline data processing.</li>
+ <li>1,000 events/sec × 15ms avg = 15 seconds processing time
needed per second</li>
+ <li>5,000 events/sec × 15ms avg = 75 seconds processing time
needed per second</li>
+ <li>10,000 events/sec × 15ms avg = 150 seconds processing
time needed per second</li>
</ul>
- </div>
- <div class="post__footer"><a class="more"
href="/blog/apache-ignite-2-16-0.html">↓ Read all</a></div>
- </article>
- <article class="post">
- <div class="post__header">
- <h2><a
href="/blog/apache-ignite-net-dynamic-linq.html">Dynamic LINQ performance and
usability with Ignite.NET and System.Linq.Dynamic</a></h2>
- <div>
- May 22, 2023 by Pavel Tupitsyn. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/apache-ignite-net-dynamic-linq.html";>Facebook</a><span>,
</span
- ><a href="http://twitter.com/home?status=Dynamic LINQ
performance and usability with Ignite.NET and
System.Linq.Dynamic%20https://ignite.apache.org/blog/apache-ignite-net-dynamic-linq.html";>Twitter</a>
- </div>
- </div>
- <div class="post__content">
- <p>Dynamically building database queries can be necessary for
some use cases, such as UI-defined filtering. This can get challenging with
LINQ frameworks like EF Core and Ignite.NET.</p>
- <p><a
href="https://ptupitsyn.github.io/Dynamic-LINQ-With-Ignite/";>Read
More...</a></p>
- </div>
- </article>
- <article class="post">
- <div class="post__header">
- <h2><a href="/blog/apache-ignite-2-13-0.html">Apache Ignite
2.13.0: new Apache Calcite-based SQL engine</a></h2>
- <div>
- April 28, 2022 by Nikita Amelchev. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/apache-ignite-2-13-0.html";>Facebook</a><span>,
</span
- ><a href="http://twitter.com/home?status=Apache Ignite
2.13.0: new Apache Calcite-based SQL
engine%20https://ignite.apache.org/blog/apache-ignite-2-13-0.html";>Twitter</a>
- </div>
- </div>
- <div class="post__content">
+ <p><strong>The constraint</strong>: Disk I/O creates a
performance ceiling on throughput regardless of CPU or memory.</p>
+ <hr />
+ <br />
+ <h3><strong>Memory-First Performance Results</strong></h3>
+ <p><strong>Concrete performance improvement with Apache Ignite
memory-first architecture:</strong></p>
+ <pre><code>// Event processing with memory-first architecture
+long startTime = System.nanoTime();
+// All operations happen in memory with microsecond access times
+try (IgniteClient client =
IgniteClient.builder().addresses("cluster:10800").build()) {
+ client.transactions().runInTransaction(tx -> {
+ // 1. Event data access (memory-based operations)
+ EventData event = eventsTable.get(tx, eventId);
+ // 2. Transaction processing (memory-based with async durability)
+ client.sql().execute(tx, "INSERT INTO event_log VALUES (?, ?)",
eventId, timestamp);
+ client.sql().execute(tx, "UPDATE event_counters SET count = count +
1");
+ // Transaction commits immediately to memory
+ // Disk persistence happens asynchronously in background
+ });
+}
+long totalTime = System.nanoTime() - startTime;
+// Result: ~200-500 microseconds per event (20x+ faster than disk-based)
+</code></pre>
+ <br />
+ <p><strong>Real-world performance characteristics:</strong></p>
+ <ul>
+ <li><strong>10,000 events/sec processing</strong>: 0.5
seconds total vs 150 seconds with disk I/O</li>
+ <li><strong>Peak throughput</strong>: 50,000+ events per sec
achievable vs 1,000 events per sec disk limit</li>
+ <li><strong>Consistent performance</strong>: Sub-millisecond
response times even during traffic spikes</li>
+ <li><strong>Resource utilization</strong>: Memory bandwidth
becomes the scaling factor, not disk I/O waits</li>
+ </ul>
+ <hr />
+ <h3>Architecture Comparison: Disk-First vs Memory-First</h3>
+ <pre class="mermaid">flowchart LR
+ subgraph "Disk-First Architecture"
+ App1[Application]
+ Cache1[Memory Cache<br/>Limited Size]
+ DB1[(Disk Database<br/>Primary Storage)]
+ App1 -->|1 - Check Cache| Cache1
+ Cache1 -->|2 - Cache Miss<br/>2-10ms| DB1
+ DB1 -->|3 - Disk Read<br/>5-15ms| Cache1
+ Cache1 -->|4 - Return Data| App1
+ App1 -->|5 - Write Operation| DB1
+ DB1 -->|6 - WAL + fsync<br/>5-15ms| Storage1[Disk Storage]
+ DB1 -->|7 - Invalidate| Cache1
+ end
+</pre>
+ <pre class="mermaid">flowchart LR
+ subgraph "Memory-First Architecture"
+ App2[Application]
+ Memory2[Memory Storage<br/>Primary Tier]
+ Async2[Async Persistence<br/>Background Process]
+ App2 -->|1 - All Operations<br/>Memory Speed| Memory2
+ Memory2 -->|2 - Immediate Response<br/><1ms| App2
+ Memory2 -.->|3 - Background<br/>Async Write| Async2
+ Async2 -.->|4 - Durability<br/>No Blocking| Storage2[Disk Storage]
+ end
+</pre>
+ <p><strong>The Fundamental Difference:</strong></p>
+ <ul>
+ <li><strong>Traditional</strong>: Memory serves disk
(cache-aside pattern with cache misses)</li>
+ <li><strong>Memory-First</strong>: Disk serves memory (async
persistence without blocking)</li>
+ <li><strong>Performance Impact</strong>: 5-15ms disk waits
become <1ms memory operations</li>
+ <li><strong>Scalability</strong>: Memory bandwidth scales
linearly vs disk I/O bottlenecks</li>
+ </ul>
+ <hr />
+ <br />
+ <h3>Memory-First Architecture Principles</h3>
+ <br />
+ <h3>Off-Heap Memory Management</h3>
+ <p>Apache Ignite manages memory regions directly outside the
JVM heap to eliminate garbage collection interference.</p>
+ <p><strong>Performance Benefits:</strong></p>
+ <ul>
+ <li><strong>Predictable Access Times</strong>: No Java GC
pauses during event processing bursts</li>
+ <li><strong>Large Memory Utilization</strong>: Event data
can consume large amounts of RAM without heap issues</li>
+ <li><strong>Direct Memory Operations</strong>: Reduced
serialization/deserialization overhead</li>
+ </ul>
+ <h3>Dual Engine Strategy for Event Requirements</h3>
+ <p>Apache Ignite provides two storage engines optimized for
different performance requirements:</p>
+ <h4>Memory-Only Storage (aimem)</h4>
+ <ul>
+ <li><strong>Purpose</strong>: Session data, real-time
analytics, temporary processing results</li>
+ <li><strong>Performance</strong>: Memory-speed operations
without disk I/O overhead</li>
+ <li><strong>Trade-off</strong>: Maximum speed in exchange
for volatility</li>
+ </ul>
+ <h4>Memory-First Persistence (aipersist)</h4>
+ <ul>
+ <li><strong>Purpose</strong>: Financial transactions, audit
logs, business-critical events</li>
+ <li><strong>Performance</strong>: Memory-speed access with
asynchronous persistence</li>
+ <li><strong>Trade-off</strong>: Near-memory speed with full
durability protection</li>
+ </ul>
+ <p><strong>The Evolution Solution</strong>: Instead of
choosing between fast caches and durable databases, you get both performance
characteristics in the same platform based on your specific data
requirements.</p>
+ <hr />
+ <br />
+ <h3>Event Processing Performance Characteristics</h3>
+ <h3>Memory-First Operations</h3>
+ <p>Event processing benefits from memory-first operations that
reduce traditional I/O bottlenecks:</p>
+ <p><strong>Architecture Benefits</strong>:</p>
+ <ul>
+ <li>Events stored in off-heap memory regions for fast
access</li>
+ <li>Multi-version storage enables concurrent read/write
operations</li>
+ <li>Asynchronous checkpointing maintains durability without
blocking processing</li>
+ <li>B+ tree structures optimize both sequential and random
access patterns</li>
+ </ul>
+ <p><strong>Performance Advantage</strong>: Event data
processing operates on memory-resident data with minimal serialization
overhead.</p>
+ <h3>Asynchronous Persistence for Event Durability</h3>
+ <p>The checkpoint manager ensures event durability without
blocking event processing.</p>
+ <h4>Background Checkpoint Process</h4>
+ <ul>
+ <li><strong>Collection Phase</strong>: Identify modified
pages during low-activity periods</li>
+ <li><strong>Write Phase</strong>: Persist changes to storage
without blocking ongoing operations</li>
+ <li><strong>Coordination</strong>: Manage recovery markers
for failure scenarios</li>
+ </ul>
+ <p><strong>Key Advantage</strong>: Event processing continues
at memory speeds while persistence happens in background threads.</p>
+ <hr />
+ <br />
+ <h3>B+ Tree Organization for Event Data</h3>
+ <p>Event-Optimized Data Structures</p>
+ <p>Apache Ignite organizes event data through specialized B+
tree variations optimized for time-series and event-driven access patterns:</p>
+ <p><strong>Event Processing Optimizations</strong>:</p>
+ <ul>
+ <li>Time-based ordering for streaming access patterns</li>
+ <li>Range scan optimization for time window queries</li>
+ <li>Cache-friendly layout for sequential event
processing</li>
+ <li>Multi-version support for consistent read operations</li>
+ </ul>
+ <h3>MVCC Integration for Event Consistency</h3>
+ <p>Event processing maintains consistency through
multi-version concurrency control:</p>
+ <p><strong>Event Processing Benefits</strong>:</p>
+ <ul>
+ <li><strong>Consistent Analytics</strong>: Read events at
specific points in time without blocking new events</li>
+ <li><strong>High-Frequency Writes</strong>: Events process
concurrently with analytical queries</li>
+ <li><strong>Recovery Guarantees</strong>: Event ordering
maintained across failures</li>
+ </ul>
+ <hr />
+ <br />
+ <h3>Performance Characteristics at Event Scale</h3>
+ <p>Memory-First Performance Profile</p>
+ <p><strong>Event Processing Characteristics</strong>:</p>
+ <ul>
+ <li><strong>Write Operations</strong>: Events commit to
memory efficiently</li>
+ <li><strong>Read Operations</strong>: Event queries complete
quickly from memory</li>
+ <li><strong>Range Scans</strong>: Time-window analytics
benefit from memory-resident data</li>
+ <li><strong>Concurrent Processing</strong>: Memory-first
design supports mixed read/write loads</li>
+ </ul>
+ <p><strong>Scaling Characteristics</strong>:</p>
+ <ul>
+ <li><strong>Linear Memory Scaling</strong>: Performance
grows with available memory</li>
+ <li><strong>CPU Utilization</strong>: Event processing can
saturate multiple cores</li>
+ <li><strong>Network Optimization</strong>: Collocated
processing eliminates network bottlenecks</li>
+ </ul>
+ <h3>Real-World Event Processing Examples</h3>
+ <p><strong>Real-World Performance Impact:</strong></p>
<p>
- As of April 26, 2022, <a
href="https://ignite.apache.org/";>Apache Ignite</a> 2.13 has been released. You
can directly check the full list of resolved <a
href="https://s.apache.org/x8u49";>Important JIRA tasks</a> but here
- let's briefly overview some valuable improvements.
+ <strong>Financial Trading Platforms</strong>: High-frequency
trades process at memory speeds instead of waiting for disk writes. Portfolio
updates, risk calculations, and compliance checks happen concurrently without
I/O
+ bottlenecks.
</p>
- <h4>This is a breaking change release: The legacy service grid
implementation was removed.</h4>
- <h3 id="new-apache-calcite-based-sql-engine">New Apache
Calcite-based SQL engine</h3>
- <p>We've implemented a new experimental SQL engine based
on Apache Calcite. Now it's possible to:</p>
+ <p><strong>IoT Event Processing</strong>: Sensor data
ingestion scales to device-native rates without sampling or queuing delays.
Anomaly detection runs on live data streams rather than batch-processed
snapshots.</p>
+ <p><strong>Gaming Backends</strong>: Player actions process
immediately while leaderboards, achievements, and session state update
concurrently. No delays between action and world state changes.</p>
+ <hr />
+ <br />
+ <h2>Foundation for High-Velocity Applications</h2>
+ <br />
+ <p>Memory-first architecture creates the performance
foundation that makes high-velocity event processing practical:</p>
+ <p><strong>Eliminates Traditional Bottlenecks</strong>:</p>
+ <ul>
+ <li>Disk I/O wait times removed from event processing
path</li>
+ <li>Garbage collection interference eliminated through
off-heap design</li>
+ <li>Network serialization overhead reduced through efficient
memory management</li>
+ </ul>
+ <p><strong>Enables New Application Patterns</strong>:</p>
<ul>
- <li>Get rid of some <a
href="https://cwiki.apache.org/confluence/display/IGNITE/IEP-37%3A+New+query+execution+engine#IEP37:Newqueryexecutionengine-Motivation";>H2
limitations</a>;</li>
- <li><a
href="https://cwiki.apache.org/confluence/display/IGNITE/IEP-37%3A+New+query+execution+engine#IEP37:Newqueryexecutionengine-Implementationdetails";>Optimize</a>
some query execution.</li>
+ <li>Real-time analytics on live transactional event
streams</li>
+ <li>Sub-millisecond response capabilities for high-frequency
processing</li>
+ <li>IoT processing at sensor data rates without data
sampling</li>
</ul>
- <p>The current H2-based engine has fundamental limitations.
For example:</p>
+ <p><strong>Maintains Enterprise Requirements</strong>:</p>
<ul>
- <li>some queries should be splitted into 2 phases (map
subquery and reduce subquery), but some of them cannot be effectively executed
in 2 phases.</li>
- <li>H2 is a third-party database product with not-ASF
license.</li>
- <li>The optimizer and other internal things are not supposed
to work in a distributed environment.</li>
- <li>It's hard to make Ignite-specific changes to the H2
code, patches are often declined.</li>
+ <li>ACID transaction guarantees for critical events</li>
+ <li>Durability through asynchronous checkpointing</li>
+ <li>Recovery capabilities for event stream continuity</li>
</ul>
+ <p>
+ The memory-first foundation transforms what's possible for
high-velocity applications. Instead of architecting around disk I/O
constraints, you can design for the performance characteristics your business
requirements
+ actually need.
+ </p>
+ <hr />
+ <br />
+ <p>
+ <em
+ >Come back next Tuesday for Part 3, where we explain how
flexible schema management lets systems evolve without downtime or complex
coordination, and why these capabilities are essential for high-velocity
applications
+ that cannot afford processing interruptions.</em
+ >
+ </p>
</div>
- <div class="post__footer"><a class="more"
href="/blog/apache-ignite-2-13-0.html">↓ Read all</a></div>
</article>
- </section>
- <section class="blog__footer">
- <ul class="pagination">
- <li><a class="current" href="/blog/ignite">1</a></li>
- <li><a class="item" href="/blog/ignite/1/">2</a></li>
- <li><a class="item" href="/blog/ignite/2/">3</a></li>
- </ul>
+ <section class="blog__footer">
+ <ul class="pagination post_page">
+ <li><a href="/blog/apache">apache</a></li>
+ <li><a href="/blog/ignite">ignite</a></li>
+ </ul>
+ </section>
</section>
</main>
<aside class="blog__sidebar">
diff --git a/blog/apache/index.html b/blog/apache/index.html
index 8aaa795479..48d4154627 100644
--- a/blog/apache/index.html
+++ b/blog/apache/index.html
@@ -343,15 +343,31 @@
<section class="blog__posts">
<article class="post">
<div class="post__header">
- <h2><a
href="/blog/apache-ignite-3-architecture-part-1.html">Apache Ignite 3
Architecture Series: Part 1 — When Multi-System Complexity Compounds at
Scale</a></h2>
+ <h2><a
href="/blog/apache-ignite-3-architecture-part-2.html">Apache Ignite
Architecture Series: Part 2 - Memory-First Architecture: The Foundation for
High-Velocity Event Processing</a></h2>
+ <div>
+ December 2, 2025 by Michael Aglietti. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/apache-ignite-3-architecture-part-2.html";>Facebook</a><span>,
</span
+ ><a
+ href="http://twitter.com/home?status=Apache Ignite
Architecture Series: Part 2 - Memory-First Architecture: The Foundation for
High-Velocity Event
Processing%20https://ignite.apache.org/blog/apache-ignite-3-architecture-part-2.html";
+ >Twitter</a
+ >
+ </div>
+ </div>
+ <div class="post__content">
+ <p>Traditional databases force a choice: fast memory access or
durable storage. High-velocity applications processing 10,000+ events per
second hit a wall when disk I/O adds 5-15ms to every transaction.</p>
+ </div>
+ <div class="post__footer"><a class="more"
href="/blog/apache-ignite-3-architecture-part-2.html">↓ Read all</a></div>
+ </article>
+ <article class="post">
+ <div class="post__header">
+ <h2><a
href="/blog/apache-ignite-3-architecture-part-1.html">Apache Ignite
Architecture Series: Part 1 - When Multi-System Complexity Compounds at
Scale</a></h2>
<div>
November 25, 2025 by Michael Aglietti. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/apache-ignite-3-architecture-part-1.html";>Facebook</a><span>,
</span
- ><a href="http://twitter.com/home?status=Apache Ignite 3
Architecture Series: Part 1 — When Multi-System Complexity Compounds at
Scale%20https://ignite.apache.org/blog/apache-ignite-3-architecture-part-1.html";>Twitter</a>
+ ><a href="http://twitter.com/home?status=Apache Ignite
Architecture Series: Part 1 - When Multi-System Complexity Compounds at
Scale%20https://ignite.apache.org/blog/apache-ignite-3-architecture-part-1.html";>Twitter</a>
</div>
</div>
<div class="post__content">
<p>
- Apache Ignite 3 shows what really happens once your <em>good
enough</em> multi-system setup starts cracking under high-volume load. This
piece breaks down why the old stack stalls at scale and how a unified,
memory-first
+ Apache Ignite shows what really happens once your <em>good
enough</em> multi-system setup starts cracking under high-volume load. This
piece breaks down why the old stack stalls at scale and how a unified,
memory-first
architecture removes the latency tax entirely.
</p>
</div>
@@ -514,33 +530,6 @@
</div>
<div class="post__footer"><a class="more"
href="/blog/protecting-apache-ignite-from-meltdown.html">↓ Read all</a></div>
</article>
- <article class="post">
- <div class="post__header">
- <h2><a
href="/blog/apache-ignite-essentials-series-for.html">Apache Ignite Essentials:
2-part Webinar Series for Architects and Java Developers</a></h2>
- <div>
- November 17, 2017 by Denis Magda. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/apache-ignite-essentials-series-for.html";>Facebook</a><span>,
</span
- ><a href="http://twitter.com/home?status=Apache Ignite
Essentials: 2-part Webinar Series for Architects and Java
Developers%20https://ignite.apache.org/blog/apache-ignite-essentials-series-for.html";>Twitter</a>
- </div>
- </div>
- <div class="post__content">
- <p class="entryContent">
- We finally made this happen! I’m happy to invite all
of the software architects and engineers out there to a series of webinars that
will introduce you to the fundamental capabilities of in-memory computing
platforms
- such as Apache Ignite.
- </p>
- <p>There will also be a mix of theory and practice. A lot of
code examples are waiting to be shown so that you can apply the theory in
practice right away.</p>
- <p>The series consists of two parts.</p>
- <h3><a
href="https://ignite.apache.org/events.html#in-memory-computing-essentials-architects-and-developers-part-1";
target="_blank">Part 1: Tuesday, November 21, 2017, 11:00am PT / 2:00pm
ET</a></h3>
- To be covered:
- <ul>
- <li>Cluster configuration and deployment.</li>
- <li>Distributed database internals (partitioning,
replication).</li>
- <li>Data processing with key-value APIs.</li>
- <li>Affinity Collocation.</li>
- <li>Data processing with SQL.</li>
- </ul>
- </div>
- <div class="post__footer"><a class="more"
href="/blog/apache-ignite-essentials-series-for.html">↓ Read all</a></div>
- </article>
</section>
<section class="blog__footer">
<ul class="pagination">
diff --git a/blog/ignite/index.html b/blog/ignite/index.html
index b632ccfde4..ffd6dd2db6 100644
--- a/blog/ignite/index.html
+++ b/blog/ignite/index.html
@@ -343,15 +343,31 @@
<section class="blog__posts">
<article class="post">
<div class="post__header">
- <h2><a
href="/blog/apache-ignite-3-architecture-part-1.html">Apache Ignite 3
Architecture Series: Part 1 — When Multi-System Complexity Compounds at
Scale</a></h2>
+ <h2><a
href="/blog/apache-ignite-3-architecture-part-2.html">Apache Ignite
Architecture Series: Part 2 - Memory-First Architecture: The Foundation for
High-Velocity Event Processing</a></h2>
+ <div>
+ December 2, 2025 by Michael Aglietti. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/apache-ignite-3-architecture-part-2.html";>Facebook</a><span>,
</span
+ ><a
+ href="http://twitter.com/home?status=Apache Ignite
Architecture Series: Part 2 - Memory-First Architecture: The Foundation for
High-Velocity Event
Processing%20https://ignite.apache.org/blog/apache-ignite-3-architecture-part-2.html";
+ >Twitter</a
+ >
+ </div>
+ </div>
+ <div class="post__content">
+ <p>Traditional databases force a choice: fast memory access or
durable storage. High-velocity applications processing 10,000+ events per
second hit a wall when disk I/O adds 5-15ms to every transaction.</p>
+ </div>
+ <div class="post__footer"><a class="more"
href="/blog/apache-ignite-3-architecture-part-2.html">↓ Read all</a></div>
+ </article>
+ <article class="post">
+ <div class="post__header">
+ <h2><a
href="/blog/apache-ignite-3-architecture-part-1.html">Apache Ignite
Architecture Series: Part 1 - When Multi-System Complexity Compounds at
Scale</a></h2>
<div>
November 25, 2025 by Michael Aglietti. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/apache-ignite-3-architecture-part-1.html";>Facebook</a><span>,
</span
- ><a href="http://twitter.com/home?status=Apache Ignite 3
Architecture Series: Part 1 — When Multi-System Complexity Compounds at
Scale%20https://ignite.apache.org/blog/apache-ignite-3-architecture-part-1.html";>Twitter</a>
+ ><a href="http://twitter.com/home?status=Apache Ignite
Architecture Series: Part 1 - When Multi-System Complexity Compounds at
Scale%20https://ignite.apache.org/blog/apache-ignite-3-architecture-part-1.html";>Twitter</a>
</div>
</div>
<div class="post__content">
<p>
- Apache Ignite 3 shows what really happens once your <em>good
enough</em> multi-system setup starts cracking under high-volume load. This
piece breaks down why the old stack stalls at scale and how a unified,
memory-first
+ Apache Ignite shows what really happens once your <em>good
enough</em> multi-system setup starts cracking under high-volume load. This
piece breaks down why the old stack stalls at scale and how a unified,
memory-first
architecture removes the latency tax entirely.
</p>
</div>
@@ -489,36 +505,6 @@
<p><a
href="https://ptupitsyn.github.io/Dynamic-LINQ-With-Ignite/";>Read
More...</a></p>
</div>
</article>
- <article class="post">
- <div class="post__header">
- <h2><a href="/blog/apache-ignite-2-13-0.html">Apache Ignite
2.13.0: new Apache Calcite-based SQL engine</a></h2>
- <div>
- April 28, 2022 by Nikita Amelchev. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/apache-ignite-2-13-0.html";>Facebook</a><span>,
</span
- ><a href="http://twitter.com/home?status=Apache Ignite
2.13.0: new Apache Calcite-based SQL
engine%20https://ignite.apache.org/blog/apache-ignite-2-13-0.html";>Twitter</a>
- </div>
- </div>
- <div class="post__content">
- <p>
- As of April 26, 2022, <a
href="https://ignite.apache.org/";>Apache Ignite</a> 2.13 has been released. You
can directly check the full list of resolved <a
href="https://s.apache.org/x8u49";>Important JIRA tasks</a> but here
- let's briefly overview some valuable improvements.
- </p>
- <h4>This is a breaking change release: The legacy service grid
implementation was removed.</h4>
- <h3 id="new-apache-calcite-based-sql-engine">New Apache
Calcite-based SQL engine</h3>
- <p>We've implemented a new experimental SQL engine based
on Apache Calcite. Now it's possible to:</p>
- <ul>
- <li>Get rid of some <a
href="https://cwiki.apache.org/confluence/display/IGNITE/IEP-37%3A+New+query+execution+engine#IEP37:Newqueryexecutionengine-Motivation";>H2
limitations</a>;</li>
- <li><a
href="https://cwiki.apache.org/confluence/display/IGNITE/IEP-37%3A+New+query+execution+engine#IEP37:Newqueryexecutionengine-Implementationdetails";>Optimize</a>
some query execution.</li>
- </ul>
- <p>The current H2-based engine has fundamental limitations.
For example:</p>
- <ul>
- <li>some queries should be splitted into 2 phases (map
subquery and reduce subquery), but some of them cannot be effectively executed
in 2 phases.</li>
- <li>H2 is a third-party database product with not-ASF
license.</li>
- <li>The optimizer and other internal things are not supposed
to work in a distributed environment.</li>
- <li>It's hard to make Ignite-specific changes to the H2
code, patches are often declined.</li>
- </ul>
- </div>
- <div class="post__footer"><a class="more"
href="/blog/apache-ignite-2-13-0.html">↓ Read all</a></div>
- </article>
</section>
<section class="blog__footer">
<ul class="pagination">
diff --git a/blog/index.html b/blog/index.html
index 99128007e9..6d61402395 100644
--- a/blog/index.html
+++ b/blog/index.html
@@ -343,15 +343,31 @@
<section class="blog__posts">
<article class="post">
<div class="post__header">
- <h2><a
href="/blog/apache-ignite-3-architecture-part-1.html">Apache Ignite 3
Architecture Series: Part 1 — When Multi-System Complexity Compounds at
Scale</a></h2>
+ <h2><a
href="/blog/apache-ignite-3-architecture-part-2.html">Apache Ignite
Architecture Series: Part 2 - Memory-First Architecture: The Foundation for
High-Velocity Event Processing</a></h2>
+ <div>
+ December 2, 2025 by Michael Aglietti. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/apache-ignite-3-architecture-part-2.html";>Facebook</a><span>,
</span
+ ><a
+ href="http://twitter.com/home?status=Apache Ignite
Architecture Series: Part 2 - Memory-First Architecture: The Foundation for
High-Velocity Event
Processing%20https://ignite.apache.org/blog/apache-ignite-3-architecture-part-2.html";
+ >Twitter</a
+ >
+ </div>
+ </div>
+ <div class="post__content">
+ <p>Traditional databases force a choice: fast memory access or
durable storage. High-velocity applications processing 10,000+ events per
second hit a wall when disk I/O adds 5-15ms to every transaction.</p>
+ </div>
+ <div class="post__footer"><a class="more"
href="/blog/apache-ignite-3-architecture-part-2.html">↓ Read all</a></div>
+ </article>
+ <article class="post">
+ <div class="post__header">
+ <h2><a
href="/blog/apache-ignite-3-architecture-part-1.html">Apache Ignite
Architecture Series: Part 1 - When Multi-System Complexity Compounds at
Scale</a></h2>
<div>
November 25, 2025 by Michael Aglietti. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/apache-ignite-3-architecture-part-1.html";>Facebook</a><span>,
</span
- ><a href="http://twitter.com/home?status=Apache Ignite 3
Architecture Series: Part 1 — When Multi-System Complexity Compounds at
Scale%20https://ignite.apache.org/blog/apache-ignite-3-architecture-part-1.html";>Twitter</a>
+ ><a href="http://twitter.com/home?status=Apache Ignite
Architecture Series: Part 1 - When Multi-System Complexity Compounds at
Scale%20https://ignite.apache.org/blog/apache-ignite-3-architecture-part-1.html";>Twitter</a>
</div>
</div>
<div class="post__content">
<p>
- Apache Ignite 3 shows what really happens once your <em>good
enough</em> multi-system setup starts cracking under high-volume load. This
piece breaks down why the old stack stalls at scale and how a unified,
memory-first
+ Apache Ignite shows what really happens once your <em>good
enough</em> multi-system setup starts cracking under high-volume load. This
piece breaks down why the old stack stalls at scale and how a unified,
memory-first
architecture removes the latency tax entirely.
</p>
</div>
@@ -489,42 +505,13 @@
<p><a
href="https://ptupitsyn.github.io/Dynamic-LINQ-With-Ignite/";>Read
More...</a></p>
</div>
</article>
- <article class="post">
- <div class="post__header">
- <h2><a href="/blog/apache-ignite-2-13-0.html">Apache Ignite
2.13.0: new Apache Calcite-based SQL engine</a></h2>
- <div>
- April 28, 2022 by Nikita Amelchev. Share in <a
href="http://www.facebook.com/sharer.php?u=https://ignite.apache.org/blog/apache-ignite-2-13-0.html";>Facebook</a><span>,
</span
- ><a href="http://twitter.com/home?status=Apache Ignite
2.13.0: new Apache Calcite-based SQL
engine%20https://ignite.apache.org/blog/apache-ignite-2-13-0.html";>Twitter</a>
- </div>
- </div>
- <div class="post__content">
- <p>
- As of April 26, 2022, <a
href="https://ignite.apache.org/";>Apache Ignite</a> 2.13 has been released. You
can directly check the full list of resolved <a
href="https://s.apache.org/x8u49";>Important JIRA tasks</a> but here
- let's briefly overview some valuable improvements.
- </p>
- <h4>This is a breaking change release: The legacy service grid
implementation was removed.</h4>
- <h3 id="new-apache-calcite-based-sql-engine">New Apache
Calcite-based SQL engine</h3>
- <p>We've implemented a new experimental SQL engine based
on Apache Calcite. Now it's possible to:</p>
- <ul>
- <li>Get rid of some <a
href="https://cwiki.apache.org/confluence/display/IGNITE/IEP-37%3A+New+query+execution+engine#IEP37:Newqueryexecutionengine-Motivation";>H2
limitations</a>;</li>
- <li><a
href="https://cwiki.apache.org/confluence/display/IGNITE/IEP-37%3A+New+query+execution+engine#IEP37:Newqueryexecutionengine-Implementationdetails";>Optimize</a>
some query execution.</li>
- </ul>
- <p>The current H2-based engine has fundamental limitations.
For example:</p>
- <ul>
- <li>some queries should be splitted into 2 phases (map
subquery and reduce subquery), but some of them cannot be effectively executed
in 2 phases.</li>
- <li>H2 is a third-party database product with not-ASF
license.</li>
- <li>The optimizer and other internal things are not supposed
to work in a distributed environment.</li>
- <li>It's hard to make Ignite-specific changes to the H2
code, patches are often declined.</li>
- </ul>
- </div>
- <div class="post__footer"><a class="more"
href="/blog/apache-ignite-2-13-0.html">↓ Read all</a></div>
- </article>
</section>
<section class="blog__footer">
<ul class="pagination">
<li><a class="current" href="/blog/">1</a></li>
<li><a class="item" href="/blog/1/">2</a></li>
<li><a class="item" href="/blog/2/">3</a></li>
+ <li><a class="item" href="/blog/3/">4</a></li>
</ul>
</section>
</main>
diff --git a/index.html b/index.html
index 3405eb06ff..22b633fd10 100644
--- a/index.html
+++ b/index.html
@@ -924,6 +924,7 @@ a(href="https://ignite-summit.org/2025/";,
target="_blank").event-featured__banne
></a>
<script src="/js/vendor/hystmodal/hystmodal.min.js"></script>
<script src="/js/vendor/smoothscroll.js"></script>
+ <script src="/js/vendor/mermaid/mermaid.min.js"></script>
<script src="/js/main.js?ver=0.9"></script>
</body>
</html>
