Já trabalho com o ClickHouse em aulas há mais de dois anos e continuo impressionado com o quanto ele entrega em cenários de alta volumetria. Uma das coisas que sempre destaco é que o ClickHouse não é “um único motor de armazenamento”, mas sim um conjunto de engines, cada uma adequada a um caso de uso diferente. Saber escolher a engine certa é o que garante eficiência e economia.

Alguns exemplos:

MergeTree e variações (ReplacingMergeTree, SummingMergeTree, AggregatingMergeTree, etc.)
Base para a maioria das tabelas. São otimizadas para grandes volumes, permitem compressão, partição e TTL. Cada variação resolve um problema específico, como deduplicar linhas, somar valores já no armazenamento ou manter agregados.

Log e TinyLog
Simples, rápidas para inserções, mas sem suporte a índices ou partições. Úteis em testes ou tabelas temporárias.

Memory
Mantém todos os dados em RAM. Ideal para cálculos transitórios, benchmarks ou tabelas de sessão.

Distributed
Permite criar uma visão única sobre dados espalhados em múltiplos shards. Fundamental quando se escala horizontalmente.

File e URL engines
Leitura direta de arquivos (CSV, Parquet, JSON) ou de dados vindos via HTTP. Muito usadas em integrações rápidas.

View e Materialized View
Permitem abstrações e pré-processamento no momento do insert. Esse último é especialmente útil para criar pipelines de agregação sem pesar na aplicação.

Esse ecossistema de engines é um dos pontos que tornam o ClickHouse tão flexível. É possível modelar a mesma informação de formas diferentes, dependendo se o foco é compressão, agregação ou velocidade de leitura.