El Panda Index de Alibaba otorga a las claves únicas de InnoDB un historial de versiones que nunca tuvieron

Las claves únicas son el cuello de botella silencioso de las bases de datos en línea. Los ID de pedido, los números de teléfono y los números de serie de transacciones dependen de los índices de clave única (UK) para mantenerse sin duplicados, y bajo alta concurrencia la aplicación de esa restricción empieza a costar. En InnoDB, el motor detrás de MySQL y del PolarDB-X compatible con MySQL de Alibaba, el problema es estructural: los índices secundarios no llevan información de versión, por lo que el motor compensa con bloqueos de intervalo y búsquedas en tabla.

El equipo de PolarDB-X de Alibaba ha publicado una solución. Panda Index, un índice UK de nueva generación para los nodos de datos del motor, otorga a las claves únicas capacidad nativa de múltiples versiones con columnas de transacción y una cadena undo independiente en cada registro. La publicación técnica del equipo de ApsaraDB describe una ruta de inserción más simple y auténticos escaneos solo de índice.

El cuello de botella de las claves únicas en InnoDB

PolarDB-X es una base de datos distribuida sobre una arquitectura unificada centralizada y distribuida, totalmente compatible con MySQL, con un almacén de filas que gestiona OLTP en cada nodo de datos. El índice agrupado de InnoDB gestiona el historial de la forma estándar: cada registro lleva un TRX_ID y un ROLL_PTR hacia una cadena undo, las actualizaciones se realizan in situ y el árbol B+ conserva solo la versión más reciente. Los índices secundarios no reciben nada de eso. Los registros UK no llevan TRX_ID, ni ROLL_PTR, ni información de versión.

Así, una actualización de clave única utiliza el enfoque de marcar-eliminar-luego-insertar: el motor marca el registro antiguo como eliminado y luego inserta uno nuevo. Hasta que se ejecuta el hilo de purga, varios registros físicos con la misma clave coexisten en el índice. Eso rompe la aplicación de la unicidad de dos maneras.

El primer problema es el bloqueo. La detección de conflictos de inserción no puede distinguir cuál de los varios registros que comparten una clave está activo, así que los escanea todos y coloca bloqueos de intervalo sobre el rango completo. Transacciones lógicamente no conflictivas terminan esperándose entre sí, a veces con interbloqueos. El problema es especialmente agudo en sistemas de trading, deducciones de saldo y ventas flash, señalan los ingenieros de ApsaraDB.

El segundo es la visibilidad. Sin información de versión en los registros UK, una lectura MVCC no puede juzgar la visibilidad por sí sola, incluso cuando el índice cubre todas las columnas de la consulta. Debe volver al índice agrupado y recorrer la cadena undo, al igual que la detección de bloqueos implícitos y la purga. Las cargas de trabajo con muchas escrituras añaden una tercera penalización: la purga se retrasa respecto a las eliminaciones, y los registros residuales marcados como eliminados amplían el rango de escaneo de la siguiente comprobación de conflictos.

Dentro de Panda Index: cuatro columnas de sistema y una cadena undo independiente

Panda Index traslada el versionado del índice agrupado al índice UK. Cada registro incorpora cuatro columnas de sistema: TRX_ID, el ID de transacción de la modificación más reciente; ROLL_PTR, un puntero a un registro undo independiente; SCN, un número de secuencia de commit del sistema de transacciones Lizard; y UBA, una dirección de bloque undo. Su semántica coincide con la de los registros del índice agrupado, por lo que el motor reutiliza el marco de visibilidad existente de Lizard, Vision.

ROLL_PTR apunta a una cadena undo propiedad exclusiva del índice UK. Las actualizaciones se realizan in situ: sin marcar-eliminar-luego-insertar, un registro físico por clave única, y las versiones históricas se almacenan en un tablespace undo separado, accesible a través de ROLL_PTR sin búsqueda en tabla. El DML hacia adelante, el rollback y la purga siguen cada uno una lógica dedicada, lo que desacopla el ciclo de vida de versiones del índice UK respecto al del índice agrupado.

Un solo bloqueo de registro en lugar de una fila de bloqueos de intervalo

Las actualizaciones in situ producen un efecto secundario útil: como máximo existe un registro físico por clave única. La detección de conflictos de inserción se reduce a una comprobación. Si no existe ningún registro, la inserción tiene éxito de inmediato. Si existe uno, el motor coloca un único bloqueo de registro sobre él y comprueba si está marcado como eliminado. Sin bloqueos de intervalo y con una huella de bloqueo mucho menor.

La publicación incluye un ejemplo resuelto. Una transacción elimina una fila donde c1 = 1 e inserta una nueva fila con el mismo valor; una segunda transacción inserta entonces c1 = 2, que no entra en conflicto. Bajo el comportamiento estándar de InnoDB, la segunda inserción agota el tiempo de espera, con cuatro bloqueos en el índice, tres de ellos bloqueos de intervalo. Bajo Panda Index, tiene éxito de inmediato con un único bloqueo de registro X,REC_NOT_GAP.

La visibilidad recibe la misma simplificación: las lecturas consistentes se completan dentro del árbol B+ del índice, las consultas con índice de cobertura obtienen auténticos escaneos solo de índice, y la detección de bloqueos implícitos ya no alcanza el índice agrupado.

El beneficio de la alta concurrencia y lo que aún falta

El cambio alinea la gestión de versiones de UK con el índice agrupado, algo que InnoDB ya maneja bien. Alibaba ha publicado resultados de trabajos afines sobre índices de bases de datos: la compresión de prefijos secundarios de PolarDB-X redujo el espacio de índice entre un 30 y un 70 por ciento, con ganancias de rendimiento de hasta un 47 por ciento en sysbench bajo presión de E/S, y la ingeniería de índices vectoriales de PolarDB informó construcciones y consultas entre 1,5 y 2 veces más rápidas, con la contención de E/S reducida en un 90 por ciento.

Panda Index en sí no tiene aún cifras publicadas. La publicación no incluye pruebas de referencia, y la evidencia de la tabla de bloqueos cubre un único escenario construido a mano. Cuatro columnas de sistema adicionales y una segunda cadena undo añaden su propio overhead de almacenamiento y purga, y si esos costos se mantienen estables bajo escrituras intensivas en UK es algo que solo las mediciones pueden responder. El resumen honesto: el mecanismo parece correcto, y la base de evidencia es la propia de Alibaba.