MariaDB Spider Engine: sharding e tabelas federadas

Uma teia de aranha tem um centro e vários pontos de apoio. Você toca no centro e a vibração chega a todos os fios. A engine Spider funciona assim: você consulta o centro e ele busca nos servidores certos.

Este artigo faz parte da série MariaDB além do MySQL: dez recursos que existem no MariaDB e não existem no MySQL Community. Exemplos escritos para MariaDB 11.4 LTS (e 11.7+ quando indicado), comparados com MySQL 8.4 LTS.

O que é a Spider?

Uma storage engine que vem com o MariaDB. Uma tabela Spider não guarda dados: ela aponta para tabelas em outros servidores MariaDB ou MySQL. Combinada com particionamento, cada partição mora num servidor diferente. É sharding feito pelo próprio banco.

                aplicação
                    │  SELECT * FROM pedidos WHERE cliente_id = 42
             ┌──────▼──────┐
             │  nó Spider  │  (sabe que cliente_id 42 está no shard 1)
             └──┬───────┬──┘
        ┌───────▼─┐   ┌─▼───────┐
        │ shard1  │   │ shard2  │
        │ id ímpar│   │ id par  │
        └─────────┘   └─────────┘

Na prática

INSTALL SONAME 'ha_spider';

CREATE SERVER shard1 FOREIGN DATA WRAPPER mysql
  OPTIONS (HOST '10.0.0.21', DATABASE 'loja', USER 'spider', PASSWORD '***', PORT 3306);
CREATE SERVER shard2 FOREIGN DATA WRAPPER mysql
  OPTIONS (HOST '10.0.0.22', DATABASE 'loja', USER 'spider', PASSWORD '***', PORT 3306);

-- Em cada shard existe a tabela real 'pedidos' (InnoDB)
-- No nó Spider:
CREATE TABLE pedidos (
  id         BIGINT,
  cliente_id INT,
  valor      DECIMAL(12,2),
  PRIMARY KEY (id, cliente_id)
) ENGINE = SPIDER COMMENT = 'wrapper "mysql", table "pedidos"'
PARTITION BY HASH (cliente_id) (
  PARTITION p1 COMMENT = 'srv "shard1"',
  PARTITION p2 COMMENT = 'srv "shard2"'
);

SELECT SUM(valor) FROM pedidos;             -- consulta os dois shards
SELECT * FROM pedidos WHERE cliente_id = 42; -- vai direto ao shard certo

Quando faz sentido

Uma tabela que não cabe mais num servidor só.
Consolidar várias bases legadas para consulta unificada.
Distribuir escrita por chave (cliente, região, tenant).

Cuidados

JOINs e agregações entre shards trafegam dados pela rede: modele a chave de particionamento pensando nas consultas.
O nó Spider vira ponto central: tenha redundância.
Transações distribuídas existem (XA), mas custam desempenho.

E no MySQL?

O MySQL tem a engine FEDERATED, que aponta para uma tabela remota, mas sem particionamento entre servidores, sem pushdown inteligente e desativada por padrão. Sharding no MySQL costuma ficar com a aplicação, o ProxySQL ou o Vitess.

A série completa: MariaDB além do MySQL

Ainda decidindo entre os dois? Leia MySQL ou MariaDB: qual é o melhor? e o guia definitivo de MySQL.

Quer dominar a base que os dois compartilham?

MariaDB nasceu do MySQL, e tudo o que é fundamento (modelagem, índices, transações, replicação, otimização) vale para os dois. É isso que eu ensino no livro Aprendendo MySQL: Prática, Teoria, Laboratórios, Desafios e Projetos: 292 páginas, 10 laboratórios guiados, 277 exercícios e 4 desafios com gabarito, e uma máquina virtual pronta para você quebrar (e consertar) à vontade.

Conheça o livro e leia a degustação gratuita.

Bora trocar ideia?

Se este artigo te ajudou (ou te fez discordar, que também vale), me siga no LinkedIn e no Instagram. Lá eu posto bastidores de banco de dados, história da computação e histórias de produção que ninguém conta em curso oficial.

Sobre o autor: Alexandre Almeida atua com bancos de dados há mais de 25 anos, foi instrutor oficial de MySQL e Oracle para mais de 1.000 alunos e escreveu Aprendendo MySQL: Prática, Teoria e Laboratórios.

Fontes: MariaDB Server Documentation (MariaDB Knowledge Base), notas de release do MariaDB Server, MySQL 8.4 Reference Manual. Imagem de capa: ilustração gerada por IA (teia de aranha com gotas de orvalho conectando vários pontos).