Apache Ignite可行性验证：三项核心功能能否实现？

Great question—let’s walk through how Apache Ignite handles each of your three core needs for your POC:

1. SQL Data Insertion (Synergized with Continuous Queries) #

Apache Ignite has full native support for SQL operations, including data insertion. You can insert data using:

• JDBC/ODBC clients
• Ignite’s native APIs (Java, .NET, Python, etc.)
• REST endpoints

When you run an insert like:

INSERT INTO TABLE_1 (id, name) VALUES (1, 'Sample Data');

This operation directly updates Ignite’s in-memory cache (and optionally persistent storage if configured). Critically, these updates are automatically picked up by continuous queries (your second requirement), so there’s built-in synergy—no extra work needed to sync inserted data with your listeners.

2. Continuous Query Listening for Specific SQL JOIN Queries #

Yes, this is completely feasible with Ignite’s Continuous Query feature. Here’s how to approach it for your JOIN scenario (SELECT * FROM TABLE_1 p1 INNER JOIN TABLE_2 p2 ON p1.id = p2.id):

• Listen to relevant caches: Since the JOIN depends on two tables, you’ll need to set up continuous queries on both TABLE_1 and TABLE_2’s underlying caches.
• Filter changes that matter: Use a remote filter to only capture updates that could affect the JOIN result. For example, you can filter entries where the id exists in the other table, or defer the JOIN logic to your local listener.
• Process updates locally: When a change is detected in either cache, your local listener can execute the JOIN query to get the updated combined result, or apply business logic to the changed entries.

A simplified Java code snippet to illustrate:

IgniteCache<Integer, Table1> table1Cache = ignite.cache("TABLE_1");
IgniteCache<Integer, Table2> table2Cache = ignite.cache("TABLE_2");

// Set up continuous query for TABLE_1
ContinuousQuery<Integer, Table1> qry1 = new ContinuousQuery<>();
qry1.setRemoteFilter(entry -> {
    // Optional: Filter entries that have a matching id in TABLE_2
    return table2Cache.containsKey(entry.getKey());
});
qry1.setLocalListener(events -> {
    // Handle updates—execute JOIN or process changed data
    events.forEach(event -> {
        Integer id = event.getKey();
        Table1 p1 = event.getValue();
        Table2 p2 = table2Cache.get(id);
        if (p2 != null) {
            // Process joined pair (p1, p2)
        }
    });
});
table1Cache.query(qry1);

// Repeat similar setup for TABLE_2's cache

Ignite also supports SQL-based filters in continuous queries if you prefer to define the condition via SQL syntax instead of code.

3. External Client SELECT Queries (Synergized with Continuous Queries) #

External clients can absolutely run occasional SELECT queries, and this works seamlessly with your continuous query setup:

• Supported clients: Ignite works with JDBC/ODBC, Python, C#, Node.js, and more—any standard SQL client can connect.
• Real-time data consistency: When your continuous query picks up an update, that change is immediately available to external SELECT queries. Ignite’s in-memory cache ensures low-latency access to the latest data, even if you’re using persistent storage.
• Synergy with continuous queries: There’s no conflict here—continuous queries listen for cache changes, while external queries read directly from the same cache. Both operations use the same data source, so your clients will always see the most up-to-date state.

For example, an external JDBC client can run your exact JOIN query at any time:

SELECT * FROM TABLE_1 p1 INNER JOIN TABLE_2 p2 ON p1.id = p2.id;

And it will return the latest data, including any updates that were just captured by your continuous query listeners.

All three requirements are fully supported by Apache Ignite, so your POC should have no trouble validating these capabilities.

内容的提问来源于stack exchange，提问作者Sunny G