Tecnologias/02 - Bancos de Dados/04 - Colunares/02 - DuckDB2 min
DuckDB
Definição
DuckDB é um banco relacional com SQL, armazenamento colunar e execução vetorizada, voltado a consultas analíticas. Pode ser incorporado à aplicação: no modo in-process, o motor funciona dentro do processo que o utiliza, sem exigir um servidor separado.
Isso permite consultar dados em scripts, notebooks e aplicações locais. O mesmo motor pode ser usado pela linha de comando ou por interfaces de linguagens como Python. Referência: características do DuckDB.
Memória, arquivo e dados externos
| Forma de uso | Onde estão os dados |
|---|---|
| Banco em memória | Estado temporário da instância |
| Banco persistente | Tabelas e catálogo em um arquivo de banco |
| Consulta de Parquet | Arquivos externos lidos pelo motor, sem importação obrigatória |
Persistir tabelas no formato do DuckDB e consultar um Parquet são operações diferentes. Uma conexão em memória também pode ler arquivos persistentes externos. Referência: conexões.
Exemplo SQL
CREATE TABLE vendas (
categoria VARCHAR,
valor DECIMAL(10, 2)
);
INSERT INTO vendas VALUES
('livros', 40.00),
('livros', 60.00),
('jogos', 150.00);
SELECT categoria, SUM(valor) AS total
FROM vendas
GROUP BY categoria
ORDER BY categoria;
O resultado contém jogos = 150.00 e livros = 100.00. A agregação resume várias linhas
por categoria; esse padrão é típico de análise de dados.
Transações e concorrência
DuckDB oferece transações, com BEGIN, COMMIT e ROLLBACK. No acesso direto ao arquivo
em modo in-process, o modelo documentado permite um processo com leitura e escrita,
ou vários processos apenas leitores. Dentro do processo escritor, múltiplas threads
podem trabalhar, com conflitos tratados pelo controle de concorrência.
Modos remotos têm arquitetura e requisitos próprios; não se deve confundi-los com vários processos abrindo diretamente o mesmo arquivo para escrever. Referências: transações e concorrência.
Aprofundamento aplicado
Um motor dentro do processo compartilha seu orçamento
Ao usar DuckDB em um script ou aplicação, a consulta disputa CPU e memória com o próprio programa. Buscar todo o resultado para uma lista de objetos pode duplicar representações e consumir mais RAM do que manter o resultado no motor ou exportá-lo diretamente.
Cenário: um relatório produz dez milhões de linhas. Calcular a agregação em SQL antes de transferir o resultado costuma reduzir o volume que a linguagem hospedeira precisa materializar. Se o objetivo é arquivo, considere exportar o resultado pelo motor.
Escolher o ciclo de vida do arquivo
Para acesso direto ao arquivo, o modelo de concorrência precisa ser respeitado. Vários processos escritores independentes exigem outra arquitetura suportada; abrir o mesmo caminho a partir de muitos workers não equivale a um servidor de banco. Referência: concorrência.
Exercício: implemente um relatório que devolve apenas totais por categoria e outro que transfere todas as linhas para somar na aplicação. Resultado esperado: compare memória do processo e bytes transferidos, além do tempo da consulta.
Relacionado: 2. Armazenamento Colunar e Execução no DuckDB · 3. Parquet e S3 com DuckDB.
Parte de DuckDB