Conceitos equivalentes entre ClickStack e Elastic

Conceitos equivalentes — ClickStack e Elastic

​

Elastic Stack vs ClickStack

Tanto o Elastic Stack quanto o ClickStack cobrem as funções centrais de uma plataforma de observabilidade, mas abordam essas funções com filosofias de design diferentes. Essas funções incluem:

• UI e alertas: ferramentas para consultar dados, criar dashboards e gerenciar alertas.
• Armazenamento e mecanismo de consulta: os sistemas de backend responsáveis por armazenar dados de observabilidade e atender consultas analíticas.
• Coleta de dados e ETL: agentes e pipelines que coletam dados de telemetria e os processam antes da ingestão.

A tabela abaixo mostra como cada stack mapeia seus componentes para essas funções:

Função	Elastic Stack	ClickStack	Comentários
UI e alertas	Kibana — dashboards, busca e alertas	UI do ClickStack (HyperDX) — UI em tempo real, busca e alertas	Ambos servem como a interface principal para os usuários, incluindo visualizações e gerenciamento de alertas. A UI do ClickStack foi criada especificamente para observabilidade e é fortemente acoplada à semântica do OpenTelemetry.
Armazenamento e mecanismo de consulta	Elasticsearch — armazenamento de documentos JSON com índice invertido	ClickHouse — banco de dados orientado a colunas com motor vetorizado	O Elasticsearch usa um índice invertido otimizado para busca; o ClickHouse usa armazenamento colunar e SQL para análises em alta velocidade sobre dados estruturados e semiestruturados.
Coleta de dados	Elastic Agent, Beats (ex.: Filebeat, Metricbeat)	OpenTelemetry Collector (edge + gateway)	O Elastic oferece suporte a shippers personalizados e a um agente unificado gerenciado pelo Fleet. O ClickStack depende do OpenTelemetry, permitindo coleta e processamento de dados neutros em relação ao fornecedor.
SDKs de instrumentação	Elastic APM agents (proprietários)	OpenTelemetry SDKs (distribuídos pelo ClickStack)	Os SDKs do Elastic estão vinculados ao stack Elastic. O ClickStack se baseia nos SDKs do OpenTelemetry para logs, métricas e traces nas principais linguagens.
ETL / Processamento de dados	Logstash, pipelines de ingestão	OpenTelemetry Collector + visões materializadas do ClickHouse	O Elastic usa pipelines de ingestão e Logstash para transformação. O ClickStack desloca o processamento para o momento da inserção por meio de visões materializadas e processadores do OTel collector, que transformam os dados de forma eficiente e incremental.
Filosofia de arquitetura	Verticalmente integrado, com agentes e formatos proprietários	Baseado em padrões abertos, com componentes fracamente acoplados	O Elastic constrói um ecossistema fortemente integrado. O ClickStack enfatiza modularidade e padrões (OpenTelemetry, SQL, armazenamento de objetos) para flexibilidade e eficiência de custos.

O ClickStack enfatiza padrões abertos e interoperabilidade, sendo totalmente nativo do OpenTelemetry da coleta à UI. Em contraste, o Elastic oferece um ecossistema fortemente acoplado, porém mais verticalmente integrado, com agentes e formatos proprietários.

Considerando que Elasticsearch e ClickHouse são os motores centrais responsáveis pelo armazenamento, processamento e consulta de dados em seus respectivos stacks, entender como eles diferem é essencial. Esses sistemas sustentam o desempenho, a escalabilidade e a flexibilidade de toda a arquitetura de observabilidade. A seção a seguir explora as principais diferenças entre Elasticsearch e ClickHouse, incluindo como eles modelam os dados, lidam com a ingestão, executam consultas e gerenciam o armazenamento.

​

Elasticsearch vs ClickHouse

ClickHouse e Elasticsearch organizam e consultam dados com base em modelos diferentes, mas muitos conceitos fundamentais cumprem funções semelhantes. Esta seção apresenta as principais equivalências para quem já conhece o Elastic, relacionando-as aos seus correspondentes no ClickHouse. Embora a terminologia seja diferente, a maioria dos fluxos de trabalho de observabilidade pode ser reproduzida — muitas vezes com mais eficiência — no ClickStack.

​

Conceitos estruturais centrais

Elasticsearch	ClickHouse / SQL	Descrição
Campo	Coluna	A unidade básica de dados, que contém um ou mais valores de um tipo específico. Os campos do Elasticsearch podem armazenar tipos primitivos, além de arrays e objetos. Os campos podem ter apenas um tipo. O ClickHouse também oferece suporte a arrays e objetos (Tuples, Maps, Nested), bem como a tipos dinâmicos como Variant e Dynamic, que permitem que uma coluna tenha múltiplos tipos.
Documento	Linha	Uma coleção de campos (colunas). Os documentos do Elasticsearch são mais flexíveis por padrão, com novos campos adicionados dinamicamente com base nos dados (o tipo é inferido automaticamente). As linhas do ClickHouse, por padrão, são vinculadas a um esquema, exigindo que os usuários insiram todas as colunas de uma linha ou um subconjunto delas. O tipo JSON no ClickHouse oferece suporte à criação equivalente de colunas dinâmicas semi-estruturadas com base nos dados inseridos.
Índice	Tabela	A unidade de execução de consultas e armazenamento. Em ambos os sistemas, as consultas são executadas em índices ou tabelas, que armazenam linhas/documentos.
Implícito	Esquema (SQL)	Esquemas SQL agrupam tabelas em espaços de nomes, frequentemente usados para controle de acesso. Elasticsearch e ClickHouse não têm esquemas, mas ambos oferecem suporte à segurança em nível de linha e de tabela por meio de roles e RBAC.
Cluster	Cluster / Banco de dados	Clusters do Elasticsearch são instâncias de runtime que gerenciam um ou mais índices. No ClickHouse, bancos de dados organizam tabelas dentro de um espaço de nomes lógico, fornecendo o mesmo agrupamento lógico que um cluster no Elasticsearch. Um cluster do ClickHouse é um conjunto distribuído de nós, semelhante ao Elasticsearch, mas desacoplado e independente dos próprios dados.

​

Modelagem de dados e flexibilidade

O Elasticsearch é conhecido pela flexibilidade de esquema por meio de mapeamentos dinâmicos. Os campos são criados à medida que os documentos passam pela ingestão, e os tipos são inferidos automaticamente — a menos que um esquema seja especificado. O ClickHouse é mais rigoroso por padrão — as tabelas são definidas com esquemas explícitos —, mas oferece flexibilidade por meio dos tipos Dynamic, Variant e JSON. Esses tipos permitem a ingestão de dados semi-estruturados, com criação dinâmica de colunas e inferência de tipos semelhante à do Elasticsearch. Da mesma forma, o tipo Map permite armazenar pares chave-valor arbitrários — embora seja exigido um único tipo tanto para a chave quanto para o valor.

A abordagem do ClickHouse para flexibilidade de tipos é mais transparente e controlada. Ao contrário do Elasticsearch, em que conflitos de tipo podem causar erros de ingestão, o ClickHouse permite dados de tipos mistos em colunas Variant e oferece suporte à evolução do esquema por meio do uso do tipo JSON.

Se não estiver usando JSON, o esquema será definido estaticamente. Se não forem fornecidos valores para uma linha, eles serão definidos como Nullable (não usado no ClickStack) ou voltarão ao valor padrão do tipo, por exemplo, um valor vazio para String.

​

Ingestão e transformação

O Elasticsearch usa pipelines de ingestão com processadores (por exemplo, enrich, rename, grok) para transformar documentos antes da indexação. No ClickHouse, uma funcionalidade semelhante é obtida com views materializadas incrementais, que podem filtrar e transformar ou enriquecer os dados de entrada e inserir os resultados em tabelas de destino. Você também pode inserir dados em uma tabela com engine Null se precisar apenas armazenar a saída da visão materializada. Isso significa que apenas os resultados das visões materializadas são preservados, enquanto os dados originais são descartados, economizando espaço de armazenamento.

Para enriquecimento, o Elasticsearch oferece processadores de enrich dedicados para adicionar contexto aos documentos. No ClickHouse, dicionários podem ser usados tanto em tempo de consulta quanto em tempo de ingestão para enriquecer linhas — por exemplo, para mapear IPs para localizações ou aplicar lookups de user agent na inserção.

​

Linguagens de consulta

O Elasticsearch oferece suporte a várias linguagens de consulta, incluindo consultas em DSL, ES|QL, EQL e KQL (no estilo Lucene), mas tem suporte limitado a junções — apenas junções externas à esquerda estão disponíveis via ES|QL. O ClickHouse oferece suporte à sintaxe SQL completa, incluindo todos os tipos de junção, funções de janela, subconsultas (inclusive correlacionadas) e CTEs. Essa é uma grande vantagem se você precisa correlacionar sinais de observabilidade com dados de negócios ou de infraestrutura.

No ClickStack, a UI fornece uma interface de busca compatível com Lucene para facilitar a transição, juntamente com suporte completo a SQL por meio do backend do ClickHouse. Essa sintaxe é comparável à sintaxe de query string do Elastic. Para uma comparação exata dessa sintaxe, consulte “Busca no ClickStack e no Elastic”.

​

Formatos de arquivo e interfaces

O Elasticsearch oferece suporte à ingestão em JSON (e suporte limitado a CSV). O ClickHouse oferece suporte a mais de 70 formatos de arquivo, incluindo Parquet, Protobuf, Arrow, CSV e outros — tanto para ingestão quanto para exportação. Isso facilita a integração com pipelines e ferramentas externas.

Ambos os sistemas oferecem uma API REST, mas o ClickHouse também fornece um protocolo nativo para interação com baixa latência e alta taxa de transferência. A interface nativa oferece suporte ao progresso da consulta, à compressão e ao streaming com mais eficiência do que o HTTP, e é o padrão para a maior parte da ingestão em produção.

​

Indexação e armazenamento

O conceito de sharding é fundamental para o modelo de escalabilidade do Elasticsearch. Cada ① índice é dividido em shards, cada um deles sendo um índice físico do Lucene armazenado como segmentos em disco. Um shard pode ter uma ou mais cópias físicas, chamadas de réplicas de shard, para resiliência. Para escalabilidade, shards e réplicas podem ser distribuídos entre vários nós. Um único shard ② consiste em um ou mais segmentos imutáveis. Um segmento é a estrutura básica de indexação do Lucene, a biblioteca Java que fornece os recursos de indexação e busca nos quais o Elasticsearch se baseia.

Processamento de inserção no Elasticsearch

Ⓐ Documentos recém-inseridos Ⓑ primeiro vão para um buffer de indexação em memória que, por padrão, é esvaziado uma vez por segundo. Uma fórmula de roteamento é usada para determinar o shard de destino dos documentos liberados do buffer, e um novo segmento é gravado em disco para esse shard. Para melhorar a eficiência das consultas e permitir a exclusão física de documentos excluídos ou atualizados, os segmentos são continuamente mesclados em segundo plano em segmentos maiores até atingirem um tamanho máximo de 5 GB. No entanto, é possível forçar uma mesclagem em segmentos ainda maiores.

O Elasticsearch recomenda dimensionar os shards para cerca de 50 GB ou 200 milhões de documentos devido à sobrecarga de heap da JVM e de metadados. Também há um limite rígido de 2 bilhões de documentos por shard. O Elasticsearch paraleliza consultas entre shards, mas cada shard é processado usando uma única thread, o que torna o excesso de sharding caro e contraproducente. Isso acopla, por natureza, o sharding à escalabilidade, exigindo mais shards (e nós) para escalar o desempenho.

O Elasticsearch indexa todos os campos em índices invertidos para buscas rápidas, usando opcionalmente doc values para agregações, ordenação e acesso a campos por script. Campos numéricos e geoespaciais usam árvores Block K-D para buscas em dados geoespaciais e em intervalos numéricos e de datas.

É importante notar que o Elasticsearch armazena o documento original completo em _source (comprimido com LZ4, Deflate ou ZSTD), enquanto o ClickHouse não armazena uma representação separada do documento. Os dados são reconstruídos a partir das colunas no momento da consulta, economizando espaço de armazenamento. Essa mesma capacidade também é possível no Elasticsearch usando Synthetic _source, com algumas restrições. Desabilitar _source também tem implicações que não se aplicam ao ClickHouse.

No Elasticsearch, os mapeamentos de índice (equivalentes aos esquemas de tabela no ClickHouse) controlam o tipo dos campos e as estruturas de dados usadas para essa persistência e consulta.

O ClickHouse, por outro lado, é orientado a colunas — cada coluna é armazenada de forma independente, mas sempre ordenada pela chave primária/de ordenação da tabela. Essa ordenação permite índices primários esparsos, que permitem ao ClickHouse pular dados com eficiência durante a execução da consulta. Quando as consultas filtram por campos da chave primária, o ClickHouse lê apenas as partes relevantes de cada coluna, reduzindo significativamente a E/S de disco e melhorando o desempenho — mesmo sem um índice completo em cada coluna.

O ClickHouse também oferece suporte a skip indexes, que aceleram a filtragem ao pré-computar dados de índice para colunas selecionadas. Eles precisam ser definidos explicitamente, mas podem melhorar significativamente o desempenho. Além disso, o ClickHouse permite especificar codecs de compressão e algoritmos de compressão por coluna — algo que o Elasticsearch não suporta (sua compressão se aplica apenas ao armazenamento do JSON em _source).

O ClickHouse também oferece suporte a sharding, mas seu modelo foi projetado para favorecer a escala vertical. Um único shard pode armazenar trilhões de linhas e continuar com desempenho eficiente, desde que memória, CPU e disco permitam. Diferentemente do Elasticsearch, não há um limite rígido de linhas por shard. Os shards no ClickHouse são lógicos — na prática, tabelas individuais — e não exigem particionamento, a menos que o conjunto de dados exceda a capacidade de um único nó. Isso normalmente acontece devido a limitações de espaço em disco, e o sharding ① só é introduzido quando a expansão horizontal se torna necessária - reduzindo a complexidade e a sobrecarga. Nesse caso, assim como no Elasticsearch, um shard armazenará um subconjunto dos dados. Os dados dentro de um único shard são organizados como uma coleção de ② partes de dados imutáveis que contêm ③ várias estruturas de dados.

O processamento dentro de um shard do ClickHouse é totalmente paralelizado, e os usuários são incentivados a escalar verticalmente para evitar os custos de rede associados à movimentação de dados entre nós.

Processamento de inserções no ClickHouse

As inserções no ClickHouse são síncronas por padrão — a gravação só é confirmada após o commit — mas podem ser configuradas para inserções assíncronas para reproduzir o buffering e o batching no estilo do Elastic. Se inserções assíncronas de dados forem usadas, Ⓐ as linhas recém-inseridas vão primeiro para um Ⓑ buffer de inserção em memória, que, por padrão, é esvaziado uma vez a cada 200 milissegundos. Se vários shards forem usados, uma tabela distribuída será usada para encaminhar as linhas recém-inseridas ao shard de destino. Uma nova parte é gravada em disco para o shard.

​

Distribuição e replicação

Embora tanto o Elasticsearch quanto o ClickHouse usem clusters, shards e réplicas para garantir escalabilidade e tolerância a falhas, seus modelos diferem significativamente na implementação e nas características de desempenho.

O Elasticsearch usa um modelo primário-secundário para replicação. Quando os dados são gravados em um shard primário, eles são copiados de forma síncrona para uma ou mais réplicas. Essas réplicas são, por si só, shards completos distribuídos entre nós para garantir redundância. O Elasticsearch só confirma escritas depois que todas as réplicas exigidas confirmam a operação — um modelo que oferece quase consistência sequencial, embora leituras sujas a partir das réplicas sejam possíveis antes da sincronização completa. Um nó mestre coordena o cluster, gerenciando a alocação de shards, a saúde e a eleição de líder.

Em contrapartida, o ClickHouse emprega consistência eventual por padrão, coordenada pelo Keeper - uma alternativa leve ao ZooKeeper. As escritas podem ser enviadas diretamente para qualquer réplica ou por meio de uma tabela distribuída, que seleciona automaticamente uma réplica. A replicação é assíncrona - as alterações são propagadas para outras réplicas depois que a escrita é confirmada. Para garantias mais rígidas, o ClickHouse oferece suporte a consistência sequencial, em que as escritas só são confirmadas depois de serem efetivadas em todas as réplicas, embora esse modo raramente seja usado devido ao impacto no desempenho. As tabelas distribuídas unificam o acesso entre vários shards, encaminhando consultas SELECT para todos os shards e mesclando os resultados. Para operações INSERT, elas equilibram a carga distribuindo os dados uniformemente entre os shards. A replicação do ClickHouse é altamente flexível: qualquer réplica (uma cópia de um shard) pode aceitar escritas, e todas as alterações são sincronizadas de forma assíncrona com as demais. Essa arquitetura permite atender consultas sem interrupção durante falhas ou manutenção, com a ressincronização sendo feita automaticamente - eliminando a necessidade de impor o modelo primário-secundário na camada de dados.

ClickHouse Cloud

No ClickHouse Cloud, a arquitetura introduz um modelo de compute shared-nothing em que um único shard é suportado por armazenamento de objetos. Isso substitui a alta disponibilidade tradicional baseada em réplicas, permitindo que o shard seja lido e gravado por vários nós simultaneamente. A separação entre armazenamento e compute permite escalabilidade elástica sem gerenciamento explícito de réplicas.

Em resumo:

• Elastic: Os shards são estruturas físicas do Lucene vinculadas à memória da JVM. O excesso de shards introduz penalidades de desempenho. A replicação é síncrona e coordenada por um nó mestre.
• ClickHouse: Os shards são lógicos e escaláveis verticalmente, com execução local altamente eficiente. A replicação é assíncrona (mas pode ser sequencial), e a coordenação é leve.

Em última análise, o ClickHouse favorece simplicidade e desempenho em escala ao minimizar a necessidade de ajuste de shards, sem deixar de oferecer fortes garantias de consistência quando necessário.

​

Desduplicação e roteamento

O Elasticsearch elimina documentos duplicados com base no _id, roteando-os para os shards de acordo com isso. O ClickHouse não armazena um identificador de linha padrão, mas oferece desduplicação no momento da inserção, permitindo que os usuários tentem novamente inserts com falha com segurança. Para ter mais controle, ReplacingMergeTree e outros motores de tabela permitem a desduplicação com base em colunas específicas.

O roteamento de índice no Elasticsearch garante que documentos específicos sejam sempre encaminhados para shards específicos. No ClickHouse, você pode definir chaves de shard ou usar tabelas Distributed para obter uma localidade de dados semelhante.

​

Agregações e modelo de execução

Embora ambos os sistemas suportem agregação de dados, o ClickHouse oferece significativamente mais funções, incluindo funções estatísticas, aproximadas e analíticas especializadas.

Em casos de uso de observabilidade, uma das aplicações mais comuns das agregações é contar com que frequência mensagens de log ou eventos específicos ocorrem (e acionar alertas caso essa frequência seja incomum).

O equivalente, no Elasticsearch, a uma consulta SQL do ClickHouse SELECT count(*) FROM ... GROUP BY ... é a agregação terms, que é uma agregação do tipo bucket do Elasticsearch.

O GROUP BY do ClickHouse com count(*) e a agregação terms do Elasticsearch geralmente são equivalentes em termos de funcionalidade, mas diferem bastante em implementação, desempenho e qualidade dos resultados.

Essa agregação no Elasticsearch estima resultados em consultas “top-N” (por exemplo, os 10 principais hosts por contagem) quando os dados consultados abrangem vários shards. Essa estimativa melhora a velocidade, mas pode comprometer a precisão. Você pode reduzir esse erro inspecionando doc_count_error_upper_bound e aumentando o parâmetro shard_size — ao custo de maior uso de memória e consultas mais lentas.

O Elasticsearch também exige uma configuração size para todas as agregações com buckets — não há como retornar todos os grupos únicos sem definir explicitamente um limite. Agregações de alta cardinalidade correm o risco de atingir os limites de max_buckets ou exigem paginação com uma agregação composta, o que costuma ser complexo e ineficiente.

O ClickHouse, por outro lado, realiza agregações exatas por padrão. Funções como count(*) retornam resultados precisos sem exigir ajustes de configuração, tornando o comportamento das consultas mais simples e previsível.

O ClickHouse não impõe limites de tamanho. Você pode executar consultas GROUP BY sem limite em grandes conjuntos de dados. Se os limites de memória forem excedidos, o ClickHouse pode gravar dados temporários em disco. Agregações que agrupam por um prefixo da chave primária são especialmente eficientes e muitas vezes são executadas com consumo mínimo de memória.

​

Modelo de execução

As diferenças acima podem ser atribuídas aos modelos de execução do Elasticsearch e do ClickHouse, que adotam abordagens fundamentalmente diferentes para a execução de consultas e o paralelismo.

O ClickHouse foi projetado para maximizar a eficiência em hardware moderno. Por padrão, o ClickHouse executa uma consulta SQL com N faixas de execução simultâneas em uma máquina com N núcleos de CPU:

Em um único nó, as faixas de execução dividem os dados em intervalos independentes, permitindo processamento simultâneo entre threads de CPU. Isso inclui filtragem, agregação e ordenação. Os resultados locais de cada faixa acabam sendo mesclados, e um operador de limite é aplicado caso a consulta inclua uma cláusula LIMIT.

A execução da consulta é ainda mais paralelizada por:

1. Vetorizaçāo SIMD: operações sobre dados colunares usam instruções SIMD da CPU (por exemplo, AVX512), permitindo o processamento em lote de valores.
2. Paralelismo em nível de cluster: em configurações distribuídas, cada nó realiza o processamento da consulta localmente. Estados de agregação parciais são transmitidos ao nó iniciador e mesclados. Se as chaves de GROUP BY da consulta estiverem alinhadas com as chaves de sharding, a mesclagem pode ser minimizada ou totalmente evitada.

Esse modelo permite escalonar com eficiência entre núcleos e nós, tornando o ClickHouse muito adequado para análises em larga escala. O uso de estados de agregação parciais permite que resultados intermediários de diferentes threads e nós sejam mesclados sem perda de precisão.

Em contraste, o Elasticsearch atribui uma thread por shard para a maioria das agregações, independentemente de quantos núcleos de CPU estejam disponíveis. Essas threads retornam resultados top-N locais ao shard, que são mesclados no nó coordenador. Essa abordagem pode subutilizar os recursos do sistema e introduzir possíveis imprecisões em agregações globais, especialmente quando termos frequentes estão distribuídos entre vários shards. A precisão pode ser melhorada aumentando o parâmetro shard_size, mas isso tem como custo maior uso de memória e maior latência da consulta.

Em resumo, o ClickHouse executa agregações e consultas com paralelismo mais granular e maior controle sobre os recursos de hardware, enquanto o Elasticsearch depende da execução baseada em shard, com restrições mais rígidas.

Para mais detalhes sobre a mecânica das agregações nas respectivas tecnologias, recomendamos o post no blog “ClickHouse vs. Elasticsearch: The Mechanics of Count Aggregations”.

​

Gerenciamento de dados

Elasticsearch e ClickHouse adotam abordagens fundamentalmente diferentes para gerenciar dados de observabilidade em séries temporais — especialmente no que diz respeito à retenção de dados, rollover e armazenamento em camadas.

​

Gerenciamento do ciclo de vida de índices vs TTL nativo

No Elasticsearch, o gerenciamento de dados de longo prazo é feito por meio de Index Lifecycle Management (ILM) e Data Streams. Esses recursos permitem definir políticas que determinam quando os índices passam por rollover (por exemplo, após atingirem determinado tamanho ou idade), quando índices mais antigos são movidos para armazenamento de menor custo (por exemplo, nas camadas warm ou cold) e quando são finalmente excluídos. Isso é necessário porque o Elasticsearch não oferece suporte a re-sharding, e os shards não podem crescer indefinidamente sem perda de desempenho. Para gerenciar o tamanho dos shards e permitir exclusões eficientes, novos índices precisam ser criados periodicamente e os antigos removidos — na prática, fazendo a rotação dos dados no nível do índice.

O ClickHouse adota uma abordagem diferente. Em geral, os dados são armazenados em uma única tabela e gerenciados com expressões TTL (time-to-live) no nível de coluna ou partição. Os dados podem ser particionados por data, permitindo uma exclusão eficiente sem a necessidade de criar novas tabelas ou realizar rollovers de índice. À medida que os dados envelhecem e atendem à condição de TTL, o ClickHouse os remove automaticamente — não é necessária nenhuma infraestrutura adicional para gerenciar essa rotação.

​

Camadas de armazenamento e arquiteturas hot-warm

O Elasticsearch oferece suporte a arquiteturas de armazenamento hot-warm-cold-frozen, nas quais os dados são movidos entre camadas de armazenamento com diferentes características de desempenho. Isso normalmente é configurado por meio do ILM e vinculado às funções dos nós no cluster.

O ClickHouse oferece suporte a armazenamento em camadas por meio de motores de tabela nativos, como MergeTree, que podem mover automaticamente dados mais antigos entre diferentes volumes (por exemplo, de SSD para HDD para armazenamento de objetos) com base em regras personalizadas. Isso pode simular a abordagem hot-warm-cold do Elastic — mas sem a complexidade de gerenciar várias funções de nós ou clusters.

ClickHouse Cloud

No ClickHouse Cloud, isso se torna ainda mais simples: todos os dados são armazenados em armazenamento de objetos (por exemplo, S3), e o processamento é desacoplado. Os dados podem permanecer no armazenamento de objetos até serem consultados; nesse momento, são buscados e armazenados em cache localmente (ou em um cache distribuído) — oferecendo o mesmo perfil de custo do tier frozen do Elastic, com melhor desempenho. Essa abordagem significa que não é preciso mover dados entre camadas de armazenamento, tornando arquiteturas hot-warm redundantes.

​

Rollups vs agregações incrementais

No Elasticsearch, rollups ou agregações são obtidos por meio de um mecanismo chamado transforms. Eles são usados para resumir dados de séries temporais em intervalos fixos (por exemplo, por hora ou por dia) usando um modelo de janela deslizante. São configurados como jobs recorrentes em segundo plano que agregam dados de um índice e gravam os resultados em um índice de rollup separado. Isso ajuda a reduzir o custo de consultas em longos intervalos de tempo, evitando varreduras repetidas de dados brutos com alta cardinalidade.

O diagrama a seguir ilustra, de forma abstrata, como os transforms funcionam (observe que usamos a cor azul para todos os documentos que pertencem ao mesmo bucket para o qual queremos pré-calcular valores agregados):

Transforms contínuos usam checkpoints baseados em um intervalo de verificação configurável (frequency do transform, com valor padrão de 1 minuto). No diagrama acima, assumimos que ① um novo checkpoint é criado após o intervalo de verificação transcorrer. Em seguida, o Elasticsearch verifica mudanças no índice de origem dos transforms e detecta três novos documentos blue (11, 12 e 13) que passaram a existir desde o checkpoint anterior. Portanto, o índice de origem é filtrado para todos os documentos blue existentes e, com uma composite aggregation (para utilizar a paginação dos resultados), os valores agregados são recalculados (e o índice de destino é atualizado com um documento que substitui o documento que continha os valores de agregação anteriores). Da mesma forma, em ② e ③, novos checkpoints são processados verificando mudanças e recalculando os valores agregados a partir de todos os documentos existentes que pertencem ao mesmo bucket blue.

O ClickHouse adota uma abordagem fundamentalmente diferente. Em vez de reagregar os dados periodicamente, o ClickHouse oferece suporte a visões materializadas incrementais, que transformam e agregam os dados no momento da inserção. Quando novos dados são gravados em uma tabela de origem, uma visão materializada executa uma consulta SQL de agregação predefinida apenas sobre os novos blocos inseridos e grava os resultados agregados em uma tabela de destino.

Esse modelo é possível graças ao suporte do ClickHouse a estados de agregação parciais — representações intermediárias de funções de agregação que podem ser armazenadas e depois mescladas. Isso permite manter resultados parcialmente agregados que são rápidos de consultar e baratos de atualizar. Como a agregação acontece à medida que os dados chegam, não é necessário executar jobs recorrentes caros nem resumir novamente os dados antigos.

A seguir, ilustramos de forma abstrata a mecânica das visões materializadas incrementais (observe que usamos a cor azul para todas as linhas que pertencem ao mesmo grupo para o qual queremos pré-calcular valores agregados):

No diagrama acima, a tabela de origem da visão materializada já contém uma parte de dados que armazena algumas linhas blue (de 1 a 10) pertencentes ao mesmo grupo. Para esse grupo, também já existe uma parte de dados na tabela de destino da view armazenando um estado de agregação parcial para o grupo blue. Quando ① ② ③ inserções na tabela de origem com novas linhas ocorrem, uma parte de dados correspondente é criada na tabela de origem para cada inserção e, em paralelo, (apenas) para cada bloco de linhas recém-inseridas, um estado de agregação parcial é calculado e inserido na forma de uma parte de dados na tabela de destino da visão materializada. ④ Durante as mesclagens de partes em segundo plano, os estados de agregação parciais são mesclados, resultando em agregação incremental de dados.

Observe que todas as funções de agregação (mais de 90), incluindo suas combinações com combinadores de função de agregação, oferecem suporte a estados de agregação parciais.

Para um exemplo mais concreto de Elasticsearch vs ClickHouse para agregações incrementais, veja este exemplo.

As vantagens da abordagem do ClickHouse incluem:

• Agregados sempre atualizados: visões materializadas ficam sempre em sincronia com a tabela de origem.
• Sem jobs em segundo plano: as agregações são feitas no momento da inserção, e não no momento da consulta.
• Melhor desempenho em tempo real: ideal para workloads de observabilidade e analytics em tempo real, em que agregados atualizados são necessários imediatamente.
• Composição flexível: visões materializadas podem ser organizadas em camadas ou combinadas com outras visões e tabelas para estratégias mais complexas de aceleração de consultas.
• TTLs distintos: diferentes configurações de TTL podem ser aplicadas à tabela de origem e à tabela de destino da visão materializada.

Esse modelo é particularmente poderoso para casos de uso de observabilidade em que você precisa calcular métricas como taxas de erro por minuto, latências ou detalhamentos top-N sem varrer bilhões de registros brutos a cada consulta.

​

Suporte a lakehouse

ClickHouse e Elasticsearch adotam abordagens fundamentalmente diferentes para integração com lakehouse. O ClickHouse é um mecanismo de execução de consultas completo, capaz de executar consultas em formatos de lakehouse como Iceberg e Delta Lake, além de se integrar a catálogos de lago de dados como AWS Glue e Unity catalog. Esses formatos dependem da consulta eficiente de arquivos Parquet, algo que o ClickHouse oferece com suporte completo. O ClickHouse pode ler tabelas Iceberg e Delta Lake diretamente, permitindo integração perfeita com arquiteturas modernas de lago de dados.

Em contrapartida, o Elasticsearch é fortemente acoplado ao seu formato de dados interno e ao mecanismo de armazenamento baseado em Lucene. Ele não consegue consultar diretamente formatos de lakehouse nem arquivos Parquet, o que limita sua capacidade de participar de arquiteturas modernas de lago de dados. O Elasticsearch exige que os dados sejam transformados e carregados em seu formato proprietário antes que possam ser consultados.

Os recursos de lakehouse do ClickHouse vão além da simples leitura de dados:

• Integração com catálogo de dados: o ClickHouse oferece suporte à integração com catálogos de dados como AWS Glue, permitindo a descoberta automática e o acesso a tabelas no armazenamento de objetos.
• Suporte a armazenamento de objetos: suporte nativo para consultar dados armazenados em S3, GCS e Azure Blob Storage, sem exigir movimentação de dados.
• Federação de consultas: a capacidade de correlacionar dados entre várias fontes, incluindo tabelas de lakehouse, bancos de dados tradicionais e tabelas do ClickHouse, usando dicionários externos e funções de tabela.
• Carregamento incremental: suporte ao carregamento contínuo de tabelas de lakehouse em tabelas locais MergeTree, usando recursos como S3Queue e ClickPipes.
• Otimização de desempenho: execução distribuída de consultas sobre dados de lakehouse usando funções de cluster para melhorar o desempenho.

Esses recursos fazem do ClickHouse uma opção natural para organizações que adotam arquiteturas de lakehouse, permitindo que elas aproveitem tanto a flexibilidade dos lagos de dados quanto o desempenho de um banco de dados colunar.