Consultar un lago

4 tareas · 35 min · Principiante

Un lago de seguridad es una carpeta enorme de archivos en columnas. No tiene un servidor que indexe cada campo: la velocidad y el costo de una consulta dependen de cuántos archivos hay que abrir. La respuesta está en las particiones, que son carpetas por clase y por fecha, y en pedir solo las columnas necesarias. En la Cooperativa Telar del Sur lees las particiones y el historial de tres consultas, y descubres cuál se equivocó.

0 de 4 · 0%

Objetivo de la sala

El lago de la cooperativa guarda sus archivos en carpetas por class_uid y por fecha. Si una consulta indica la clase y la fecha en su filtro, el motor solo abre las carpetas que coinciden y no mira las demás: es lo que se llama podar particiones. Si el filtro nombra solo un usuario o una dirección, el motor no sabe en qué carpeta está y tiene que abrirlas todas.

Esto no cambia el resultado; cambia lo que cuesta obtenerlo, porque en un lago se paga, en general, por lo que se escanea.

Responde para continuar

¿Qué debe llevar toda consulta sobre un lago particionado por clase y fecha?

Un filtro por clase y por fecha, para que el motor abra solo las carpetas necesarias Un filtro por usuario, porque es lo más selectivo y reduce las filas devueltas Un SELECT con todas las columnas, para no perder ningún dato del evento que se busca

Abre particiones. Quieres los eventos de autenticación (class_uid 3002) del 11 y el 12 de marzo de 2026. Solo cuentan las carpetas que cumplen clase y fecha; cada una trae su número de archivos.

Responde para continuar

Escribe cuántos archivos hay que abrir para esa consulta.

Ver pista de ayuda

Suma `archivos` de las filas de la clase 3002 con esas dos fechas.

historial_consultas guarda lo que escaneó cada consulta ya ejecutada. Una consulta cara no siempre es la que más devuelve: es la que más lee. Cruza lo que escaneó con su filtro y su selección y verás la razón.

Responde para continuar

Escribe el id de la consulta que más gigabytes escaneó.

Ver pista de ayuda

Ordena `historial_consultas` por `gb_escaneados`.

La consulta más costosa del historial pide todas las columnas de todos los días de todas las clases, y su autor solo quería los fallos de un usuario de autenticación de un día. El resultado era el mismo con una fracción de lo escaneado. Reescribirla es una buena práctica de equipo: en un lago, una consulta descuidada se paga cada vez que se ejecuta.

Responde para continuar

¿Qué reescritura mantiene el resultado y reduce lo que se escanea?

Ejecutar la consulta original dos veces y quedarse con la primera respuesta que llegue Mantener el SELECT con todas las columnas y añadir un filtro por usuario al final Filtrar por clase y fecha y pedir solo time, status_id y user.name

Inicia sesión para registrar tus puntos y progreso en el ranking.

Entrar · Registrarse

1 La partición como atajo

2 Cuántos archivos Lab

3 La que más escaneó Lab

4 Reescribir la consulta

Whoami-Labs Pro utiliza cookies