trilha

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

Buscar

Busca por título, seção e texto das notas