Loki o Elasticsearch: ahorrar disco puede hacer más lenta la búsqueda

Loki favorece el almacenamiento de registros cuando las consultas suelen comenzar por servicio, entorno y tiempo. Su arquitectura de índices y fragmentos permite localizar flujos mediante etiquetas y conservar las líneas en fragmentos comprimidos. Si una búsqueda de texto abarca muchos flujos, el sistema debe leer y filtrar más contenido: el ahorro de espacio puede trasladar trabajo a la consulta.

Elasticsearch resulta más adecuado cuando el equipo necesita encontrar palabras o frases imprevistas entre registros de distintos orígenes. La documentación de búsqueda de Elastic explica que los campos de tipo text se analizan e indexan para buscar dentro de ellos. Esa flexibilidad tiene un coste de almacenamiento; por eso la comparación útil depende tanto del esquema como del producto elegido.

Qué se guarda para responder una consulta

En Loki, una combinación de etiquetas identifica un flujo. El índice indica dónde están sus fragmentos y cada fragmento reúne líneas de ese flujo durante un intervalo. Una consulta que selecciona una aplicación y una ventana breve puede descartar gran parte del historial antes de buscar una cadena dentro de las líneas restantes.

Cuando la pregunta no identifica bien el origen, la ventaja cambia de lugar. Loki conserva el contenido para poder filtrarlo después, pero un selector amplio deja más fragmentos por examinar. Elasticsearch puede resolver búsquedas sobre campos de texto indexados mediante términos preparados durante la ingesta. Se paga espacio al escribir para disponer de una ruta de búsqueda distinta al leer.

Indexar tampoco es una propiedad uniforme de Elasticsearch. El esquema puede tratar un mensaje como texto analizado o conservarlo para consultas de otro tipo. Dos instalaciones con las mismas líneas y versiones pueden ocupar cantidades distintas de disco y admitir preguntas distintas. Una cifra de compresión sin el mapeo de campos no describe por sí sola la capacidad de investigación que recibirá el equipo.

Qué demuestra la medición de disco y latencia

En la medición de Platform Monkey, un corpus generado de 300.000 líneas y 40,9 MB brutos ocupó 10,1 MB con Loki, 52,6 MB con Elasticsearch en modo logsdb, 7,9 MB con logsdb_columnar y el mensaje como keyword, y 32,4 MB con logsdb_columnar y el mensaje como text; en una búsqueda de frase sobre ese corpus, las configuraciones con texto indexado tardaron 35 ms frente a 280 ms de Loki. El ensayo empleó un solo nodo por sistema y un almacén de archivos para Loki.

La variante columnar más pequeña ilustra el límite del ahorro: en esa configuración, el mensaje carecía del índice de texto necesario para la consulta de frase usada en la prueba. Al mapearlo como text, volvió esa capacidad y aumentó el espacio ocupado. Por tanto, el resultado más compacto no representa una alternativa equivalente para un equipo que necesita buscar frases dentro de los mensajes.

Las latencias publicadas describen ese corpus y esas consultas, no una ventaja fija trasladable a producción. El filtro literal de líneas utilizado en Loki y la búsqueda de frase sobre texto analizado en Elasticsearch tampoco tienen exactamente la misma semántica. La prueba sirve para mostrar el intercambio entre estructuras guardadas y trabajo de lectura; no predice cuánto tardará una investigación con otros datos, selectores o recursos de consulta.

Las notas de Elasticsearch para la versión 9.5.0 presentan columnar y logsdb_columnar como vista preliminar técnica. En esos modos, los campos se guardan por defecto como valores columnares sin índice invertido; los campos text pueden indexarse si se declaran expresamente. Ese estado de madurez también importa al valorar la variante de menor tamaño para un despliegue operativo.

Tres patrones de búsqueda, tres costes distintos

Origen y tiempo conocidos. Una alerta que señala el servicio afectado y una ventana acotada favorece el recorrido de Loki: las etiquetas seleccionan flujos y el filtro de línea trabaja sobre los fragmentos correspondientes. Si esa es la consulta habitual y la retención consume buena parte del presupuesto, indexar todo el mensaje puede aportar poco al uso diario. La condición es disponer de etiquetas que realmente reduzcan el conjunto de datos.

Texto imprevisto entre servicios. Durante una investigación, el equipo puede conocer una frase del error sin saber qué aplicación la emitió. Un campo de mensaje indexado en Elasticsearch facilita esa búsqueda amplia. Loki también permite buscar el texto conservado, pero un selector poco preciso obliga a examinar más líneas. Aquí el criterio decisivo es la latencia aceptable para consultas interactivas, junto con el espacio que exige sostenerlas.

Valores estructurados conocidos. Si predominan filtros por estado, ruta o duración, conviene distinguir la búsqueda exacta y el análisis de campos de la búsqueda de frases dentro del mensaje. Una configuración columnar puede reducir estructuras almacenadas cuando esas frases no hacen falta. Si sí hacen falta, el mensaje requiere un tratamiento distinto. El volumen de consultas sobre cada campo determina qué capacidad merece pagarse durante la ingesta.

Cuándo las etiquetas perjudican a Loki

El tamaño del índice de Loki depende de las combinaciones de etiquetas, no solo del volumen de líneas. Las recomendaciones de Grafana sobre etiquetas advierten que demasiadas combinaciones crean numerosos flujos, agrandan el índice y dejan fragmentos pequeños. Un identificador de petición u otro valor casi único puede convertir una estrategia pensada para ahorrar espacio en una fuente de sobrecarga.

Las etiquetas funcionan mejor para categorías estables que ayudan a seleccionar registros, como aplicación, entorno o región. Un identificador que cambia en cada evento puede permanecer en la línea o, cuando corresponde, en metadatos consultables sin definir la identidad del flujo. Así se conserva la posibilidad de localizarlo sin multiplicar las combinaciones indexadas. La decisión exige observar qué campos acotan las consultas frecuentes y cuáles solo se necesitan después de abrir un flujo.

La elección según volumen y necesidades

Para mucho volumen y retención prolongada, Loki encaja mejor si las búsquedas empiezan por etiquetas selectivas y el equipo puede mantener baja su cardinalidad. Si predominan las búsquedas de texto desconocido entre servicios y periodos amplios, Elasticsearch con los campos pertinentes indexados ofrece una ruta más directa. Cuando bastan filtros sobre valores estructurados, el esquema columnar merece una evaluación separada, teniendo presente su condición de vista preliminar técnica.

Con poco volumen, la diferencia de disco puede pesar menos que administrar otra plataforma. Con mucho volumen, el gasto tampoco termina en los bytes almacenados: influyen el cómputo para consultar, la retención y el trabajo de operación. Si el equipo ya mantiene Elasticsearch, incorporar Loki añade componentes; si sus búsquedas están bien delimitadas y el historial domina el coste, esa complejidad puede compensarse. La elección depende del conjunto real de consultas y del esquema necesario para responderlas.

Lee también:

• GA4 o Matomo: ahorrar licencia puede elevar el coste de privacidad
• Jira o Linear: ahorrar en licencias puede trasladar el coste a la administración
• REST o GraphQL: ahorrar solicitudes puede aumentar la complejidad