⚙️Motores de bases de datos: OLTP vs OLAP

Hoy vamos a hablar de algo un poco más amplio: los motores de bases de datos. A grandes rasgos, los podemos dividir en dos grandes categorías:

• OLTP (procesamiento de transacciones online): los que están optimizados para procesar transacciones.

• OLAP (procesamiento analítico online): los que están optimizados para analíticas.

Y sí, los patrones de acceso a datos en uno y otro son muy diferentes.

OLTP: lo que maneja el usuario

Los sistemas OLTP suelen ser los que están de cara al usuario. Tienen que manejar muchas peticiones a la vez, así que las queries suelen pedir pocos registros, casi siempre por clave, para que el motor pueda usar un índice y responder rápido.

Aquí el cuello de botella suele estar en el tiempo que tarda el disco en buscar el dato exacto.

Dentro de este mundo OLTP hay dos formas comunes de organizar el almacenamiento:

• Estructura tipo log: no se sobreescriben ficheros, solo se añaden. Luego se eliminan ficheros obsoletos. Ejemplos: SSTables, LSM-trees, LevelDB, Cassandra, HBase, Lucene...

• Update-in-place: se sobreescriben páginas concretas en disco. El ejemplo clásico: B-trees, usados en la mayoría de bases de datos relacionales y muchas no relacionales también.

La ventaja de las estructuras tipo log es que convierten escrituras aleatorias en escrituras secuenciales, lo que es mucho más eficiente para escrituras en discos y SSDs. Por eso han ido ganando fama en los últimos años.

Si la estructura tipo log va a ofrecer un mejor rendimiento en las escrituras, la estructura con update-in-place va a hacerlo en lecturas.

OLAP: lo que manejan los analistas

Aquí ya no estamos hablando de miles de usuarios haciendo clics, sino de almacenes de datos o warehouses y otros sistemas de analíticas menos conocidos que utilizan los analistas de negocios. Los sistemas OLAP manejan muchas menos queries, pero cada una escanea millones de filas.

En estos casos el cuello de botella no es el tiempo de búsqueda, sino el ancho de banda del disco: cuántos datos puedes leer por segundo.

¿Y qué pasa con los índices?

Cuando tus queries requieren escanear secuencialmente una gran cantidad de filas, los índices dejan de ser tan relevantes. En cambio, se convierte mucho más valioso el poder codificar los datos de forma compacta y así poder minimizar la cantidad de datos que necesita la query leer del disco.

Por eso, en estos sistemas ha triunfado el almacenamiento por columnas. Permite leer solo las columnas necesarias, y además compactar los datos. Dado que en una misma columna van a haber muchos registros con el mismo valor, es mucho más facil compactar dichos datos. Esto hace que las queries vayan mucho más rápido.

Así quedaría una base de datos en base a columnas en vez de filas:

Y así quedaría comprimida utilizando bitmap encoding para una sola columna:

Tabla resumen