Storage engines do MariaDB: o banco que tem vários motores debaixo do capô

Uma das coisas que mais me encantam no MariaDB é que ele não é um banco, são vários. A camada SQL (parser, otimizador, usuários) é uma só, mas quem grava os dados no disco é um componente plugável: o storage engine. Você escolhe o motor por tabela. É como ter um carro onde dá para trocar o motor conforme a viagem.

Como funciona

        Aplicação
            │  SQL
            ▼
 ┌──────────────────────────┐
 │ Camada SQL do MariaDB    │  parser, otimizador, cache, privilégios
 └──────────┬───────────────┘
            │  API de storage engine
   ┌────────┼────────┬─────────┬──────────┬────────┐
   ▼        ▼        ▼         ▼          ▼        ▼
 InnoDB    Aria   MyRocks  ColumnStore  Spider    S3 ...

SHOW ENGINES;                               -- o que está disponível
CREATE TABLE t (id INT) ENGINE=InnoDB;      -- escolha por tabela
ALTER TABLE t ENGINE=Aria;                  -- troca (reescreve a tabela)
INSTALL SONAME 'ha_rocksdb';                -- carrega um motor plugável

InnoDB: o padrão, e com razão

Transacional (ACID), bloqueio por linha, MVCC, chaves estrangeiras, recuperação automática após queda. Se você está em dúvida, é InnoDB. 95% das tabelas de qualquer sistema OLTP devem morar aqui.

Aria: o MyISAM que aprendeu a cair de pé

Criado pela própria equipe do MariaDB como sucessor do MyISAM. É crash-safe, rápido em leitura e o MariaDB usa Aria nas tabelas de sistema e nas tabelas temporárias internas. Não é transacional no sentido completo: use para dados de leitura, logs e tabelas auxiliares.

MyRocks: compressão e escrita pesada

Baseado no RocksDB (estrutura LSM). Grava muito bem e comprime muito, ocupando bem menos disco que o InnoDB em muitos cenários. Bom para dados volumosos e com escrita intensa, como eventos e telemetria. Custa algumas funcionalidades e exige tuning próprio.

ColumnStore: análise sem sair do SQL

Armazena por coluna, ideal para agregações em bilhões de linhas. Detalhei em MariaDB ColumnStore.

Spider: sharding transparente

A tabela "existe" num servidor, mas os dados estão espalhados em vários. Veja MariaDB Spider.

S3: dados frios baratos

Move tabelas Aria para um armazenamento compatível com S3, somente leitura. Perfeito para histórico que quase ninguém consulta mas que não pode ser apagado.

ALTER TABLE vendas_2019 ENGINE=S3;   -- vai para o bucket, continua consultável

CONNECT: o canivete suíço

Lê e escreve dados externos como se fossem tabelas: CSV, JSON, XML, outros bancos via ODBC/JDBC. Ótimo em migrações e integrações.

CREATE TABLE precos_csv (sku VARCHAR(20), preco DECIMAL(10,2))
ENGINE=CONNECT TABLE_TYPE=CSV FILE_NAME='/dados/precos.csv' HEADER=1;

Os coadjuvantes úteis

• MEMORY: tudo em RAM, some ao reiniciar. Cache e tabelas de trabalho.
• Archive: compressão alta, só INSERT e SELECT. Logs antigos.
• CSV: a tabela é um arquivo CSV. Troca de dados simples.
• SEQUENCE: gera séries de números sob demanda (SELECT * FROM seq_1_to_10).
• BLACKHOLE: aceita tudo e não guarda nada. Parece piada, mas é útil em topologias de replicação.
• MyISAM: legado. Prefira Aria ou InnoDB.

Como escolher (cola rápida)

Cuidados

• Transação que mistura motores transacionais e não transacionais não é atômica por inteiro.
• Backup e replicação se comportam diferente por motor. Teste o seu.
• Galera Cluster replica apenas InnoDB.

Para saber até onde o InnoDB e os outros aguentam em volume, leia o guia do CTO sobre o MariaDB. Vindo do PostgreSQL? Tem guia de migração. Tudo em /mariadb.

Sobre o autor: Alexandre Almeida é MariaDB Ambassador no Brasil, autor do livro Aprendendo MySQL e trabalha com bancos de dados há mais de 30 anos.

Fontes: MariaDB Knowledge Base: Storage Engines, InnoDB, Aria, MyRocks, S3 Storage Engine, CONNECT, Spider e ColumnStore (mariadb.com/kb). Imagem: ilustração gerada por IA.