Cache distribuído e SQL

Objetivos

Nesta aula você vai:

Configurar caches Ignite com parâmetros de produção
Criar tabelas SQL e executar queries distribuídas
Combinar cache em memória com persistência nativa de forma consciente

Introdução

Um dicionário organiza palavras por ordem alfabética; uma enciclopédia as organiza por conceito, com referências cruzadas. O cache Ignite é o dicionário — acesso rápido por chave. O SQL do Ignite é a enciclopédia — você pergunta "quais autores publicaram mais de três obras antes de 1900?" e o cluster responde sem que sua aplicação Java filtre milhões de objetos em memória.

Esta aula ensina a usar ambas as formas de organização no mesmo cluster — e quando a enciclopédia vale o esforço de manter.

Conteúdo

Configuração de cache

Caches Ignite são criados via API ou configuração XML:

import org.apache.ignite.configuration.CacheConfiguration;
import org.apache.ignite.cache.CacheAtomicityMode;
import org.apache.ignite.cache.CacheMode;

CacheConfiguration<String, Livro> cacheCfg = new CacheConfiguration<>("livros")
  .setCacheMode(CacheMode.PARTITIONED)
  .setBackups(1)
  .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
  .setExpiryPolicy(new ModifiedExpiryPolicy(Duration.ofHours(24)));

IgniteCache<String, Livro> livros = ignite.getOrCreateCache(cacheCfg);

Parâmetro	Opções	Quando usar
`CacheMode`	`PARTITIONED`, `REPLICATED`	Particionado para datasets grandes; replicado para catálogos pequenos lidos por todos
`Backups`	0, 1, 2...	1 é padrão enterprise para tolerância a falha
`AtomicityMode`	`ATOMIC`, `TRANSACTIONAL`	Transacional para operações multi-key consistentes
`ExpiryPolicy`	TTL por criação/modificação/acesso	Sessões, tokens, cache com invalidação temporal

Cache Mode — decisão arquitetural

PARTITIONED — cada chave vive em uma partição; backups em nós distintos:

Dataset 100GB, 3 nós → ~33GB por nó (+ backups)

REPLICATED — cópia completa em cada nó:

Dataset 1GB, 3 nós → 1GB em cada nó (3GB total)

Replicated para tabelas de referência (países, categorias). Partitioned para entidades volumosas (pedidos, eventos).

SQL distribuído — da teoria à prática

Ignite expõe engine SQL compatível com ANSI SQL. Defina tabela sobre cache:

CREATE TABLE livros (
  isbn VARCHAR PRIMARY KEY,
  titulo VARCHAR,
  autor VARCHAR,
  ano INT,
  paginas INT
) WITH "template=partitioned, backups=1";

Inserção e consulta via JDBC ou API:

import org.apache.ignite.cache.query.SqlFieldsQuery;

SqlFieldsQuery query = new SqlFieldsQuery(
  "SELECT autor, COUNT(*) AS total " +
  "FROM livros " +
  "WHERE ano < 1900 " +
  "GROUP BY autor " +
  "HAVING COUNT(*) > 2"
);

try (QueryCursor<List<?>> cursor = ignite.cache("livros")
    .query(query.setDistributedJoins(true))) {
  for (List<?> row : cursor) {
    System.out.println(row.get(0) + ": " + row.get(1) + " obras");
  }
}

Ou via JDBC thin driver:

// jdbc:ignite:thin://127.0.0.1:10800
Connection conn = DriverManager.getConnection(
  "jdbc:ignite:thin://127.0.0.1:10800"
);
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery(
  "SELECT titulo FROM livros WHERE autor = 'Machado de Assis'"
);

Índices e performance SQL

CREATE INDEX idx_autor ON livros (autor);
CREATE INDEX idx_ano ON livros (ano);

Prática	Motivo
Índice em colunas de `WHERE` e `JOIN`	Evita full scan distribuído
`setDistributedJoins(true)` com cautela	Joins entre partições são caros
Colocation de tabelas relacionadas	Join local na mesma partição

Colocation — chaves relacionadas mapeadas para a mesma partição:

CREATE TABLE capitulos (
  id BIGINT PRIMARY KEY,
  livro_isbn VARCHAR,
  numero INT,
  titulo VARCHAR
) WITH "affinity_key=livro_isbn";

Capítulos e livros com mesma affinity key residem no mesmo nó — join sem rede.

Persistência nativa

Sem persistência, restart do cluster perde dados em memória. Com native persistence:

<property name="dataStorageConfiguration">
  <bean class="org.apache.ignite.configuration.DataStorageConfiguration">
    <property name="defaultDataRegionConfiguration">
      <bean class="org.apache.ignite.configuration.DataRegionConfiguration">
        <property name="persistenceEnabled" value="true"/>
        <property name="maxSize" value="10737418240"/> <!-- 10GB -->
      </bean>
    </property>
    <property name="walPath" value="/var/ignite/wal"/>
    <property name="storagePath" value="/var/ignite/storage"/>
  </bean>
</property>

Após ativar, chame ignite.cluster().active(true) e aguarde rebalance.

Camada	Função
RAM (page cache)	Leituras quentes em velocidade de memória
WAL	Durabilidade de escritas — log append-only
Storage (pages em disco)	Dataset maior que RAM

Ignite lê do disco via page cache — datasets de terabytes cabem com latência aceitável para workloads analíticos, não para microsegundos de trading.

SQL sobre dados híbridos

Cenário corporativo: tabela pedidos persistente + cache clientes replicado:

SELECT p.id, c.nome, p.valor
FROM pedidos p
JOIN clientes c ON p.cliente_id = c.id
WHERE p.data > '2025-01-01';

Com colocation e índices, Ignite executa join distribuído. Sem colocation, distributedJoins atravessa rede — monitore latência.

Armadilhas comuns

Full table scan em tabela particionada de bilhões de linhas — sempre indexe
Cache sem TTL em dados que mudam — stale reads silenciosos
Persistence sem SSD — WAL em HDD satura I/O
Transações longas — bloqueiam partições; mantenha curtas
Assumir SQL = PostgreSQL — dialetos e limitações existem; teste queries

Resumo

Caches Ignite configuram modo (partitioned/replicated), backups, atomicidade e TTL
SQL ANSI permite queries ad-hoc e joins sobre dados em cluster — com índices e colocation
Persistência nativa (WAL + pages) estende capacidade além da RAM com durabilidade
Colocation de tabelas relacionadas é crítica para performance de joins distribuídos
SQL em Ignite substitui lógica de filtragem na aplicação, mas exige mesmo rigor de modelagem que bancos relacionais