Muchos Mitos

Como comentaba hace un tiempo, estoy trabajando con Sql Server. Eso no solo implica cambiar de motor y olvidar algunas cosas que en Oracle estaban desde la década pasada (me olvidaba de una en el post anterior: poder hacer inserts masivos desde variables en memoria, y poder hacer updates masivos a secas), sino también cambiar de comunidad, leer otros libros, otros blogs, hablar con otra gente.

Además de mi pequeño berrinche por perder algunas features que me han gustado, he notado algo peor: la comunidad de Sql Server es notablemente más pobre que la comunidad de Oracle. Y no lo digo porque no haya personas como Tom Kyte, Craig Shallahamer, Jonathan Lewis o Cary Millsap (porque, por ejemplo, Kalen Delaney evidentemente sabe de que habla), sino porque hay un concepto que en la comunidad de Oracle está bastante claro y que la de Sql Server no parece haber descubierto: la gestión de performance por índices agregados no sirve. Pareciera a veces que a los muchachos de Sql Server les falta leer a Neil Gunther.

Los libros de performance de Sql Server que estoy leyendo insisten, todos, con la vieja y ridícula idea de hacer una linea base de indicadores cuando tu sistema anda bien y luego detectar desvíos sobre esos indicadores, así, de alguna manera, detectarías los problemas de performance antes de que sucedan viendo los síntomas antes de que se manifiesten en el ambiente productivo. Y cuando tenés un desvío, apretás el botón rojo ponés la batiseñal en el cielo y al rato vienen superman y linterna verde (bueno, nadie es perfecto) a rescatarte.

Esta idea tiene varios problemas. Diría que esta idea solo tiene problemas. Y en todos los niveles. Empecemos.

Primero, establecer una linea base de indicadores cuando tu sistema anda bien es una quimera, por varias razones: a veces llegás, como consultor experto en performance, como DBA, como arquitecto, como galeote o lo que fuera a algún lugar donde, si las cosas anduvieron bien, vos jamás las viste. Otras, el sistema cambia lo suficiente como para que la línea base se desactualice antes de que tenga validez estadística (esto implica mayor funcionalidad que implica más carga que requiere una actualización en hardware: o dicho de otra manera, el software cambia). Y a veces (esto es particularmente cierto en las puntocom), no se necesita que cambie el sistema, tan solo cambia el patrón de uso por alguna condición comercial o del entorno.

Otro problema tiene que ver con que el conjunto de indicadores de un sistema corriendo no es un sistema de ecuaciones con solución única. Es decir, que un sistema puede andar bien con varias combinaciones de indicadores. El único indicador razonable para medir la performance es el tiempo de respuesta en relación a la carga de trabajo: si el resto cambia pero mi tiempo de respuesta es razonable, entonces está bien independientemente de lo que diga el hit ratio, la tasa de inserción, la cantidad de log file syncs (o como se llamen en Sql Server) o lo que fuera.

Por último (cerrando los problemas que se me ocurren ahora, no pienso poder abarcarlos todos), muchas veces los indicadores no sirven para nada. El indicador más exitoso en esto de no tener ninguna utilidad práctica es el hit ratio (calculo que porque es el más fácil e intuitivo). Cary Millsap explica por qué el hit ratio no es un buen indicador, demostrando que un hit ratio muy alto puede ser problemático. Particularmente nunca vi un caso así, pero sí vi bases con hit ratios 'bajos' (de alrededor del 70%) que soportaban sistemas que escalaban muy bien y con excelente tiempos de respuesta.

El problema con el hit ratio es el viejo problema de confundir correlación con causalidad. A veces, ciertos problemas que degradan la escalabilidad y los tiempos de respuesta, también bajan el hit ratio, lo que no quiere decir que todos los problemas de performance lo hagan ni que un hit ratio menor al 90% solo pueda ser causado por algún problema. Lo mismo se aplica a cualquier indicador.

Millsap usa el siguiente ejemplo: supongamos dos conjuntos de consultas que obtienen exactamente el mismo conjunto de datos. El primero luego de correr en un sistema tiene un 99% de hit ratio y el segundo un hit ratio de 90%. Es mejor el primero?. Depende: supongamos que el primero hizo 10000 lecturas (entre lógicas y físicas) y el segundo 100. Millsap aclara que "el hecho de que acceder a memoria sea 10000 veces más rápido que acceder a disco no significa que una lectura lógica (resuelta en el caché) sea 10000 veces más rápida que una lectura física (en los datafiles)". Más aún, si tenemos consultas que leen inecesariamente una y otra vez los mismos bloques, el hit ratio será alto.

Por supuesto, mis rápidos comentarios sobre el artículo de Millsap no son excusa para no leerlo. Incluso si no se trabaja con Oracle, los conceptos se aplican a cualquier base de datos.

Resumiendo, los mejores indicadores (debería decir 'únicos indicadores') de la performance de un sistema son sus tiempos de respuesta y su capacidad de escalar, no un hit ratio o una esotérica combinación de indicadores. Ignoro cuanto tiempo tardará la comunidad de Sql Server en darse cuenta de esto. Tal vez cuando tengan que soportar un volumen realmente alto.