Busca no ClickStack e no Elastic

Busca no ClickStack e no Elastic

​

Busca no ClickStack e no Elastic

O ClickHouse é um engine com SQL nativo, projetado desde o início para cargas de trabalho analíticas de alto desempenho. Em contraste, o Elasticsearch fornece uma interface semelhante a SQL, convertendo SQL para a query DSL subjacente do Elasticsearch — o que significa que ela não é uma funcionalidade nativa, e a paridade de recursos é limitada.

O ClickHouse não apenas oferece suporte completo a SQL, como também o estende com uma variedade de funções voltadas para observabilidade, como argMax, histogram e quantileTiming, que simplificam consultas em logs, métricas e traces estruturados.

Para exploração simples de logs e traces, a UI do ClickStack (HyperDX) fornece uma sintaxe no estilo Lucene para filtragem textual intuitiva em consultas de campo-valor, intervalos, wildcard e muito mais. Isso é comparável à sintaxe Lucene no Elasticsearch e a elementos da Kibana Query Language.

A interface de busca oferece suporte a essa sintaxe familiar, mas a traduz nos bastidores em cláusulas SQL WHERE eficientes, tornando a experiência familiar para usuários do Kibana e, ao mesmo tempo, permitindo aproveitar o poder do SQL quando necessário. Isso permite que você explore toda a gama de funções de busca de string, funções de similaridade e funções de data e hora no ClickHouse.

Abaixo, comparamos as linguagens de consulta Lucene do ClickStack e do Elasticsearch.

​

Sintaxe de busca do ClickStack vs. query string do Elasticsearch

Tanto o ClickStack quanto o Elasticsearch oferecem linguagens de consulta flexíveis para permitir uma filtragem intuitiva de logs e traces. Enquanto a query string do Elasticsearch é fortemente integrada ao seu DSL e mecanismo de indexação, o ClickStack oferece uma sintaxe inspirada no Lucene que é traduzida em ClickHouse SQL nos bastidores. A tabela abaixo mostra como padrões de busca comuns se comportam nos dois sistemas, destacando semelhanças de sintaxe e diferenças na execução no backend.

Recurso	Sintaxe do ClickStack	Sintaxe do Elasticsearch	Comentários
Busca de texto livre	error	error	Faz correspondência em todos os campos indexados; no ClickStack, isso é reescrito como um SQL ILIKE em vários campos.
Correspondência de campo	level:error	level:error	Sintaxe idêntica. No ClickStack, a correspondência é feita com valores exatos do campo no ClickHouse.
Busca por frase	"disk full"	"disk full"	O texto entre aspas corresponde a uma sequência exata; o ClickHouse usa igualdade de string ou ILIKE.
Correspondência de frase em campo	message:"disk full"	message:"disk full"	É traduzido para SQL ILIKE ou correspondência exata.
Condições OR	error OR warning	error OR warning	OU lógico entre termos; ambos os sistemas oferecem suporte nativo a isso.
Condições AND	error AND db	error AND db	Ambos são traduzidos para interseção; não há diferença na sintaxe para o usuário.
Negação	NOT error or -error	NOT error or -error	Suportado da mesma forma; o ClickStack converte para SQL NOT ILIKE.
Agrupamento	(error OR fail) AND db	(error OR fail) AND db	Agrupamento booleano padrão em ambos.
Wildcards	error* or *fail*	error*, *fail*	O ClickStack oferece suporte a wildcards no início/fim; o ES desabilita wildcards iniciais por padrão por questões de desempenho. Wildcards dentro de termos não são suportados, por exemplo, f*ail. Os wildcards devem ser aplicados com uma correspondência de campo.
Intervalos (numérico/data)	duration:[100 TO 200]	duration:[100 TO 200]	O ClickStack usa SQL BETWEEN; o Elasticsearch expande para consultas de intervalo. * sem limite em intervalos não é suportado, por exemplo, duration:[100 TO *]. Se necessário, use Unbounded ranges abaixo.
Intervalos sem limite (numérico/data)	duration:>10 or duration:>=10	duration:>10 or duration:>=10	O ClickStack usa operadores SQL padrão
Inclusivo/exclusivo	duration:{100 TO 200} (exclusive)	Same	{} indica limites exclusivos. * em intervalos não é suportado, por exemplo, duration:[100 TO *]
Verificação de existência	N/A	_exists_:user or field:*	_exists_ não é suportado. Use LogAttributes.log.file.path: * para colunas Map, por exemplo, LogAttributes. Para colunas raiz, elas precisam existir e terão um valor padrão se não forem incluídas no evento. Para buscar valores padrão ou colunas ausentes, use a mesma sintaxe do Elasticsearch: ServiceName:* ou ServiceName != ''.
Regex	função match	name:/joh?n(ath[oa]n)/	Atualmente não é suportado na sintaxe Lucene. Você pode usar SQL e a função match ou outras funções de busca de string.
Correspondência difusa	editDistance('quikc', field) = 1	quikc~	Atualmente não é suportado na sintaxe Lucene. As funções de distância podem ser usadas em SQL, por exemplo, editDistance('rror', SeverityText) = 1, ou outras funções de similaridade.
Busca por proximidade	Não suportado	"fox quick"~5	Atualmente não é suportado na sintaxe Lucene.
Boosting	quick^2 fox	quick^2 fox	Não é suportado no ClickStack no momento.
Wildcard de campo	service.*:error	service.*:error	Não é suportado no ClickStack no momento.
Caracteres especiais com escape	Escape reserved characters with \	Same	Escape obrigatório para símbolos reservados.

​

Diferenças entre existência/ausência

Diferentemente do Elasticsearch, em que um campo pode ser totalmente omitido de um evento e, portanto, realmente “não existir”, o ClickHouse exige que todas as colunas em um esquema de tabela existam. Se um campo não for fornecido em um evento de inserção:

• Para campos Nullable, ele será definido como NULL.
• Para campos não anuláveis (o padrão), ele será preenchido com um valor padrão (geralmente uma string vazia, 0 ou equivalente).

No ClickStack, usamos a segunda opção, já que Nullable não é recomendado.

Esse comportamento significa que verificar se um campo “existe” no sentido do Elasticsearch não tem suporte direto.

Em vez disso, você pode usar field:* ou field != '' para verificar a presença de um valor não vazio. Assim, não é possível distinguir entre campos realmente ausentes e campos explicitamente vazios.

Na prática, essa diferença raramente causa problemas em casos de uso de observabilidade, mas é importante tê-la em mente ao traduzir consultas entre sistemas.