Set up docs MCPBú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á enNULL. - 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.