Optimización de Transacciones Distribuidas en PolarDB-X: Parte 2

Optimización de Transacciones Distribuidas en PolarDB-X: Parte 2

Este artículo se centra en cómo PolarDB-X optimiza los commits de transacciones distribuidas utilizando el sistema de transacciones Lizard, con el objetivo de reducir la latencia mientras se mantiene la corrección. En la primera parte de esta serie, discutimos cómo eliminamos el paso del registro de transacciones, reduciendo la latencia de los commits distribuidos a tres tiempos de ida y vuelta (RTTs) y dos operaciones de persistencia de datos, siendo el primer RTT (obtener el prepare_gcn) opcional.

Ahora, abordaremos los detalles de implementación de la optimización del commit, haciendo hincapié en los desafíos y dificultades encontrados durante su despliegue. Recapitulemos lo que hemos logrado hasta ahora.

Desafíos en la Optimización de Lecturas de Un Solo Shard

Durante la implementación de la optimización del commit, uno de los problemas más desafiantes fue la optimización de las lecturas de un solo shard. En PolarDB para Xscale (PolarDB-X), si una instrucción de lectura autocommit afecta solo a un shard, se omite la obtención de un snapshot_gcn del servicio de metadatos global (GMS) y, en su lugar, se utiliza el max_gcn de ese shard como el snapshot_gcn de la lectura.

Esta optimización elimina un RTT hacia el GMS y mejora significativamente el rendimiento de lectura de un solo shard. Antes de la optimización del commit, las reglas de determinación de visibilidad para lecturas de un solo shard eran las siguientes:

• Si una lectura de un solo shard se encuentra con una transacción activa no confirmada, esa transacción es invisible.
• Si la lectura se encuentra con una transacción en fase de PREPARE, la lectura se bloquea hasta que la transacción alcance el COMMIT.
• Si la lectura se encuentra con una transacción COMMIT y el snapshot_gcn de la lectura es menor que el commit_gcn de la transacción, la transacción es invisible.
• Si el snapshot_gcn de la lectura es igual al commit_gcn, la transacción es visible.
• Si el snapshot_gcn de la lectura es mayor que el commit_gcn, la transacción es visible.

Estas reglas garantizaban que las lecturas de un solo shard mantuvieran tanto el aislamiento de instantáneas como la consistencia externa.

Complejidades Post-Optimización del Commit

Después de introducir la optimización del commit, la determinación de visibilidad para las lecturas de un solo shard se volvió más compleja. La optimización del commit permite que el commit_gcn final de una transacción se derive del max_gcn de un nodo de datos (DN), al igual que el snapshot_gcn de una lectura de un solo shard. Esto significa que cuando el snapshot_gcn de una lectura de un solo shard es igual al commit_gcn de una transacción de escritura, la garantía de que «la lectura de un solo shard ocurrió después del commit» ya no se mantiene necesariamente.

Para resolver esto, cuando una lectura de un solo shard se encuentra con una transacción optimizada para commit y el snapshot_gcn es igual al commit_gcn, la lectura recurre al flujo estándar de lectura distribuida: obtiene un snapshot_gcn del oráculo de tiempo (TSO) y luego realiza la lectura.

Resultados de la Optimización del Commit

Finalmente, después de abordar la optimización de lecturas de un solo shard y asegurar la compatibilidad con el ordenamiento del CDC, los resultados de la optimización del commit de transacciones se resumen en un escenario donde, en el caso predeterminado, un commit de transacción aún requiere tres RTTs y una operación de persistencia de datos. Sin embargo, con la optimización adecuada, un commit distribuido puede completarse con solo un RTT y una operación de persistencia de datos.

Pruebas de Rendimiento

Realizamos pruebas de rendimiento de la optimización del commit usando sysbench, centrándonos en dos escenarios: un escenario de solo escritura y un escenario de actualización de índice global (GSI). Los resultados mostraron que la optimización del commit no solo aumentó el TPS (transacciones por segundo) sino que también redujo el tiempo de respuesta (RT).

• Para el escenario de solo escritura, los resultados mostraron mejoras de hasta el 34,26% en TPS y una reducción significativa en RT.
• En el escenario de actualización de GSI, se observaron mejoras de hasta el 27,48% en TPS.

Estos resultados demuestran que la optimización del commit no solo incrementa el rendimiento de las bases de datos, sino que también mejora la eficiencia en entornos de producción.

Para más información, puedes consultar la primera parte de este artículo.

Fuente: Alibaba Cloud Blog