MariaDB ColumnStore: banco colunar para análise sem sair do SQL

Num armazém organizado por pedido, montar um pedido é fácil. Mas contar quantas caixas azuis existem exige abrir todos os pedidos. Num armazém organizado por tipo de produto, é só olhar uma prateleira. Isso é armazenamento colunar.

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.

Linha versus coluna

InnoDB (linha)                         ColumnStore (coluna)
[1|Ana  |SP|150.00]                    id:     [1|2|3|...]
[2|Bruno|RJ| 80.00]                    nome:   [Ana|Bruno|Carla|...]
[3|Carla|SP|300.00]                    uf:     [SP|RJ|SP|...]      ← comprime muito
                                       valor:  [150|80|300|...]
SELECT SUM(valor) lê TODAS as colunas  SELECT SUM(valor) lê SÓ a coluna valor

Para OLTP (buscar um cliente, gravar um pedido), linha ganha. Para OLAP (somar, agrupar e filtrar milhões de linhas), coluna ganha de lavada: lê menos disco, comprime melhor e processa em paralelo.

Na prática

-- Pacote: mariadb-plugin-columnstore
CREATE TABLE vendas_fato (
  data_venda DATE,
  loja_id    INT,
  produto_id INT,
  qtd        INT,
  valor      DECIMAL(12,2)
) ENGINE = ColumnStore;

-- Carga em massa (bem mais rápida que INSERT linha a linha)
LOAD DATA LOCAL INFILE '/dados/vendas_2026.csv'
  INTO TABLE vendas_fato FIELDS TERMINATED BY ',';

SELECT loja_id, YEAR(data_venda) ano, SUM(valor) total
  FROM vendas_fato
 GROUP BY loja_id, ano
 ORDER BY total DESC;

A grande sacada: InnoDB e ColumnStore no mesmo servidor, com JOIN entre eles. O cadastro fica em InnoDB, a tabela de fatos em ColumnStore.

Quando não usar

• Muitos UPDATEs e DELETEs pequenos: o ColumnStore não foi feito para isso.
• Consultas que buscam uma linha pela chave: InnoDB é melhor.
• Poucos milhões de linhas: InnoDB com bons índices costuma dar conta.

E no MySQL?

O MySQL Community não tem engine colunar. A Oracle oferece o HeatWave, que é um serviço de nuvem pago. No MariaDB, o ColumnStore é open source e roda na sua máquina.

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

• Tabelas temporais (System Versioning) para viajar no tempo dos dados
• Períodos de aplicação e WITHOUT OVERLAPS para reservas sem conflito
• SEQUENCE, o gerador de números que o AUTO_INCREMENT não consegue ser
• INSERT e DELETE ... RETURNING, uma ida ao banco em vez de duas
• Modo Oracle (SQL_MODE=ORACLE) para migrar PL/SQL com menos dor
• Multi-master síncrono que já vem na caixa
• Banco colunar para análise sem sair do SQL
• Sharding transparente com tabelas distribuídas
• Thread pool gratuito para milhares de conexões
• Busca vetorial com índice HNSW para IA e RAG

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 (corredor de armazém com prateleiras altas organizadas em colunas).