Consulta paralela para Amazon Aurora MySQL - Amazon Aurora
Información general de consultas paralelas

Consulta paralela para Amazon Aurora MySQL

En este tema, se describe la optimización del rendimiento de las consultas en paralelo de la edición compatible con Amazon Aurora MySQL. Esta característica usa una ruta de procesamiento especial para determinadas consultas de uso intensivo de datos, que aprovecha la arquitectura de almacenamiento compartido de Aurora. Consultas en paralelo funciona mejor con los clústeres de base de datos Aurora MySQL que tienen tablas con millones de filas y consultas analíticas que tardan minutos u horas en completarse.

Temas

Información general de consultas paralelas de Aurora MySQL

Consultas en paralelo de Aurora MySQL es una optimización que paraleliza algunas de los cálculos y E/S del procesamiento de consultas con un uso intensivo de datos. El trabajo que se paraleliza incluye la recuperación de filas del almacenamiento, la extracción de valores de columna y la determinación de qué filas coinciden con las condiciones de la cláusula WHERE y de las cláusulas JOIN. Este trabajo con uso intensivo de los datos se delega (en términos de optimización de base de datos, se baja de posición) a varios nodos de la capa de almacenamiento distribuido de Aurora. Sin una consulta paralela, cada consulta transfiere todos los datos analizados a un solo nodo del clúster de Aurora MySQL (el nodo principal) y realiza ahí todos los procesamientos de consultas.

sugerencia

El motor de base de datos de PostgreSQL también tiene una característica denominada “consulta paralela”. Esa característica no está relacionada con la consulta paralela de Aurora.

Cuando está activada una característica de consulta en paralelo, el motor de Aurora MySQL determina automáticamente cuándo las consultas pueden aprovecharla, sin requerir cambios de SQL como sugerencias o atributos de tabla. En las secciones siguientes, puede encontrar una explicación cuándo se aplica una consulta en paralelo a una consulta. También podrá encontrar cómo asegurarse de que las consultas en paralelo se aplican cuando proporcionan el máximo beneficio.

nota

La optimización de consultas en paralelo proporciona el mayor beneficio para consultas de larga duración que tardan minutos u horas en completarse. Aurora MySQL generalmente no realiza la optimización de consultas en paralelo para consultas de bajo costo. Tampoco suele realizar la optimización de consultas paralelas si otra técnica de optimización tiene más sentido, como el almacenamiento en caché de consultas, el almacenamiento en caché de grupo de búferes o las búsquedas de índice. Consulte si observa que las consultas paralelas no se usan cuando lo esper Cómo comprobar qué instrucciones usan consultas paralelas para Aurora MySQL.

Ventajas

Con la consulta paralela, puede ejecutar consultas analíticas de uso intensivo de datos en tablas de Aurora MySQL. En muchos casos, puede obtener una mejora del rendimiento de orden de magnitud sobre la división tradicional del trabajo para el procesamiento de consultas.

Entre los beneficios de usar consultas en paralelo se incluyen los siguientes:

  • Rendimiento de E/S mejorado, debido a la paralelización de solicitudes de lectura física en múltiples nodos de almacenamiento.

  • Reduce el tráfico de red. Aurora no transmite páginas de datos enteras de nodos de almacenamiento al nodo principal y, después, filtra las filas y columnas innecesarias. En vez de eso, Aurora transmite tuplas compactas que contienen solo los valores de columna necesarios para el conjunto de resultados.

  • Uso reducido de CPU en el nodo director debido al procesamiento de la función de insertar, filtrado de filas y proyección de columnas para la cláusula WHERE.

  • Presión de memoria reducida en el grupo de búfer. Las páginas procesadas por la consulta paralela no se agregan al grupo de búferes. Este enfoque reduce la posibilidad de que un análisis intensivo de datos expulse los datos utilizados con frecuencia del grupo de búferes.

  • Reducción potencial de la duplicación de datos en la canalización de extracción, transformación y carga (ETL), haciendo que sea práctico realizar consultas analíticas de ejecución prolongada en los datos existentes.

Arquitectura

La característica de consulta en paralelo utiliza los principios de arquitectura principales de Aurora MySQL: desacoplar el motor de base de datos del subsistema de almacenamiento y reducir el tráfico de red mediante la optimización de los protocolos de comunicación. Aurora MySQL utiliza estas técnicas para acelerar las operaciones de escritura intensiva, como el procesamiento de registros de rehacer. Las consultas en paralelo aplican los mismos principios a las operaciones de lectura.

nota

La arquitectura de las consultas en paralelo de Aurora MySQL es diferente de la de las características de nombre similar de otros sistemas de base de datos. La consulta en paralelo de Aurora MySQL no implica multiprocesamiento simétrico (SMP), así que no depende de la capacidad de la CPU del servidor de la base de datos. El procesamiento paralelo tiene lugar en la capa de almacenamiento, independiente del servidor de Aurora MySQL que sirve como coordinador de consultas.

De forma predeterminada, sin consulta en paralelo, el procesamiento de una consulta de Aurora implica la transmisión de datos sin procesar a un solo nodo del clúster de Aurora (el nodo principal). Aurora luego realiza todo el procesamiento adicional para esa consulta en un solo hilo en ese único nodo. Con las consultas paralelas, gran parte de este trabajo con uso intensivo de E/S y de CPU se delega a los nodos de la capa de almacenamiento. Solo las filas compactas del conjunto de resultados se transmiten de vuelta al nodo director, con las filas ya filtradas y los valores de la columna ya extraídos y transformados. El beneficio del rendimiento viene de la reducción del tráfico de red, la reducción del uso de CPU en el nodo director y la paralelización de la E/S en los nodos de almacenamiento. La cantidad de E/S, filtrado y proyección paralelos es independiente del número de instancias de base de datos del clúster de Aurora que ejecute la consulta.

Requisitos previos

Para utilizar todas las características de la consulta paralela, se requiere un clúster de base de datos de Aurora MySQL que ejecute la versión 2.09 o una posterior. Si ya tiene un clúster que desea utilizar con consulta paralela, puede actualizarlo a una versión compatible y activar la consulta paralela después. En ese caso, asegúrese de seguir el procedimiento de actualización en Consideraciones para actualizar las consultas paralelas ya que los nombres de las opciones de configuración y los valores predeterminados son diferentes en estas versiones más recientes.

Las instancias de base de datos del clúster deben utilizar las clases de instancia db.r*.

Asegúrese de que la optimización de combinación hash esté activada para su clúster. Para saber cómo hacerlo, consulte Activación de una combinación hash para clústeres de consultas paralelas.

Para personalizar parámetros como aurora_parallel_query y aurora_disable_hash_join, debe tener un grupo de parámetros personalizado que utilice con el clúster. Puede especificar estos parámetros individualmente para cada instancia de base de datos mediante un grupo de parámetros de base de datos. Sin embargo, se recomienda especificarlos en un grupo de parámetros de clúster de base de datos. De esta forma, todas las instancias de base de datos del clúster heredan la misma configuración para estos parámetros.

Limitaciones

La característica de consultas en paralelo tiene las siguientes limitaciones:

  • La configuración de almacenamiento del clúster de base de datos Aurora I/O-Optimized no admite consultas paralelas.

  • No puede usar la consulta paralela con las clases de instancia db.t2 o db.t3. Esta limitación se aplica incluso si solicita la consulta paralela mediante la variable de sesión aurora_pq_force.

  • La consulta paralela no se aplica a las tablas que utilizan los formatos de fila COMPRESSED o REDUNDANT. Utilice los formatos de fila COMPACT o DYNAMIC para las tablas que piensa utilizar con consultas paralelas.

  • Aurora utiliza un algoritmo basado en costos para determinar si utilizar el mecanismo de consulta paralela para cada instrucción SQL. El uso de ciertas construcciones SQL en una instrucción puede evitar la consulta paralela o hacer que la consulta paralela sea poco probable para esa instrucción. Para obtener información acerca de la compatibilidad de construcciones SQL con la consulta paralela, consulte Constructos de SQL para consultas paralelas en Aurora MySQL.

  • Cada instancia de base de datos Aurora solo puede ejecutar un número determinado de sesiones de consultas en paralelo a la vez. Si una consulta tiene varias partes que usan consultas en paralelo, como subconsultas, uniones u operadores UNION, esas fases se ejecutan en secuencia. La instrucción solo cuenta como una única sesión de consulta en paralelo cada vez. Puede monitorizar el número de sesiones activas usando las variables de estado de consultas en paralelo. Puede comprobar el límite de sesiones simultáneas para una instancia de base de datos determinada consultando la variable de estado Aurora_pq_max_concurrent_requests.

  • La consulta en paralelo está disponible en todas las regiones de AWS compatibles con Aurora. Para la mayoría de las regiones de AWS, la versión de Aurora MySQL mínima requerida para utilizar la consulta en paralelo es 2.09.

  • La consulta paralela está diseñada para mejorar el rendimiento de las consultas que realizan un uso intensivo de datos. No está diseñada para consultas ligeras.

  • Le recomendamos que utilice nodos de lector para las instrucciones SELECT, especialmente las que realizan un uso intensivo de datos.

Costos de E/S con consulta paralela

Si su clúster de Aurora MySQL utiliza una consulta en paralelo, es posible que vea un aumento en los valores VolumeReadIOPS. Las consultas en paralelo no utilizan el grupo de búfer. Por lo tanto, si bien las consultas son rápidas, este procesamiento optimizado puede dar como resultado un aumento de las operaciones de lectura y los cargos asociados.

Los costos de E/S de consulta paralela de su consulta se miden en la capa de almacenamiento y serán iguales o mayores si la consulta paralela está activada. La ventaja es que mejora el rendimiento de las consultas. Hay dos razones por las que los costos de E/S pueden ser más altos con la consulta paralela:

  • Aunque algunos de los datos de una tabla se encuentren en el grupo de búferes, la consulta paralela requiere que todos los datos se analicen en la capa de almacenamiento, lo que genera costos de E/S.

  • La ejecución de una consulta paralela no prepara el grupo de búferes. Como resultado, las ejecuciones consecutivas de la misma consulta paralela generan el costo total de E/S.