Shirakami: A Hybrid Concurrency Control Protocol for Tsurugi Relational Database System

El artículo presenta Shirakami, un nuevo protocolo de control de concurrencia híbrido implementado en el sistema de base de datos Tsurugi que combina protocolos para transacciones largas y cortas para ofrecer un rendimiento estable y superior en comparación con PostgreSQL al manejar cargas de trabajo mixtas.

Lo esencial

Imagina que un sistema de base de datos es como una gran cocina de restaurante muy ocupada.

En esta cocina, hay dos tipos de chefs trabajando al mismo tiempo:

1. Los "Chefs Express" (Transacciones Cortas): Son como los camareros que piden un café, un sándwich rápido o una ensalada. Quieren su plato en segundos, sin esperar a que nadie más termine.
2. Los "Chefs Maestros" (Transacciones Largas): Son los que están preparando un banquete gigante, una paella para 500 personas o un pastel de bodas complejo. Tardan mucho tiempo, necesitan muchos ingredientes y no pueden parar a mitad de camino.

El Problema: El Caos en la Cocina

En la mayoría de los restaurantes (las bases de datos tradicionales como PostgreSQL), hay un problema grave cuando estos dos tipos de chefs trabajan juntos:

• Si el Chef Maestro está preparando la salsa para el banquete y necesita usar la sartén, el Chef Express no puede usarla.
• Si el Chef Express intenta usar la sartén mientras el Maestro está ahí, el Maestro tiene que esperar.
• El resultado: El Chef Maestro se queda atascado esperando al Chef Express, y el Chef Express se queda esperando al Maestro. La cocina se llena de gente gritando, platos caídos y, en el peor de los casos, el Chef Maestro tiene que tirar toda su comida a la basura (abortar la transacción) y empezar de nuevo porque alguien le tocó un ingrediente.

Esto es lo que pasa en las bases de datos actuales: las tareas largas (como calcular la factura de un mes entero de teléfono o el costo de todos los ingredientes de una fábrica) se bloquean constantemente por las tareas rápidas, o viceversa.

La Solución: Shirakami (El Nuevo Jefe de Cocina)

Los autores del artículo proponen un nuevo sistema llamado Shirakami. Imagina a Shirakami como un Jefe de Cocina súper inteligente que tiene un plan maestro para que ambos tipos de chefs trabajen sin chocar.

Shirakami no usa un solo método para todos. Usa una estrategia híbrida con dos reglas diferentes:

1. La Regla del "Chef Maestro" (Shirakami-LTX)

Para las tareas largas (como calcular facturas de teléfono), Shirakami les da un pase VIP.

• La Analogía: Imagina que el Chef Maestro entra a la cocina y anuncia: "¡Voy a usar la sartén de la salsa y la nevera de los vegetales durante los próximos 10 minutos!".
• La Magia: En lugar de esperar a que termine, el sistema marca esos ingredientes como "reservados para el futuro".
• El Truco: Si un Chef Express llega y ve que esos ingredientes están reservados, el Chef Express no entra en pánico. Simplemente espera un segundo, mira otra cosa o se va a hacer otra tarea. No necesita esperar a que el Maestro termine todo el banquete.
• Resultado: El Maestro puede trabajar en su gran banquete sin que los Express lo molesten, y los Express no se quedan atascados esperando al Maestro.

2. La Regla del "Chef Express" (Shirakami-OCC)

Para las tareas rápidas (como pedir un café), Shirakami usa un método de velocidad y confianza.

• La Analogía: El Chef Express toma sus ingredientes, cocina su plato rápido y, justo antes de servirlo, verifica: "¿Alguien tocó mis ingredientes mientras yo cocinaba?".
• La Magia: Si nadie los tocó, ¡listo! Se sirve el plato. Si alguien sí los tocó (un conflicto), el Chef Express simplemente tira su plato y lo hace de nuevo en un segundo.
• Resultado: Como las tareas son muy cortas, es muy raro que tengan que empezar de nuevo. Son extremadamente rápidas.

¿Cómo se llevan bien? (La Sincronización)

Lo genial de Shirakami es que no tiene que cambiar de estrategia a mitad de la jornada.

• Usa un sistema de "Epocas" (como turnos de trabajo).
• Si un Chef Maestro empieza un turno, se le da prioridad.
• Si un Chef Express intenta hacer algo que choca con el Maestro, el sistema le dice: "Oye, el Maestro tiene prioridad, inténtalo en el siguiente turno".
• Además, Shirakami tiene un truco llamado "Reenvío de Orden". Imagina que el Chef Maestro y el Chef Express necesitan usar la misma cuchara. En lugar de que uno gane y el otro pierda, el sistema reorganiza el orden: "Ok, tú usas la cuchara primero, y luego él la usa". Así, ambos pueden terminar su trabajo sin tirar nada a la basura.

Los Resultados: ¡Es un éxito!

Los autores probaron este sistema en un banco de datos real llamado Tsurugi (que significa "Espada" en japonés, ¡muy rápido!).

• En la prueba de Facturación Telefónica: Tsurugi fue 19.7 veces más rápido que la competencia (PostgreSQL). Mientras la competencia se ahogaba en esperas, Tsurugi facturaba a toda velocidad.
• En la prueba de Costos de Fábrica (BOM): Fue 5.6 veces más rápido.
• La prueba de fuego: Cuando compararon solo la capacidad de manejar tareas largas, el sistema de Shirakami fue 680 veces más eficiente que el sistema antiguo.

En Resumen

Shirakami es como un director de tráfico inteligente que sabe que en la ciudad hay tanto coches de carreras (transacciones rápidas) como camiones de mudanza (transacciones largas). En lugar de ponerlos todos en la misma fila y causar un atasco, le da al camión un carril especial y a los coches de carreras un carril rápido, asegurando que nadie se choque y que todos lleguen a tiempo.

Es una solución perfecta para el mundo real, donde necesitamos hacer cosas rápidas (pedir un café) y cosas grandes (calcular la nómina de toda una empresa) al mismo tiempo, sin que una detenga a la otra.

Resumen técnico

Resumen Técnico: Shirakami y Tsurugi

1. El Problema: Cargas de Trabajo Híbridas no Atendidas

Las aplicaciones modernas de bases de datos, como la gestión de Listas de Materiales (BoM) en la industria manufacturera y el facturación de telecomunicaciones, enfrentan un desafío único: deben procesar simultáneamente dos tipos de transacciones con requisitos contradictorios:

• Transacciones Cortas: Operaciones rápidas, intermitentes y de alta concurrencia (ej. actualizaciones de precios de materias primas, registro de llamadas en tiempo real).
• Transacciones Largas (Read-Write): Procesos analíticos o de lotes (batch) que escanean grandes volúmenes de datos, realizan cálculos complejos y escriben resultados masivos (ej. cálculo de costos de productos, facturación mensual).

Limitaciones de los protocolos actuales:

• Los protocolos convencionales basados en Serializabilidad de Conflicto (CSR) o OCC (Control de Concurrencia Optimista) como Silo o ERMIA fallan con transacciones largas. Tienen un espacio de programación limitado, lo que provoca una alta tasa de abortos (falsos positivos) cuando las transacciones largas compiten con las cortas.
• Los protocolos Deterministas son eficientes para transacciones largas pero no soportan consultas SQL con subconsultas dinámicas (comunes en bases de datos reales) y no son adecuados para transacciones cortas de alta concurrencia.
• Sistemas como Oze o Tuskflow abordan transacciones largas pero carecen de implementación en sistemas de producción o están limitados a grafos, no a bases de datos relacionales generales.

2. Metodología: El Protocolo Híbrido Shirakami

Los autores proponen Shirakami, un protocolo de control de concurrencia híbrido diseñado para integrarse en Tsurugi, un sistema de base de datos relacional de grado productivo. Shirakami combina dos sub-protocolos que operan concurrentemente sin necesidad de conmutación dinámica:

• Shirakami-OCC (S-OCC): Basado en el protocolo Silo, optimizado para transacciones cortas. Utiliza técnicas de lectura invisible y commits paralelos.
• Shirakami-LTX (S-LTX): Un nuevo protocolo diseñado para transacciones largas basado en Serializabilidad de Vista Multiversión (MVSR).

Mecanismos Clave de Integración:

1. Preservación de Escritura (Write Preservation - WP):

   • Las transacciones largas (S-LTX) declaran el área de datos que escribirán al inicio de su ejecución (a nivel de tabla).
   • Esta declaración actúa como una "advertencia" para las transacciones cortas (S-OCC). Si una transacción corta detecta que lee datos que una transacción larga planea escribir, puede abortar proactivamente antes de llegar a la fase de validación, evitando conflictos costosos y bloqueos.

2. Sincronización Basada en Épocas (Epoch-based Synchronization):

   • El sistema gestiona transacciones en bloques de tiempo llamados "épocas".
   • Prioridad: Las transacciones S-LTX tienen prioridad sobre las S-OCC. Una transacción larga comienza en una época específica y se asegura de que todas las transacciones cortas concurrentes se serialicen después de ella (o en épocas posteriores), garantizando que las largas no sean bloqueadas por las cortas.

3. Reenvío de Orden (Order Forwarding):

   • Este es el mecanismo más innovador de S-LTX. Permite cambiar dinámicamente el orden de serialización.
   • Si una transacción de baja prioridad (dentro de S-LTX) lee datos escritos por una de alta prioridad, el sistema puede "reenviar" el orden, permitiendo que la transacción de baja prioridad se comprometa antes que la de alta prioridad dentro de la misma época.
   • Esto expande el espacio de programación más allá de la serializabilidad de conflicto tradicional, reduciendo drásticamente los abortos innecesarios.

4. Manejo de Lecturas Fantasma:

   • Se implementan mecanismos específicos para evitar lecturas fantasma en ambos protocolos, asegurando que las transacciones cortas no vean estados inconsistentes generados por transacciones largas en proceso de reordenamiento.

3. Contribuciones Clave

• Primera implementación productiva de MVSR: Shirakami es la primera implementación a nivel de producción que utiliza el amplio espacio de programación de la Serializabilidad de Vista Multiversión (MVSR) para transacciones largas en un sistema relacional general.
• Coexistencia sin degradación: Logra que las transacciones largas y cortas coexistan sin que las largas sean abortadas repetidamente por las cortas, ni que las cortas sufran latencia excesiva.
• Soporte SQL Completo: A diferencia de los enfoques deterministas, Shirakami soporta SQL completo, incluidas subconsultas, gracias a su naturaleza no determinista controlada.
• Arquitectura Tsurugi: Presentan Tsurugi, un sistema de base de datos relacional de memoria principal (main-memory) con arquitectura modular (índices Yakushima, motor SQL Jogasaki, almacenamiento de logs Limestone) que implementa Shirakami.

4. Resultados Experimentales

Los autores evaluaron el sistema en dos escenarios principales:

A. Comparativa con PostgreSQL (Benchmarks de Producción):

• Facturación de Telecomunicaciones: Tsurugi (con Shirakami) mostró una latencia 19.7 veces menor que PostgreSQL al procesar transacciones de lotes largas bajo carga de transacciones cortas. PostgreSQL no pudo completar la prueba con 64 hilos dentro del límite de tiempo.
• Lista de Materiales (BoM): Tsurugi fue 5.6 veces más rápido que PostgreSQL. Cuando PostgreSQL se configuró en un nivel de aislamiento más bajo (READ COMMITTED) para ser más rápido, generó anomalías de datos inaceptables.

B. Comparativa Interna (S-LTX vs. S-OCC):

• Utilizando una carga de trabajo basada en YCSB-E con transacciones largas y cortas mezcladas:
  • S-LTX logró un rendimiento (throughput) 680 veces mayor que S-OCC para las transacciones largas.
  • Mientras que S-OCC fallaba en comprometer transacciones largas a medida que aumentaba su longitud (debido a conflictos), S-LTX mantenía una tasa de éxito estable incluso con transacciones de miles de operaciones.

5. Significado e Impacto

El trabajo de Shirakami es significativo porque resuelve una brecha crítica en la ingeniería de bases de datos: la incapacidad de los sistemas actuales para manejar cargas de trabajo mixtas (HTAP - Procesamiento Transaccional y Analítico Híbrido) de manera eficiente en un solo motor.

• Eliminación de la separación nocturna: Permite que las empresas ejecuten procesos de lotes pesados (como facturación o cálculo de costos) en tiempo real, sin necesidad de detener las operaciones diarias o ejecutarlos en ventanas nocturnas separadas.
• Eficiencia de Recursos: Al reducir drásticamente los abortos de transacciones largas, se optimiza el uso de CPU y memoria, evitando el desperdicio de ciclos de procesamiento.
• Viabilidad Industrial: Al ser parte de un sistema de grado productivo (Tsurugi), demuestra que las teorías avanzadas de control de concurrencia (como MVSR y reenvío de orden) pueden implementarse de manera robusta en entornos reales, superando las limitaciones de los sistemas comerciales actuales como PostgreSQL o las soluciones puramente deterministas.

En conclusión, Shirakami establece un nuevo estándar para el control de concurrencia en bases de datos relacionales modernas, permitiendo una escalabilidad superior en entornos donde la latencia y el procesamiento de grandes volúmenes de datos deben coexistir.