Por que o PostgreSQL é Lento para Analytics (e Como Resolver)

Seu dashboard está lento? Entenda por que bancos tradicionais sofrem com Big Data e aprenda a usar o ClickHouse para processar bilhões de linhas em milissegundos.

Você construiu sua API em Go, conectou ao PostgreSQL e tudo funciona perfeitamente. Os usuários cadastram-se, compram produtos e o sistema voa.

Mas aí, o seu chefe pede um Dashboard de Analytics. Ele quer saber: “Qual a média de vendas por hora nos últimos 5 anos, filtrado por região?”.

Você escreve a query SQL. Roda. E espera… espera… 10 segundos… 30 segundos… O banco trava. A CPU vai a 100%.

O que aconteceu? O seu PostgreSQL quebrou? Não. Você apenas tentou usar um martelo para apertar um parafuso.

Bem-vindo ao mundo do ClickHouse e do armazenamento colunar. Hoje, vou te ensinar a ferramenta que empresas como Uber, Spotify e Cloudflare usam para processar petabytes de dados em milissegundos, e como ela pode salvar a performance do seu projeto.

O Problema: Linhas vs. Colunas (OLTP vs. OLAP)

Para entender o ClickHouse, precisamos entender por que o PostgreSQL (e MySQL, SQL Server) é “lento” para relatórios.

O PostgreSQL é um banco OLTP (Online Transaction Processing). Ele é orientado a LINHAS. Imagine uma planilha do Excel. Quando o Postgres grava dados no disco, ele grava a linha inteira do usuário “Thiago” junta (ID, Nome, Email, Idade, Endereço).

• Vantagem: É super rápido para encontrar uma pessoa específica (SELECT * FROM users WHERE id = 1).
• Desvantagem: Para somar a “Idade” de todos os usuários, o banco precisa ler a linha inteira de todo mundo, carregar dados inúteis (como o Endereço) para a memória, só para pegar a idade. É um desperdício enorme de I/O.

O ClickHouse é um banco OLAP (Online Analytical Processing). Ele é orientado a COLUNAS. Ele grava todos os “Nomes” juntos num arquivo, todas as “Idades” noutro, e assim por diante.

• Vantagem: Para somar as idades, ele vai direto no arquivo de idades. Ele ignora o resto. Ele lê apenas o que precisa.
• Resultado: Consultas que levam minutos no Postgres levam milissegundos no ClickHouse.

O Que é o ClickHouse?

O ClickHouse é um banco de dados open-source, criado pela Yandex, focado em velocidade insana para leitura e agregação de dados.

Ele não serve para ser o banco principal da sua aplicação (onde você guarda o perfil do usuário). Ele serve para ser o cérebro dos seus relatórios, logs e métricas.

As 3 Magias do ClickHouse:

1. Armazenamento Colunar: Como explicado acima.
2. Compressão Agressiva: Como dados similares ficam juntos (ex: uma coluna cheia de datas iguais), ele comprime muito bem. 1TB de dados no Postgres pode virar 100GB no ClickHouse.
3. Processamento Vetorial: Ele usa instruções modernas da CPU (SIMD) para processar blocos de dados de uma vez só, não linha por linha.

Tutorial: Rodando o ClickHouse em 5 Minutos

Vamos subir uma instância e ver a mágica acontecer. A forma mais fácil é via Docker.

1. Instalação (Docker)

Bash

docker run -d --name clickhouse-server --ulimit nofile=262144:262144 -p 8123:8123 -p 9000:9000 clickhouse/clickhouse-server

Agora, vamos entrar no cliente do banco:

Bash

docker exec -it clickhouse-server clickhouse-client

2. Criando uma Tabela (A Engine MergeTree)

No Postgres, você só faz CREATE TABLE. No ClickHouse, você precisa escolher a Engine. A mais famosa e usada é a MergeTree.

SQL

CREATE TABLE acessos_site (
    id UInt64,
    url String,
    usuario_id UInt32,
    data_acesso DateTime
) ENGINE = MergeTree()
ORDER BY (data_acesso, url);

Nota do Mentor: O ORDER BY aqui não é só para ordenar a saída. É ele que define como o ClickHouse cria o índice primário esparso. É obrigatório na MergeTree.

3. Inserindo Milhões de Dados (Simulação)

O ClickHouse adora “lotes” (batches). Nunca insira linha por linha (INSERT INTO...). Insira milhares de uma vez. Vamos usar uma função geradora para criar 1 milhão de linhas falsas instantaneamente:

SQL

INSERT INTO acessos_site
SELECT
    number,
    concat('https://visaobinaria.com.br/post/', toString(rand() % 100)),
    rand() % 1000,
    now() - rand() % 10000
FROM numbers(1000000);

4. A Performance

Agora, vamos fazer uma pergunta complexa: “Quais são as 5 URLs mais acessadas?”

SQL

SELECT
    url,
    count() as total
FROM acessos_site
GROUP BY url
ORDER BY total DESC
LIMIT 5;

Execute. O resultado deve aparecer em algo como 0.005 sec. É instantâneo. Em um banco tradicional com milhões de linhas, isso exigiria índices complexos ou causaria lentidão.

Conectando com Go (Integração)

Você não vai usar o terminal para sempre. Vamos conectar nossa API Go ao ClickHouse.

Instale o driver oficial: go get github.com/ClickHouse/clickhouse-go/v2

Go

package main

import (
    "context"
    "fmt"
    "github.com/ClickHouse/clickhouse-go/v2"
)

func main() {
    conn, err := clickhouse.Open(&clickhouse.Options{
        Addr: []string{"127.0.0.1:9000"},
        Auth: clickhouse.Auth{
            Database: "default",
            Username: "default",
            Password: "",
        },
    })
    
    if err != nil {
        panic(err)
    }

    // Exemplo: Lendo dados
    rows, err := conn.Query(context.Background(), "SELECT count() FROM acessos_site")
    if err != nil {
        panic(err)
    }
    
    for rows.Next() {
        var count uint64
        rows.Scan(&count)
        fmt.Printf("Total de linhas: %d\n", count)
    }
}

Quando NÃO usar ClickHouse?

Como mentor, preciso ser honesto. Não jogue seu PostgreSQL fora. O ClickHouse é ruim para:

1. Updates e Deletes unitários: Ele não foi feito para você mudar o email de um usuário específico. Updates são operações pesadas e assíncronas no ClickHouse.
2. Transações complexas (ACID): Não tente fazer um sistema bancário de transferência de dinheiro nele. Use Postgres para isso.
3. Buscas por Chave Única: SELECT * FROM tabela WHERE id = 123 é mais rápido no Postgres.

Conclusão

A arquitetura moderna de software geralmente envolve dois bancos de dados:

1. PostgreSQL (OLTP): Para o “estado atual” da aplicação (usuários, pedidos, pagamentos).
2. ClickHouse (OLAP): Para o “histórico de eventos” (logs, cliques, telemetria, histórico de vendas).

Ao adicionar o ClickHouse ao seu cinto de utilidades, você para de ter medo de tabelas com 1 bilhão de linhas e começa a ver dados como um ativo, não como um problema de performance.

Você já teve problemas de lentidão em dashboards? Já conhecia o conceito de banco colunar? Comente abaixo!

---

3. SEÇÃO FAQ (Featured Snippets)

O ClickHouse substitui o PostgreSQL? Não. Eles são complementares. O PostgreSQL é ideal para transações (OLTP) e gerenciamento de dados do dia a dia. O ClickHouse é especializado em análises (OLAP) e grandes volumes de dados. A arquitetura ideal geralmente usa os dois juntos.

O ClickHouse é gratuito? Sim, o ClickHouse é open-source (licença Apache 2.0). Você pode instalá-lo gratuitamente nos seus servidores. Existem também versões gerenciadas na nuvem (ClickHouse Cloud) que são pagas.

Por que o ClickHouse é tão rápido? Principalmente devido ao armazenamento orientado a colunas (lê apenas os dados necessários), compressão de dados eficiente e execução vetorizada de queries (processa múltiplos dados simultaneamente na CPU).

---