Un proceso de ETL, que hace dos años tardaba un par de horas, acababa de superar la temida barrera de las 22 horas de ejecución. Se estaba solapando con el ciclo del día siguiente. Nuestro Data Warehouse ha chocado violentamente contra el muro físico del rendimiento.

La respuesta corporativa clásica siempre ha sido tirar de chequera: "compra un servidor más grande". Pero cuando ya tienes una bestia de 64 núcleos y medio terabyte de RAM en formato SMP (Symmetric Multiprocessing), el siguiente salto de hardware cuesta lo mismo que un yate. Tenemos que cambiar de arquitectura.

Scale-Up vs Scale-Out: El problema de las filas

Las bases de datos relacionales tradicionales (Oracle, SQL Server, MySQL) guardan los datos en el disco duro orientados a filas. Si yo hago un SELECT SUM(Ventas) FROM Facturacion, el disco duro tiene que leer la fila entera (incluyendo el ID de cliente, la dirección, el texto de observaciones) solo para extraer el número de la venta y sumarlo. Es un desperdicio brutal de I/O de disco.

La solución que estamos investigando es cambiar el paradigma hacia el almacenamiento columnar y las arquitecturas MPP (Massively Parallel Processing). En un modelo columnar, todos los valores de la columna "Ventas" se guardan físicamente juntos en el disco. Al leerlos, ignoras el resto de columnas, y al ser datos del mismo tipo numérico, los algoritmos de compresión hacen magia.

En SQL Server 2012 introdujeron tímidamente los índices "Columnstore", y estoy probándolos ahora mismo:

-- Creando un índice columnar no agrupado sobre nuestra gigantesca tabla de hechos
CREATE NONCLUSTERED COLUMNSTORE INDEX NCCI_Fact_Ventas 
ON Fact_Ventas (
    FechaKey,
    ProductoKey,
    ClienteKey,
    ImporteVenta,
    Cantidad
);

-- Una consulta analítica típica que antes leía 50 GB del disco
SELECT 
    ProductoKey, 
    SUM(ImporteVenta) 
FROM Fact_Ventas 
GROUP BY ProductoKey;

La diferencia es absurda. La misma consulta que antes tardaba 40 minutos haciendo un barrido completo de la tabla, ahora baja a unos 12 segundos porque el motor lee los datos altamente comprimidos directamente a la caché de la CPU mediante procesamiento por lotes (Batch Mode).

Reflexión: La muerte del servidor único

La arquitectura de "una sola máquina gigantesca" está obsoleta para la analítica de datos. Herramientas como Apache Spark, que vimos hace poco, y las bases de datos MPP como Teradata o el incipiente Amazon Redshift nos marcan el camino.

El futuro pasa por distribuir (Scale-Out). En lugar de un servidor de 100.000 euros, conectas veinte servidores baratos de 5.000 euros y repartes los datos entre ellos. El reto para los que venimos del SQL tradicional es que desarrollar sobre sistemas distribuidos implica pelearse con la latencia de red, la distribución de claves (sharding) y bloqueos distribuidos. Escalar horizontalmente soluciona el problema del hardware, pero multiplica por diez la complejidad del software.