La escritura de objetos binarios grandes (BLOB) en MySQL dentro de entornos de alta concurrencia suele provocar cuellos de botella en el rendimiento, como contención de bloqueos y generación excesiva de registros redo. PolarDB resuelve estos desafíos mediante optimizaciones a nivel de kernel que eliminan la contención de bloqueos, reducen la presión de E/S y mejoran la gestión de espacio durante las operaciones con BLOB. Esto mejora significativamente el rendimiento de DML y DDL, lo que garantiza que sus servicios se ejecuten de manera estable y eficiente bajo cargas de trabajo de alta concurrencia.
Descripción general
Un objeto binario grande (BLOB) es un tipo de campo de base de datos que se utiliza para almacenar objetos de datos extensos, como imágenes, documentos y texto largo. En el motor nativo InnoDB de MySQL, cuando un campo BLOB de una fila de datos supera cierto tamaño, InnoDB lo almacena en páginas de datos separadas fuera de la página principal. Aunque este mecanismo permite manejar grandes volúmenes de datos, también introduce tres problemas importantes de rendimiento:
Cuello de botella en escrituras concurrentes: La actualización de un BLOB fuera de página adquiere un bloqueo pesimista. Esto permite que solo un hilo escriba BLOB en la tabla a la vez, lo cual limita severamente la concurrencia.
Mayor presión de E/S: Los campos grandes generan entradas de registro redo voluminosas. Si la E/S del disco es insuficiente, el vaciado de registros se convierte en un cuello de botella que bloquea las operaciones de escritura en primer plano.
Retraso en la recuperación de espacio: El proceso de limpieza de datos BLOB antiguos, conocido como proceso Purge, es ineficiente. Esto puede provocar un crecimiento excesivo del espacio de almacenamiento y degradación del rendimiento.
La función de optimización de BLOB en PolarDB soluciona estos problemas. Optimiza todo el ciclo de vida de los BLOB, incluidas las escrituras, actualizaciones y recuperación de espacio, directamente a nivel de kernel y sin requerir cambios en la aplicación.
Facturación
La función de optimización del rendimiento de BLOB está integrada en el kernel de PolarDB y está disponible sin costo adicional.
Optimizar el rendimiento de escritura de BLOB
Si experimenta cuellos de botella en el throughput o alta latencia al escribir en tablas BLOB durante las horas pico de actividad, la causa suele ser la contención de bloqueos de escritura. PolarDB resuelve este problema mediante la preasignación de páginas y la optimización de latches de índice.
Preasignación de páginas
Esta optimización divide el proceso de escritura de BLOB en los siguientes pasos:
Calcula el número necesario de páginas de datos y las asigna en una sola operación por lotes.
Copia los datos en un estado libre de bloqueos y llena las páginas recién asignadas con el contenido del BLOB.
Vincula la cadena resultante de páginas de datos al registro del índice mediante una única operación de bloqueo optimista.
Durante todo este proceso, solo la fase inicial de asignación de espacio es exclusiva. Las operaciones más costosas en tiempo, como la copia de datos, pueden ejecutarse simultáneamente con otras escrituras de BLOB. Además, dado que la copia de datos ocurre fuera de la sección crítica, el sistema evita el riesgo de que una sola escritura genere una gran cantidad de datos de registro redo que podrían llenar el búfer de registros y bloquear las escrituras. En última instancia, este mecanismo minimiza el tiempo de retención de bloqueos globales y mejora significativamente el rendimiento de escritura concurrente.
Optimización de latch de índice
En tablas que contienen campos BLOB pequeños (menores a 8 KB) o de tamaño mixto, el MySQL nativo suele abandonar prematuramente el bloqueo optimista durante las actualizaciones debido a operaciones de modificación de estructura de páginas de índice (SMO). Posteriormente, recurre a un modelo de bloqueo pesimista ineficiente que afecta gravemente el rendimiento concurrente. La optimización de latch de índice resuelve este cuello de botella al mantener las operaciones en la ruta optimista durante más tiempo. Esta optimización funciona mediante los siguientes pasos:
Permanecer en la ruta optimista: Cuando se detecta una posible actualización de campo BLOB, la lógica de optimización no cambia inmediatamente a un bloqueo pesimista. En su lugar, continúa reteniendo un latch compartido (S-latch), que tiene menor probabilidad de conflicto, y permanece en la ruta de actualización optimista.
Preconstrucción e intento de actualización: En la ruta optimista, preconstruye la estructura de datos BLOB necesaria para la actualización e intenta modificar la página del índice directamente.
-
Decisión de confirmación o retroceso:
Éxito: Si el registro actualizado cabe dentro de los requisitos de espacio de la página de índice actual, la operación se completa rápidamente en la ruta optimista.
Fallo: Si la página no tiene espacio suficiente, la optimización abandona automáticamente el intento y recurre sin problemas a la ruta de bloqueo pesimista nativa de MySQL. La ruta nativa completa entonces toda la operación de actualización para garantizar la consistencia de los datos.
La ventaja clave de este enfoque optimista es que aumenta significativamente la tasa de éxito de las actualizaciones optimistas. Permite que muchas operaciones, que de otro modo recurrirían al bloqueo pesimista, se completen de manera más eficiente. Esto mejora enormemente el throughput para actualizar datos BLOB de tamaño mixto bajo alta concurrencia.
Habilitar optimizaciones de escritura
En la consola de PolarDB, vaya a la página para view and modify los siguientes parámetros y habilitar estas optimizaciones:
Parámetro | Descripción | Versiones compatibles |
| Habilita o deshabilita la preasignación de páginas para BLOB. Valores válidos:
|
|
| Establece la longitud máxima de una sola columna BLOB para la cual se utiliza la preasignación de páginas. | |
| Habilita o deshabilita la optimización de latch de índice para BLOB. |
Reducir registros redo para escrituras de BLOB
Si su carga de trabajo implica escribir grandes cantidades de datos BLOB, lo que provoca que la tasa de generación de registros redo se convierta en un cuello de botella de E/S, puede habilitar la compresión redo para aliviar la presión.
La compresión redo funciona comprimiendo en paralelo las entradas de registro redo relacionadas con BLOB antes de escribirlas en el búfer de registros. Este proceso reduce significativamente el volumen de datos de registro redo escritos en el disco; las pruebas muestran una reducción promedio del 40 % al 60 %. Esto disminuye la presión de E/S de almacenamiento y evita que el módulo redo se convierta en un cuello de botella que afecte el rendimiento general de escritura. Durante la recuperación tras fallos, el sistema descomprime y aplica automáticamente estos registros.
Habilitar compresión redo
En la consola de PolarDB, vaya a la página para view and modify los siguientes parámetros y habilitar esta optimización:
Parámetro | Descripción | Versiones compatibles |
| Establece el algoritmo de compresión para los registros redo de BLOB. Valores válidos:
|
|
| Establece el nivel de compresión para el algoritmo seleccionado. Valores válidos: 0 a 9. Predeterminado: 6. |
Acelerar la recuperación de espacio de BLOB
Si observa que la recuperación de espacio de tablespace es lenta y los archivos continúan creciendo después de eliminar o actualizar frecuentemente datos BLOB, la causa raíz es la ineficiencia del proceso Purge en segundo plano nativo de MySQL. Al limpiar datos, este proceso primero adquiere bloqueos principales, como Index SX, antes de leer las páginas BLOB. Si una página no está en memoria, se desencadena una operación de E/S de disco costosa en tiempo mientras se retiene el bloqueo, lo cual puede bloquear otras operaciones concurrentes en la tabla durante un período prolongado. La optimización de prelectura Purge de PolarDB resuelve este cuello de botella al separar las operaciones de E/S del proceso de bloqueo. Esta optimización funciona mediante los siguientes pasos:
Identificar páginas objetivo: Antes de adquirir un bloqueo e iniciar la limpieza, el proceso Purge identifica primero la cadena completa de BLOB fuera de página que deben recuperarse.
Prelectura asíncrona: Inicia solicitudes de E/S asíncronas para cargar desde el disco hacia el pool de búfer las páginas objetivo que aún no están en memoria.
Limpieza rápida: Una vez que todas las páginas están cargadas en memoria, el proceso Purge adquiere los bloqueos principales necesarios, como
Index SX, y realiza rápidamente las operaciones de liberación de páginas en memoria y modificación de metadatos.
El mecanismo de prelectura Purge evita realizar operaciones de E/S de disco dentro de una sección crítica donde se retiene un bloqueo. Al trasladar las operaciones de E/S más costosas en tiempo a una etapa anterior, el tiempo de retención de bloqueos se reduce a la duración de operaciones rápidas en memoria. Esto no solo mejora la eficiencia de la recuperación de datos BLOB y previene el crecimiento excesivo de espacio, sino que, más importante aún, reduce el bloqueo de cargas de trabajo en primer plano, como escrituras de alta concurrencia, por parte del proceso de limpieza en segundo plano. Como resultado, mejora el rendimiento general de concurrencia y la estabilidad de la base de datos.
Habilitar prelectura Purge
En la consola de PolarDB, vaya a la página para view and modify el siguiente parámetro y habilitar esta optimización:
Parámetro | Descripción | Versiones compatibles |
| Habilita o deshabilita la prelectura Purge para BLOB. Valores válidos:
| Compatible con todas las versiones. |
Mejorar la eficiencia de ejecución de DDL
Si necesita ejecutar operaciones DDL, como ALTER TABLE, en tablas con una gran cantidad de datos BLOB y las operaciones tardan demasiado, puede habilitar las optimizaciones de BLOB relacionadas con DDL para reducir significativamente el tiempo de operación.
Preasignación de páginas: Dado que las columnas de desbordamiento para campos BLOB existen en la clave primaria, las operaciones DDL que reconstruyen la tabla principal también implican escribir campos BLOB. La optimización de preasignación de páginas utiliza un método de bloqueo más directo y simplificado para escribir datos BLOB, lo cual evita la sobrecarga de manejar conflictos de concurrencia complejos y mejora significativamente la eficiencia de reconstrucción.
Optimización de latch: El DDL paralelo particiona el árbol de claves primarias, de modo que varios hilos de trabajo no operan sobre la misma página de datos. Esta optimización protege la asignación de nuevas páginas de forma independiente, lo que permite que otras operaciones se ejecuten simultáneamente y mejora la eficiencia.
-
Optimización redo:
Agregación de páginas: Durante una carga masiva, en lugar de generar una entrada de registro redo por cada registro, el sistema escribe los cambios de una página de datos completa como una sola entrada de registro redo grande después de que la página se llena. Esto mejora la eficiencia de las operaciones redo.
Compresión agregada: Las entradas de registro redo grandes y agregadas se comprimen posteriormente para reducir aún más la cantidad de datos de registro redo generados durante el proceso DDL.
Habilitar optimizaciones DDL
En la consola de PolarDB, vaya a la página para view and modify los siguientes parámetros y habilitar estas optimizaciones:
Algunos parámetros de la siguiente tabla no se pueden modificar manualmente. Si necesita cambiarlos, envíe un ticket para obtener asistencia.
Parámetro | Descripción | Versiones compatibles |
| Especifica si se deben habilitar las optimizaciones de BLOB durante las operaciones DDL. Valores válidos:
|
|
| Especifica si se debe habilitar la optimización de bloqueo de índice durante las operaciones DDL. Valores válidos:
|
|
| Especifica si se debe habilitar la agregación de páginas redo durante la carga masiva DDL. Valores válidos:
|
|
| Establece el algoritmo de compresión redo para la carga masiva DDL. Valores válidos:
|
|
| Establece el objetivo para la compresión redo durante las operaciones DDL. Valores válidos:
|
|
Optimizaciones de módulos relacionados
En escenarios de BLOB con alto throughput, también pueden producirse cuellos de botella en otros módulos. Para lograr un rendimiento aún mejor, PolarDB proporciona las siguientes optimizaciones relacionadas:
Escrituras de registro redo asíncronas en paralelo: Varios hilos fragmentan los datos en el búfer de registro redo y los envían simultáneamente como tareas de E/S asíncronas. Esto aumenta significativamente el throughput de escritura de registros redo, alcanzando hasta 4 GB/s en pruebas.
Optimización de extensión de archivos: Basada en el sistema de archivos distribuido desarrollado internamente por PolarDB, las operaciones de extensión de tablespace solo requieren modificar una pequeña cantidad de metadatos. Se elimina la operación nativa de relleno con ceros del archivo, por lo que el tiempo y la sobrecarga de bloqueos de la extensión de archivos dejan de ser un cuello de botella.
Vaciado de páginas sucias sin bloqueos: Esta optimización utiliza tecnología de páginas sombra. Al vaciar una página sucia, el sistema primero construye una copia en memoria, libera el bloqueo de la página y luego usa la copia para la operación de E/S. Esto evita que la operación de E/S bloquee las solicitudes de escritura porque no se retiene ningún bloqueo de página durante el vaciado.
Pruebas de rendimiento
Los siguientes datos muestran las mejoras de rendimiento en escenarios DML y DDL después de habilitar las optimizaciones de BLOB.
-
Rendimiento DML: En escenarios de alta concurrencia con longitudes de fila de 100 KB y 200 KB, las optimizaciones de PolarDB mejoran el rendimiento de inserción y actualización casi 3 veces. Cuando se combinan con la compresión redo, el rendimiento mejora de 4 a 5 veces.
Rendimiento DDL: Para una tabla de 40 GB que contiene campos BLOB, habilitar estas optimizaciones aumenta la tasa de escritura DDL de 5 a 6 veces y reduce el tiempo total de ejecución en un 84 %.
