Tu informe tarda 40 minutos: qué es un índice y por qué lo cambia todo

Pides el informe de ventas del mes y esperas. Cuarenta minutos después, por fin sale. Un compañero de otra empresa, con un negocio parecido y datos parecidos, pide el mismo tipo de informe y lo tiene en dos segundos. Nadie te ha explicado por qué, y la primera reacción suele ser pensar en el servidor: que hace falta uno más potente, más caro, con más memoria. Casi nunca es eso.

#La analogía del libro sin índice

Imagina un libro de mil páginas sin índice al final ni tabla de contenidos al principio. Si alguien te pide encontrar todas las veces que aparece una palabra concreta, solo hay una forma de hacerlo: leer el libro entero, página por página, de principio a fin. No importa lo rápido que leas: si el libro tiene mil páginas, vas a tener que pasar por las mil.

Eso es exactamente lo que hace una base de datos sin índices cuando le pides un informe: mira fila por fila, una detrás de otra, buscando las que cumplen lo que has pedido. Con pocas filas no se nota, igual que no se nota buscar una palabra en un cuento de diez páginas. El problema aparece cuando el libro deja de tener diez páginas y pasa a tener miles.

Y da igual, para esto, por cuál de las dos grandes familias se optara en su día al elegir dónde viven los datos, la decisión que se explicó aquí al hablar de SQL o NoSQL: las dos usan índices, y las dos se arrastran cuando falta el que hacía falta.

#Por qué el problema aparece de golpe

Lo que más sorprende de este problema es su calendario. El informe que hoy tarda dos segundos puede tardar cuarenta minutos dentro de un año sin que nadie haya tocado el sistema ni haya roto nada, porque lo único que ha cambiado por el camino es el tamaño de la tabla.

Con mil filas, buscar una por una es tan rápido que nadie lo nota. Con un millón tampoco se nota gran cosa: recorrerlas todas sigue siendo cuestión de décimas de segundo, y por eso mucha gente cree, con razón hasta cierto punto, que su sistema aguanta lo que le echen. El terreno cambia cuando la tabla llega a decenas de millones de filas, y sobre todo cuando el informe tiene que cruzar dos o tres tablas de ese tamaño entre sí: ahí cada fila de una obliga a rebuscar en las otras, la cuenta se multiplica, y el informe que antes salía al instante empieza a tardar minutos, y luego decenas de minutos. El negocio no ha cambiado de sistema. Ha cambiado de tamaño, y el sistema no estaba preparado para ese tamaño.

#El índice: la tabla de contenidos de los datos

Un índice es, para una base de datos, exactamente lo que la tabla de contenidos es para el libro: una lista ordenada que le dice al sistema, sin tener que leer todo lo demás, exactamente dónde está lo que se busca. En vez de recorrer fila por fila, la base de datos consulta ese índice y va directa al dato, igual que tú vas directo al capítulo cuatro sin pasar por los tres anteriores.

Crear un índice sobre la columna por la que se busca más a menudo —la fecha de una venta, el número de cliente, el código de un pedido— es, en la mayoría de los casos, la diferencia entre un informe de cuarenta minutos y uno de dos segundos, sin cambiar ni una línea del informe en sí. Solo cambia cómo de rápido encuentra el sistema lo que ya sabía buscar.

#Por qué a veces el informe de ayer iba bien y el de hoy no

Hay una variante de este mismo problema que confunde todavía más, porque parece que el sistema «se ha estropeado de repente». Un informe puede llevar meses saliendo rápido y, un día cualquiera, empezar a tardar minutos sin que nadie haya cambiado nada a propósito. Lo habitual no es una avería: es que la tabla ha cruzado, en algún punto, el umbral a partir del cual leerla entera deja de ser instantáneo. No hay un aviso previo de que se acerca ese umbral, ni una alarma que suene antes de cruzarlo. Simplemente, un día el informe tarda un poco más, y las siguientes semanas tarda cada vez más, porque la tabla sigue creciendo al mismo ritmo que el negocio.

Esto explica también por qué un informe puede funcionar perfectamente en las pruebas antes de lanzar un sistema nuevo y empezar a fallar meses después, ya en producción: en las pruebas, la tabla apenas tenía datos de ejemplo. En producción, crece con cada venta, cada cliente, cada pedido real, y antes o después alcanza el tamaño en el que la falta de un índice se nota.

#Por qué suele ser un arreglo barato

Revisar y añadir los índices que faltan suele costar horas de trabajo, no un cambio de infraestructura, y eso rara vez es lo que el negocio espera oír. Comparado con lo que la gente asume —que hace falta comprar un servidor más grande, o migrar a otro sistema entero—, es de largo la opción más barata y la que primero se debería probar. Comprar más máquina puede aliviar el síntoma un tiempo, pero si el problema real es que se está leyendo la tabla entera cada vez, tarde o temprano el negocio vuelve a crecer y el síntoma vuelve a aparecer.

#El precio de los índices: no son gratis

Un índice no es una solución mágica que se pueda poner en todas partes sin coste. Ocupa espacio en disco, porque guarda una copia ordenada de las columnas por las que se busca, más una referencia que apunta a la fila donde vive el resto del dato. No duplica la tabla entera —igual que la tabla de contenidos de un libro no repite el libro, solo los títulos y sus páginas—, pero sí ocupa, y con varios índices sobre la misma tabla ese espacio se suma. Y cada vez que se añade o modifica un dato, el sistema tiene que actualizar también ese índice, lo que hace las escrituras —dar de alta un pedido, registrar una venta— un poco más lentas de lo que serían sin él.

Por eso poner un índice en cada columna de cada tabla tampoco es la solución: se ganaría velocidad de lectura a cambio de perder velocidad de escritura, y de ocupar mucho más espacio del necesario. El criterio correcto es indexar las columnas por las que de verdad se busca a menudo —las que aparecen en los informes, en los filtros, en las búsquedas del día a día— y dejar en paz las demás.

#No todos los índices sirven igual

Otro matiz que conviene conocer, aunque sea sin entrar en detalle técnico: no basta con «tener un índice» en general, tiene que estar puesto sobre la columna correcta. Un informe que filtra por fecha de venta no se acelera si el único índice que existe está sobre el nombre del cliente. Es como tener la tabla de contenidos de un libro ordenada por tema cuando lo que se busca es un capítulo por número de página: la tabla existe, pero no ayuda a encontrar lo que hace falta. Por eso la revisión de índices no es un trámite de una sola vez: cada informe nuevo, cada filtro nuevo que se añade a una pantalla, puede necesitar su propio índice si se usa con frecuencia.

#La frase exacta para la próxima vez que un informe se atasque

Antes de plantear siquiera comprar más servidor, hay una pregunta concreta que hacer, y conviene hacerla con estas palabras: «¿por qué columnas se filtra este informe, y esas columnas tienen índice?». Si la respuesta es clara y ya está resuelta, el problema está en otro sitio. Si nadie lo ha revisado nunca, ahí suele estar la ganancia más barata y más rápida de conseguir.

#Cómo distinguir un problema de índices de uno de servidor

Hay una forma sencilla de saber en cuál de los dos casos estás: si el informe tarda mucho pero el servidor apenas usa recursos mientras lo genera —poco uso de procesador, poca memoria ocupada—, casi siempre es un problema de cómo se busca el dato, no de cuánta máquina hay detrás. Si en cambio el servidor va al límite de su capacidad mientras el informe corre, ahí sí puede haber un problema real de infraestructura. La mayoría de las veces que alguien pide «un servidor más grande» para arreglar un informe lento, lo que realmente hacía falta era mirar los índices primero.