MariaDB ha comenzado a implementar ejecución paralela de consultas —un cambio arquitectónico notable— y lo ha explicado en el primer episodio de Inner Join, su nueva serie de vídeo con ingenieros del equipo central. Oleg Smirnov, del equipo de Optimizer, detalla por qué la base de datos ha ejecutado históricamente cada consulta en un solo hilo, qué motivó el cambio y cómo funciona la aproximación inicial bajo el capó.
Qué cambia: dividir un query entre varios trabajadores
Hasta ahora MariaDB Server ejecutaba cada consulta en un único hilo. El equipo está desarrollando la capacidad de fragmentar la tarea y procesar partes en paralelo sobre varios núcleos. La idea práctica es dividir la lectura de una tabla grande en “trozos” (chunks), asignar cada trozo a un worker que realice el join, el filtrado y la agregación sobre su porción, y luego juntar las salidas parciales en un resultado final. La simultaneidad de esos workers es la fuente del posible aumento de rendimiento.
Cómo lo implementan: chunking e integración con InnoDB
La implementación inicial se centra en InnoDB, el motor de almacenamiento más usado en entornos de producción. Para partir la tabla se aprovecha la estructura de índice agrupado (B-tree) de InnoDB: el código lee la página raíz y crea un chunk por entrada que encuentra allí. Esas entradas suelen ser suficientes para generar más unidades de trabajo que núcleos disponibles, y si no es así el sistema puede redividir los chunks bajando un nivel en el árbol y generando sub-chunks más pequeños.
Los chunks se colocan en una cola de tareas; cada worker extrae el siguiente chunk y lo procesa. Si detecta que el chunk es demasiado grande frente al número de workers o provoca desequilibrios (por ejemplo, muchos workers inactivos), lo vuelve a dividir. Esa redivisión dinámica es la clave para equilibrar la carga y evitar que algunos núcleos queden ociosos.
Limitaciones y comportamiento actual
Los ingenieros subrayan que la ejecución paralela todavía está en desarrollo y no ha sido lanzada como versión estable. Además, hay matices funcionales: las consultas que requieren un orden determinado (ORDER BY), funciones de ventana u otras operaciones dependientes del orden pueden no paralelizarse en esta fase o bien aplicar la ordenación al conjunto resultante tras la fusión de partes parciales. Los resultados de una ejecución paralela pueden llegar en distinto orden que una ejecución serial; para muchas consultas esto es aceptable, pero para las que exigen orden sí hay consideraciones adicionales.
Quién trabaja en ello y por qué importa
El trabajo fue dividido entre ingenieros: uno centrado en la capa SQL (workers, joins y agregaciones) y otro en la capa de almacenamiento (cómo generar y gestionar los chunks). El objetivo es moderno: aprovechar servidores con muchos núcleos para que una única consulta pueda usar varios de ellos y así reducir latencias y tiempos de respuesta de consultas pesadas.
Qué deben hacer administradores y desarrolladores
Por ahora no hay una acción inmediata obligatoria: la ejecución paralela está en desarrollo y aún no se distribuye en una versión estable. Administradores y propietarios de webs deben seguir los canales oficiales de MariaDB para recibir avisos de lanzamiento y notas técnicas. Cuando la función llegue a versiones públicas, las tareas habituales serán revisar compatibilidad con el motor InnoDB, probar cargas reales en entornos de preproducción y medir mejoras y comportamientos en consultas con ORDER BY o funciones de ventana, además de ajustar parámetros de paralelismo según la arquitectura de CPU del servidor.
La explicación completa y técnica está disponible en el episodio de Inner Join publicado por MariaDB Foundation en su canal de vídeo.
Lee también:
- Fedora Linux 45 se lanza el 3 de noviembre: novedades y qué deben hacer los administradores
- Altera presenta Agilex 27, su primer FPGA Agilex 2X con 800GbE y preparación para 1.6TbE
Fuente: MariaDB.org
