maglietti commented on code in PR #282:
URL: https://github.com/apache/ignite-website/pull/282#discussion_r2510781391
##########
_src/_blog/getting-to-know-apache-ignite-3.pug:
##########
@@ -0,0 +1,386 @@
+---
+title: "Getting to Know Apache Ignite 3: A Schema-Driven Distributed Computing
Platform"
+author: "Michael Aglietti"
+date: 2025-11-11
+tags:
+ - apache
+ - ignite
+---
+
+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 over four years of
development, it represents a complete departure from traditional caching
solutions toward a unified distributed computing platform with microsecond
latencies and collocated processing capabilities.
Review Comment:
Please remove "over four years of development". I is unnecessary.
##########
_src/_blog/getting-to-know-apache-ignite-3.pug:
##########
@@ -0,0 +1,386 @@
+---
+title: "Getting to Know Apache Ignite 3: A Schema-Driven Distributed Computing
Platform"
+author: "Michael Aglietti"
+date: 2025-11-11
+tags:
+ - apache
+ - ignite
+---
+
+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 over four years of
development, it represents a complete departure from traditional caching
solutions toward a unified distributed computing platform with microsecond
latencies and collocated processing capabilities.
+
+<!-- end -->
+
+p
+ strong Forget everything you knew about Apache Ignite.
+ | Version 3.0 is a complete architectural rewrite that transforms Ignite
from a caching platform into a memory-first distributed computing platform with
microsecond latencies and collocated processing.
+
+h3 Architectural Foundation: Schema-Driven Design
+
+p The core architectural shift in Ignite 3 is that your schema becomes the
foundation for data placement, query optimization, and compute job scheduling.
Instead of managing separate systems with different data models, you define
your schema once and it drives everything.
+
+pre
+ code.
+ // Unified platform connection
+ IgniteClient ignite = IgniteClient.builder()
+ .addresses("node1:10800", "node2:10800", "node3:10800")
+ .build();
+
+p Schema definitions use Java annotations to specify colocation strategies,
storage profiles, and indexing:
Review Comment:
I think that this was intended to be a note.
##########
_src/_blog/getting-to-know-apache-ignite-3.pug:
##########
@@ -0,0 +1,386 @@
+---
+title: "Getting to Know Apache Ignite 3: A Schema-Driven Distributed Computing
Platform"
+author: "Michael Aglietti"
+date: 2025-11-11
+tags:
+ - apache
+ - ignite
+---
+
+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 over four years of
development, it represents a complete departure from traditional caching
solutions toward a unified distributed computing platform with microsecond
latencies and collocated processing capabilities.
+
+<!-- end -->
+
+p
+ strong Forget everything you knew about Apache Ignite.
+ | Version 3.0 is a complete architectural rewrite that transforms Ignite
from a caching platform into a memory-first distributed computing platform with
microsecond latencies and collocated processing.
+
+h3 Architectural Foundation: Schema-Driven Design
+
+p The core architectural shift in Ignite 3 is that your schema becomes the
foundation for data placement, query optimization, and compute job scheduling.
Instead of managing separate systems with different data models, you define
your schema once and it drives everything.
+
+pre
+ code.
+ // Unified platform connection
+ IgniteClient ignite = IgniteClient.builder()
+ .addresses("node1:10800", "node2:10800", "node3:10800")
+ .build();
+
+p Schema definitions use Java annotations to specify colocation strategies,
storage profiles, and indexing:
+
+p
+ strong Schema Creation:
+ | Ignite 3 supports three approaches for schema creation:
+ul
+ li
+ strong SQL DDL
+ | - Traditional
+ code CREATE TABLE
+ | statements
+ li
+ strong Java Annotations API
+ | - POJO markup with
+ code @Table
+ | ,
+ code @Column
+ | , etc.
+ li
+ strong Java Builder API
+ | - Programmatic
+ code TableDefinition.builder()
+ | approach
+
+p We use the Java Annotations API in this blog for their compile-time type
safety and clear colocation syntax.
+
+pre
+ code.
+ @Table(zone = @Zone(value = "MusicStore", storageProfiles = "default"))
+ public class Artist {
+ @Id
+ private Integer ArtistId;
+
+ @Column(value = "Name", length = 120, nullable = false)
+ private String Name;
+
+ // Constructors, getters, setters...
+ }
+
+ @Table(
+ zone = @Zone(value = "MusicStore", storageProfiles = "default"),
+ colocateBy = @ColumnRef("ArtistId"),
+ indexes = @Index(value = "IFK_AlbumArtistId", columns = {
+ @ColumnRef("ArtistId") })
+ )
+ public class Album {
+ @Id
+ private Integer AlbumId;
+
+ @Id
+ private Integer ArtistId;
+
+ @Column(value = "Title", length = 160, nullable = false)
+ private String Title;
+
+ // Constructors, getters, setters...
+ }
+
+p The
+ code colocateBy
+ | annotation ensures that albums are stored on the same nodes as their
corresponding artists, eliminating distributed join overhead and enabling local
processing.
+
+h3 Multiple APIs, Single Schema
+
+p Ignite 3 provides different API views into the same schema, eliminating
impedance mismatch between operational and analytical workloads:
+
+pre
+ code.
+ // RecordView for structured operations
+ RecordView<Artist> artists = ignite.tables()
+ .table("Artist")
+ .recordView(Artist.class);
+
+ // KeyValueView for high-performance access patterns
+ KeyValueView<Long, Album> albums = ignite.tables()
+ .table("Album")
+ .keyValueView(Long.class, Album.class);
+
+ // SQL for analytics using Apache Calcite engine
+ SqlStatement analytics = ignite.sql()
+ .statementBuilder()
+ .query("SELECT a.Name, COUNT(al.AlbumId) as AlbumCount " +
+ "FROM Artist a JOIN Album al ON a.ArtistId = al.ArtistId " +
+ "GROUP BY a.Name");
+
+ // Collocated compute jobs
+ ComputeJob<String> job = ComputeJob.colocated("Artist", 42,
+ RecommendationJob.class);
+ JobExecution<String> recommendation = ignite.compute()
+ .submit(ignite.clusterNodes(), job, "rock");
+
+p This approach eliminates the typical data serialization and movement
overhead between different systems while maintaining type safety and schema
evolution capabilities.
+
+blockquote
+ p This represents a fundamental architectural shift from Ignite 2.x, which
treated everything as key-value operations in a cache. Ignite 3 puts an
evolvable schema first and uses memory-centric storage to deliver microsecond
latencies for all operations, not just cache hits.
Review Comment:
Replace:
"...which treated everything as key-value operations in a cache."
With:
"...that accessed data as key-value operations using the cache API."
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
