Seu banco de dados é 40x mais lento do que deveria

Suas consultas analíticas provavelmente rodam significativamente mais devagar do que o necessário. Considere uma consulta de agregação em 100 milhões de linhas: com o Postgres, essa operação leva impressionantes 9,7 segundos. O DuckDB, um banco de dados column-store, completa a mesma consulta em apenas 0,24 segundos, demonstrando uma melhoria de velocidade superior a 40x. Essa diferença gritante revela um gargalo arquitetural fundamental inerente a muitos bancos de dados tradicionais.

Bancos de dados relacionais tradicionais como o Postgres são row-stores. Eles organizam os dados em disco por linha, o que significa que uma linha inteira é recuperada do armazenamento, mesmo que uma consulta precise apenas do valor de uma única coluna daquela linha. Para cargas de trabalho analíticas que agregam dados em muitas linhas, mas poucas colunas, esse design força o banco de dados a ler grandes quantidades de dados irrelevantes, desperdiçando largura de banda de I/O e ciclos de CPU valiosos.

Bancos de dados column-store como DuckDB e ClickHouse invertem esse paradigma. Eles armazenam dados agrupados por coluna. Quando uma consulta de agregação tem como alvo uma coluna específica, o banco de dados lê do disco apenas os dados daquela coluna, ignorando completamente todas as outras colunas na tabela. Isso reduz drasticamente a quantidade de dados processados, levando aos ganhos de desempenho observados.

Bancos de dados colunares alcançam sua velocidade impressionante realizando ordens de magnitude menos trabalho. Em vez de escanear cada linha, eles empregam estratégias inteligentes de indexação e metadados para pular dados irrelevantes. Essa eficiência deriva de seu armazenamento orientado a colunas, que agrupa os dados por coluna em vez de linha, otimizando para consultas analíticas que frequentemente agregam subconjuntos de colunas.

O ClickHouse, por exemplo, não indexa linhas individuais; ele depende de uma sparse primary key definida em uma coluna ordenada, como um timestamp. À medida que os dados são ingeridos, eles são classificados e divididos em blocos de tamanho fixo de aproximadamente 8.192 linhas, conhecidos como granules. O ClickHouse armazena apenas o primeiro timestamp de cada granule, criando cerca de 12.000 pequenas notas em memória para um conjunto de dados de 100 milhões de linhas.

Quando uma consulta solicita dados para um período específico, como março, o ClickHouse escaneia rapidamente essas notas em memória, identificando e lendo apenas os granules relevantes do disco. Em nosso benchmark, isso significou ler apenas 1.633 de 12.208 blocos, ignorando mais de 86% do conjunto de dados. O DuckDB usa um truque semelhante e altamente eficaz: ele armazena min/max metadata para cada pedaço de coluna. Isso permite que o DuckDB prove que um pedaço é irrelevante para a consulta — por exemplo, um pedaço que abrange de janeiro a fevereiro — e pule seu conteúdo inteiramente sem ler.

Bancos de dados colunares se destacam em consultas de agregação, mas sua arquitetura introduz compensações significativas para outras operações comuns. Uma consulta de busca pontual (point lookup), que recupera uma única linha por ID, revela esse contraste gritante. Com o Postgres, isso leva apenas 2 milissegundos graças ao seu binary tree index, que navega eficientemente até a página de dados exata contendo a linha solicitada.

O ClickHouse, no entanto, tem dificuldades com tais consultas, registrando 168 milissegundos. Sua sparse primary key, classificada por timestamp e depois por ID, não oferece caminho direto para um ID arbitrário sem escanear todos os 12.208 blocos de dados. Mesmo após localizar a linha, ele deve reconstruir o registro completo abrindo e unindo todos os oito arquivos de coluna, um custo operacional considerável para uma busca aparentemente simples.

Atualizar uma única linha expõe ainda mais a divergência arquitetural. Com o Postgres, uma atualização é concluída em 5 milissegundos, reescrevendo uma linha e atualizando uma entrada de índice. O ClickHouse, por outro lado, leva impressionantes 5,8 segundos para a mesma operação. Isso se deve aos seus immutable data files; modificar um único valor exige a reescrita de todo o arquivo da coluna de receita para aquele bloco de dados afetado.

Essas características de desempenho não são falhas de design, mas especializações inerentes. Bancos de dados orientados a linhas como o Postgres são otimizados para transactional workloads (OLTP), onde inserções, atualizações e consultas frequentes de uma única linha são primordiais. Bancos de dados colunares, por design, priorizam analytical workloads (OLAP), onde consultas agregadas sobre vastos conjuntos de dados predominam, tornando seus pontos fortes e fracos distintos com base no caso de uso.

Existem duas opções colunares distintas para acelerar consultas analíticas: ClickHouse e DuckDB. Embora ambos entreguem ganhos de desempenho impressionantes em relação ao Postgres para operações agregadas, suas filosofias arquiteturais divergem significativamente, ditando aplicações ideais distintas.

O ClickHouse opera como um sistema completo baseado em servidor, construído especificamente para data warehouses de produção. Ele funciona de forma muito semelhante ao Postgres, exigindo uma instância de servidor em execução e suportando acesso simultâneo de múltiplos usuários para ambientes de análise compartilhados e robustos.

O DuckDB, por outro lado, oferece uma experiência de embedded library, semelhante ao SQLite para cargas de trabalho analíticas. Ele é executado no mesmo processo da sua aplicação, armazenando todo o seu banco de dados em um único arquivo no disco, tornando-o ideal para manipulação de dados local e do lado do cliente.

Para um backend de análise escalável e compartilhado que suporte múltiplos usuários e grandes conjuntos de dados, o ClickHouse é a sua arma de escolha. Ele lida com ingestão de alto rendimento e consultas agregadas complexas em petabytes de dados em um ambiente de produção.

Escolha o DuckDB para turbinar a análise de dados local, alimentar aplicações de nó único ou acelerar trabalhos de ETL extremamente rápidos. Sua natureza in-process e banco de dados de arquivo único simplificam a implantação para cientistas de dados individuais ou ferramentas internas de menor escala.

Se você precisa de uma plataforma de análise robusta e multiusuário, ignore o DuckDB. Se suas necessidades se limitam ao processamento local de usuário único, a sobrecarga de servidor do ClickHouse é desnecessária.

Qual é a principal diferença entre um banco de dados colunar e um baseado em linhas?

Um banco de dados baseado em linhas (como o Postgres) armazena todos os dados de um único registro juntos. Um banco de dados colunar (como o ClickHouse) armazena todos os valores de uma única coluna juntos, o que é muito mais eficiente para consultas analíticas.

Quando devo usar um banco de dados colunar?

Use um banco de dados colunar para cargas de trabalho analíticas (OLAP) que envolvem agregar ou filtrar algumas colunas em milhões ou bilhões de linhas. Eles são ideais para dashboards, business intelligence e plataformas de análise.

Por que os bancos de dados colunares são lentos para atualizações de uma única linha?

Seus arquivos de dados são otimizados para ingestão em massa e são frequentemente imutáveis. Atualizar um único valor pode exigir a reescrita de um bloco inteiro grande de um arquivo de coluna, tornando-o muito mais lento do que bancos de dados transacionais.

O DuckDB é um substituto para o Postgres?

Não, eles servem a propósitos primários diferentes. O DuckDB é um banco de dados analítico embarcado (como o SQLite para análise), ideal para análise de dados in-process. O Postgres é um banco de dados transacional de propósito geral (OLTP) projetado para ser um sistema de registro.