Búsquedas en ClickStack y Elastic

Búsquedas en ClickStack y Elastic

​

Búsqueda en ClickStack y Elastic

ClickHouse es un motor nativo de SQL, diseñado desde cero para cargas de trabajo analíticas de alto rendimiento. En cambio, Elasticsearch ofrece una interfaz similar a SQL que transpila SQL al DSL de consultas subyacente de Elasticsearch; es decir, no es una capacidad de primer nivel y la paridad de funciones es limitada.

ClickHouse no solo admite SQL completo, sino que además lo amplía con una variedad de funciones orientadas a la observabilidad, como argMax, histogram y quantileTiming, que simplifican las consultas sobre logs, métricas y trazas estructurados.

Para explorar logs y trazas de forma sencilla, la UI de ClickStack (HyperDX) ofrece una sintaxis de estilo Lucene para un filtrado intuitivo basado en texto con consultas de campo-valor, rangos, comodines y más. Esto es comparable a la sintaxis de Lucene en Elasticsearch y a algunos elementos de Kibana Query Language.

La interfaz de búsqueda admite esta sintaxis conocida, pero la traduce internamente en cláusulas SQL WHERE eficientes, lo que hace que la experiencia resulte familiar para los usuarios de Kibana y, al mismo tiempo, les permite aprovechar la potencia de SQL cuando lo necesiten. Esto le permite aprovechar toda la gama de funciones de búsqueda de cadenas, funciones de similitud y funciones de fecha y hora de ClickHouse.

A continuación, comparamos los lenguajes de consulta Lucene de ClickStack y Elasticsearch.

​

Sintaxis de búsqueda de ClickStack vs cadena de consulta de Elasticsearch

Tanto ClickStack como Elasticsearch proporcionan lenguajes de consulta flexibles que permiten un filtrado intuitivo de logs y trazas. Mientras que la cadena de consulta de Elasticsearch está estrechamente integrada con su DSL y su motor de indexación, ClickStack admite una sintaxis inspirada en Lucene que se traduce internamente a ClickHouse SQL. La siguiente tabla describe cómo se comportan los patrones de búsqueda habituales en ambos sistemas, destacando las similitudes de sintaxis y las diferencias en la ejecución del backend.

Funcionalidad	Sintaxis de ClickStack	Sintaxis de Elasticsearch	Comentarios
Búsqueda de texto libre	error	error	Coincide en todos los campos indexados; en ClickStack esto se reescribe como un ILIKE SQL en varios campos.
Coincidencia de campo	level:error	level:error	Sintaxis idéntica. ClickStack hace coincidir valores exactos de campos en ClickHouse.
Búsqueda de frase	"disk full"	"disk full"	El texto entre comillas coincide con una secuencia exacta; ClickHouse usa igualdad de cadenas o ILIKE.
Coincidencia de frase en campo	message:"disk full"	message:"disk full"	Se traduce a ILIKE SQL o a una coincidencia exacta.
Condiciones OR	error OR warning	error OR warning	OR lógico de términos; ambos sistemas lo admiten de forma nativa.
Condiciones AND	error AND db	error AND db	Ambos se traducen en una intersección; no hay diferencias en la sintaxis para el usuario.
Negación	NOT error o -error	NOT error o -error	Compatible de la misma forma; ClickStack lo convierte a NOT ILIKE SQL.
Agrupación	(error OR fail) AND db	(error OR fail) AND db	Agrupación booleana estándar en ambos.
Comodines	error* o *fail*	error*, *fail*	ClickStack admite comodines al principio y al final; ES desactiva los comodines iniciales de forma predeterminada por rendimiento. No se admiten comodines dentro de los términos; por ejemplo, f*ail. Los comodines deben aplicarse con una coincidencia de campo.
Rangos (numérico/fecha)	duration:[100 TO 200]	duration:[100 TO 200]	ClickStack usa BETWEEN SQL; Elasticsearch lo amplía a consultas de rango. No se admite * no acotado en rangos; por ejemplo, duration:[100 TO *]. Si es necesario, use Unbounded ranges a continuación.
Rangos no acotados (numérico/fecha)	duration:>10 o duration:>=10	duration:>10 o duration:>=10	ClickStack usa operadores SQL estándar
Inclusivo/exclusivo	duration:{100 TO 200} (exclusive)	Igual	{} indica límites exclusivos. No se admite * en rangos; p. ej., duration:[100 TO *]
Comprobación de existencia	N/A	_exists_:user o field:*	_exists_ no es compatible. Use LogAttributes.log.file.path: * para columnas Map, por ejemplo LogAttributes. En el caso de las columnas raíz, estas deben existir y tendrán un valor predeterminado si no se incluyen en el evento. Para buscar valores predeterminados o columnas ausentes, use la misma sintaxis que en Elasticsearch: ServiceName:* o ServiceName != ''.
Regex	función match	name:/joh?n(ath[oa]n)/	Actualmente no es compatible en la sintaxis de Lucene. Puede usar SQL y la función match u otras funciones de búsqueda de cadenas.
Coincidencia difusa	editDistance('quikc', field) = 1	quikc~	Actualmente no es compatible en la sintaxis de Lucene. Se pueden usar funciones de distancia en SQL; por ejemplo, editDistance('rror', SeverityText) = 1 u otras funciones de similitud.
Búsqueda de proximidad	No compatible	"fox quick"~5	Actualmente no es compatible en la sintaxis de Lucene.
Realce	quick^2 fox	quick^2 fox	Actualmente no es compatible en ClickStack.
Comodín de campo	service.*:error	service.*:error	Actualmente no es compatible en ClickStack.
Caracteres especiales escapados	Escape los caracteres reservados con \	Igual	Es necesario escapar los símbolos reservados.

​

Diferencias entre existencia y ausencia

A diferencia de Elasticsearch, donde un campo puede omitirse por completo de un evento y, por tanto, realmente “no existir”, ClickHouse requiere que existan todas las columnas del esquema de una tabla. Si no se proporciona un campo en un evento de inserción:

• En los campos Nullable, se establecerá en NULL.
• En los campos no anulables (el valor predeterminado), se rellenará con un valor predeterminado (a menudo una cadena vacía, 0 o equivalente).

En ClickStack, usamos esta última opción, ya que Nullable no se recomienda.

Este comportamiento significa que comprobar si un campo “existe” en el sentido de Elasticsearch no tiene soporte directo.

En su lugar, puedes usar field:* o field != '' para comprobar la presencia de un valor no vacío. Por tanto, no es posible distinguir entre campos realmente ausentes y campos explícitamente vacíos.

En la práctica, esta diferencia rara vez causa problemas en casos de uso de observabilidad, pero es importante tenerla en cuenta al traducir consultas entre sistemas.