Rendimiento en Snowflake: cómo influye la caché en las consultas

Imagina que una consulta tardaba doce segundos. Después de un cambio tarda uno. Ya tenemos una mejora del 91,7 %, una captura para la presentación y motivos para estar contentos. Solo falta una pregunta bastante molesta: ¿la segunda ejecución hizo el mismo trabajo?

En Snowflake, una respuesta puede llegar antes porque el motor calcula con más eficiencia, porque encuentra datos en la caché del warehouse o porque recupera un resultado que ya estaba calculado. Para quien espera delante de la pantalla las tres situaciones pueden ser estupendas. Para decidir qué hemos mejorado, significan cosas diferentes.

Una mejora de rendimiento solo es defendible si la comparación conserva el trabajo y declara qué reutiliza. No hace falta desconfiar de cada segundo ahorrado. Hace falta saber qué afirmación permiten esos segundos antes de convertirlos en una decisión de arquitectura o de presupuesto.

¿Una consulta más rápida demuestra que el warehouse funciona mejor?

No por sí sola. El tiempo observado puede incluir efectos de reutilización, espera y ejecución distintos. Si Snowflake devuelve un resultado persistido, esa observación no permite atribuir la mejora a la capacidad de cálculo del warehouse. Sí puede servir para evaluar la respuesta que recibe un usuario bajo esas condiciones.

La distinción parece académica hasta que alguien utiliza una prueba favorable para justificar un recurso mayor. En ese momento ya no estamos discutiendo un cronómetro. Estamos decidiendo qué comportamiento esperamos comprar.

Calcular, leer de cerca y recuperar algo terminado

La documentación de resultados persistidos de Snowflake explica que la plataforma puede evitar una nueva ejecución y devolver un resultado anterior. La reutilización está sujeta a condiciones, entre ellas la coincidencia de la consulta, la disponibilidad del resultado y la ausencia de cambios relevantes en los datos. Ni siquiera cumplir las condiciones documentadas garantiza siempre su reutilización.

Snowflake documenta una retención de 24 horas que puede renovarse al reutilizar el resultado, con un máximo de 31 días desde la ejecución original. Es una regla de la capacidad documentada, no una promesa de que un informe concreto vaya a responder desde caché durante un mes. Y, desde luego, no significa que deban devolverse datos obsoletos cuando cambian las tablas.

La caché del warehouse tiene otra función: conserva datos de tabla que pueden volver a utilizarse durante el procesamiento. La consulta sigue teniendo trabajo que hacer. Al suspender el warehouse se pierde esa caché. Por tanto, impedir la reutilización del resultado no equivale a medir una ejecución sin datos previamente cargados.

Resultado reutilizado

Se recupera una respuesta ya calculada. La observación habla de esa ruta de servicio.

Ejecución con datos en caché

Se calcula la respuesta aprovechando datos disponibles localmente. Habla del procesamiento en esas condiciones.

Ejecución tras la suspensión

El warehouse ha perdido su caché de datos. Es un escenario relevante si el servicio funciona con pausas, pero no representa todas sus consultas.

Estas distinciones no pretenden clasificar cada optimización interna del motor. Sirven para evitar que tres situaciones diferentes acaben con la misma etiqueta en una hoja de resultados.

Una prueba puede ser correcta y responder a otra pregunta

Imaginemos que comparamos dos configuraciones. A recibe la primera consulta después de una pausa. B recibe una repetición inmediata sobre los mismos datos. Si B gana, tenemos una observación real del escenario que acabamos de construir. Lo que no tenemos todavía es una comparación aislada entre configuraciones.

Podemos darle la vuelta al problema: eliminar toda reutilización tampoco convierte automáticamente la prueba en una representación fiel del servicio. Si un panel se consulta muchas veces con los mismos filtros, aprovechar resultados anteriores forma parte de su comportamiento habitual. Excluirlo puede ser razonable para estudiar el cálculo y poco representativo para estimar la experiencia de sus usuarios.

La pregunta que ordena el análisis es qué queremos decidir. Un cambio de tamaño necesita evidencia sobre el trabajo que puede acelerar. Un compromiso de respuesta necesita observar el recorrido del usuario, incluidas las esperas que le afectan. Una política de suspensión necesita contemplar las pausas. Son decisiones relacionadas, pero sus pruebas no son intercambiables.

Esto amplía la discusión sobre cómo interpretar el rendimiento interno de Snowflake: entender el mecanismo ayuda, pero todavía hay que construir una comparación que permita atribuirle el resultado.

La ficha de comparación defendible

Propongo acompañar cualquier afirmación de mejora con una ficha de comparación defendible. Es una síntesis propia para discutir evidencia, no un estándar de benchmarking ni un sustituto del análisis del historial de consultas.

Decisión

Qué vamos a cambiar si la mejora se sostiene: tamaño, diseño, suspensión o compromiso de servicio.

Trabajo equivalente

Qué consulta, datos y resultado funcional se mantienen comparables. Devolver menos información no demuestra hacer antes el mismo trabajo.

Estado de reutilización

Qué sabemos sobre resultados persistidos y caché de datos en cada observación, y qué sigue sin comprobarse.

Condiciones de servicio

Qué concurrencia, pausas y patrón de llegada representa la muestra, con cuántas observaciones y durante qué período.

Resultado y coste

Qué tiempos se midieron, cómo varían y qué consumo queda dentro del perímetro económico de la comparación.

Aplicada al ejemplo de doce segundos frente a uno, la ficha puede concluir algo menos vistoso y bastante más útil: «La repetición respondió antes; todavía no hemos aislado el efecto del cambio». Eso no invalida la observación ni obliga a tirar el trabajo. Evita vender una atribución que la prueba aún no sostiene.

Una ficha completa tampoco elimina por sí sola la variabilidad. Si el resultado depende de una única ejecución excepcional o de una carga que nadie utiliza, seguirá faltando evidencia. El documento ayuda a localizar esa carencia; no la rellena.

La caché también tiene una conversación económica

Mantener un warehouse activo para conservar datos en caché implica consumir créditos durante los intervalos sin consultas. La documentación de Snowflake pone precisamente el ejemplo de consultas cada treinta minutos y una suspensión a los diez: se paga tiempo ocioso y la caché se pierde antes de la siguiente consulta. Es un ejemplo del proveedor sobre ese patrón, no una configuración universal recomendada.

El ahorro de tiempo y el ahorro de dinero merecen columnas separadas. Un servicio puede responder antes y costar más, y aun así compensar si mejora una decisión importante. También puede dar una cifra espectacular en una prueba y no cambiar nada relevante para sus usuarios. Como vimos al analizar qué servicio sostiene la factura de Snowflake, hace falta relacionar el consumo con una necesidad concreta.

Antes de celebrar la siguiente captura, conviene poder completar esta frase: «Hemos mejorado este comportamiento, en estas condiciones, con este coste». Si solo sabemos que la segunda vez fue más rápida, todavía tenemos una pista. Una buena pista merece investigación, no una diapositiva que prometa más de lo que medimos.