Con la aceleración de la digitalización, la cantidad de datos globales está aumentando exponencialmente, lo que plantea un enorme desafío para el rendimiento de los sistemas de bases de datos. Como tecnología clave en el sistema de gestión de bases de datos, el optimizador tiene un impacto importante en el rendimiento y la eficiencia de la base de datos: analiza y optimiza la solicitud de consulta del usuario para generar un plan de ejecución eficiente y luego devuelve el resultado de la consulta rápidamente. Sin embargo, la misma declaración SQL puede producir diferencias de rendimiento de órdenes de magnitud bajo diferentes decisiones de optimización. Con el aumento del tamaño de los datos y la complejidad de las consultas, el desarrollo continuo y la innovación del optimizador se convertirán en una dirección importante para la mejora continua del rendimiento del sistema de base de datos, y también es una de las competitividad más poderosa del sistema de base de datos.
Para escenarios distribuidos y nativos de la nube, PieCloudDB Database, un almacén de datos virtual nativo de la nube, diseñó y construyó una nueva generación de optimizadores: "Daqi". El nombre está inspirado en un personaje NPC del juego "Red Dead Redemption" y su eslogan "Tengo un plan" encaja perfectamente con la función del optimizador.
El optimizador "Daqi" implementa muchas funciones de optimización en PieCloudDB. Al generar planes de consulta de alta calidad, actúa como el "grupo de expertos" del sistema de base de datos para garantizar el rendimiento de las consultas y la eficiencia de los usuarios. "Daqi" logra un procesamiento de consultas más rápido y eficiente al analizar inteligentemente las declaraciones de las consultas, optimizar los planes de consultas y utilizar capacidades informáticas y de almacenamiento de datos distribuidos.
Mascota Tuoshupai "Paipai"
1 Operación agregada y empuje agregado
Hoy presentaremos en detalle la nueva función de "Daqi": juntar y empujar hacia abajo. En los sistemas de bases de datos modernos, la operación agregada (Aggregate) es un tipo de operación muy común. Mediante la operación de agregación, se pueden combinar varias filas de datos en una sola y se pueden realizar estadísticas, sumas y cálculos promedio en ella.
En el proceso tradicional de ejecución de consultas, la operación de agregación generalmente se realiza después de que se devuelven los resultados de la consulta y todos los datos deben transmitirse al motor de consultas para el cálculo de la agregación. Sin embargo, para conjuntos de datos a gran escala y consultas complejas, este enfoque puede generar problemas como un bajo rendimiento de las consultas, una alta carga computacional y costosos costos computacionales.
Para resolver estos problemas, el optimizador de PieCloudDB "Daqi" ha creado la función de pushdown agregado (Aggregate Pushdown). Después de las pruebas, en muchos escenarios, la función de pushdown agregado logrará una mejora en el rendimiento de cien o incluso mil veces.
2 Principio de empuje agregado
Pushdown Aggregation es una tecnología de optimización de consultas de bases de datos que reduce la transmisión de datos y la sobrecarga de procesamiento al enviar operaciones de agregación a las fuentes de datos, mejorando así el rendimiento y la eficiencia de las consultas.
El principio de realización del pushdown de agregación es realizar la operación de agregación lo antes posible en el proceso de ejecución de la consulta y enviar la operación de agregación a la fuente de datos para su procesamiento. Específicamente, cuando se genera el plan de consulta, el optimizador enviará la operación de agregación a la fuente de datos para que el cálculo de agregación se pueda realizar en la fuente de datos. Esto puede reducir la cantidad de transferencia de datos, reducir la carga del motor de consultas y utilizar la potencia informática de la fuente de datos para la agregación local.
Usemos un diagrama simple para explicar el principio de implementación principal del pushdown de agregación:
Con o sin comparación de "pushdown agregado"
En la figura anterior, la figura de la izquierda es el proceso de ejecución sin pushdown agregado y la figura de la derecha es el proceso de ejecución con pushdown agregado. En el caso de que no haya una inserción agregada en la figura de la izquierda, las tablas T1 y T2 se conectarán primero y la operación de agregación se completará en los conjuntos de datos después de la conexión.
En el caso de la inserción de agregación en la figura de la derecha, se realizará una operación de agregación en la tabla T1 antes de realizar la operación de unión en las tablas T1 y T2. De esta manera, en algunos escenarios, la cantidad de datos involucrados en la tabla T1 se puede reducir considerablemente durante la operación de unión, mejorando así significativamente el rendimiento de la consulta. Para mejorar con precisión la eficiencia de la consulta, los dos planes de ejecución anteriores se generarán en "Daqi" y, finalmente, se seleccionará el plan de ejecución con el menor costo de acuerdo con la estimación del modelo de costos.
Cuando hay más tablas participando en la conexión, "Daqi" intentará llevar la operación de agregación a diferentes capas de conexión y seleccionará la posición de empuje óptima mediante la comparación de costos.
3 Ejemplo de demostración de pushdown agregado
A continuación, echemos un vistazo al efecto del pushdown de agregación mediante un ejemplo de consulta. Primero, creamos una tabla de prueba con la siguiente declaración:
CREAR TABLA t (x int , y int ); INSERTAR EN t SELECCIONAR i % 30 , i % 30 FROM generate_series( 1 , 10240 ) i; ANALIZAR t;
La consulta utilizada para la prueba es la siguiente:
SELECCIONE t1 .x, suma( t2 .y + t3 .y), conteo (*) DESDE t t1 ÚNASE a t t2 EN t1 .x = t2 .x ÚNASE a t t3 EN t2 .x = t3 .x GRUPO POR t1 .x ;
Cuando no hay un pushdown de agregación, el plan de consulta es el siguiente:
EXPLICAR (ANALIZAR, DESCONECTAR COSTOS) SELECCIONAR t1.x, suma(t2.y + t3.y), contar(*) DESDE t t1 UNIR t t2 ON t1.x = t2.x UNIR t t3 ON t2.x = t3 .x GRUPO POR t1.x; PLAN DE CONSULTA ------------------------------------------------ -------------------------------------------------- ------------------------- Gather Motion 3:1 (corte1; segmentos: 3) ( tiempo real =153884.859..274102.066 filas =30 bucles = 1) -> HashAggregate ( tiempo real =274100.004..274100.011 filas =12 bucles =1) Grupo Clave Uso máximo de memoria: 0 kB -> Unión Hash ( tiempo real =38.717..100579.782 filas =477571187 bucles =1) Cond Hash: (t1.x = t3.x) Texto adicional: (seg0) Longitud de la cadena Hash 341,4 promedio, 342 max, usando 12 de 131072 depósitos. -> Hash Join ( tiempo real =2.088..429.203 filas =1398787 bucles =1) Hash Cond: (t1.x = t2.x) Texto adicional: (seg0) Longitud de la cadena hash 341,4 promedio, 342 máximo, usando 12 de 131072 cubos. -> Redistribuir movimiento 3:3 (segmentos 2; segmentos: 3) ( tiempo real=0.044..4.590 filas =4097 bucles =1) Clave hash: t1.x -> Seq Scan en t t1 ( tiempo real =1.382..32.683 filas =3496 bucles =1) -> Hash ( tiempo real =1.760.. 1,761 filas = 4097 bucles = 1) Depósitos: 131072 Lotes: 1 Uso de memoria: 1185 kB -> Redistribuir movimiento 3:3 (sección3; segmentos: 3) ( tiempo real = 0,049...0,922 filas = 4097 bucles = 1) Clave hash: t2.x -> Seq Scan en t t2 ( tiempo real =1.628..32.837 filas =3496 bucles =1) -> Hash ( tiempo real =36.153..36.153 filas =4097 bucles =1) Depósitos: 131072 lotes : 1 Uso de memoria: 1185 kB -> Redistribuir movimiento 3:3 (porción4; segmentos: 3) ( tiempo real =3.918..35.169 filas =4097 bucles =1) Clave hash: t3.x -> Seq Scan en t t3 (real tiempo=1.380..30.316 filas = 3496 bucles =1) Tiempo de planificación: 8.810 ms (slice0) Memoria del ejecutor: 257 Kbytes. (segmento1) Memoria del ejecutor: 2484 KB de promedio x 3 trabajadores, 2570 KB máximo (seg0). Work_mem: 1185 Kbytes máx. (segmento2) Memoria del ejecutor: 32840 K bytes promedio x 3 trabajadores, 32841 K bytes máximo (seg0). (segmento3) Memoria del ejecutor: 32860 K bytes promedio x 3 trabajadores, 32860 K bytes máximo (seg0). (segmento4) Memoria del ejecutor: 32860 K bytes promedio x 3 trabajadores, 32860 K bytes máximo (seg0). Memoria utilizada: 128000 kB Optimizador: optimizador de consultas Postgres Tiempo de ejecución: 274130,589 ms (32 filas)
Y cuando hay un pushdown de agregación, el plan de consulta es el siguiente:
EXPLICAR (ANALIZAR, DESCONECTAR COSTOS) SELECCIONAR t1.x, suma(t2.y + t3.y), contar(*) DESDE t t1 UNIR t t2 ON t1.x = t2.x UNIR t t3 ON t2.x = t3 .x GRUPO POR t1.x; PLAN DE CONSULTA ------------------------------------------------ -------------------------------------------------- -------------------------------------------------- ------ Reunir movimiento 3:1 (sección1; segmentos: 3) ( tiempo real =835.755..836.406 filas =30 bucles =1) -> Finalizar GroupAggregate ( tiempo real =834.227..835.432 filas =12 bucles = 1) Clave de grupo : t1.x -> Ordenar ( tiempo real =834.031..834.441 filas =4097 bucles =1) Clave de clasificación: t1.x Método de clasificación: clasificación rápida Memoria: 1266 kB -> Redistribuir movimiento 3:3 (sección2; segmentos: 3 ) ( tiempo real =812.139..830.706 filas =4097 bucles =1) Clave hash: t1.x -> Hash Join ( tiempo real =810.536..828.097 filas =3496 bucles =1) Cond. hash: (t1.x = t2 .X) Texto adicional: (seg0) Longitud de la cadena hash 1,0 promedio, 1 máximo, usando 30 de 131072 depósitos. -> Seq Scan en t t1 ( tiempo real =1.689..16.674 filas =3496 bucles =1) -> Hash ( tiempo real =808.497..808.498 filas =30 bucles =1) Depósitos: 131072 Lotes: 1 Uso de memoria: 1026kB -> Broadcast Motion 3:3 (sección3; segmentos: 3) ( tiempo real =461.065..808.466 filas =30 bucles =1) -> HashAggregate parcial ( tiempo real =810.026..810.033 filas =12 bucles =1) Clave de grupo : t2.x Uso máximo de memoria: 0 kB -> Hash Join ( tiempo real =28.070..331.181 filas =1398787 bucles =1) Hash Cond: (t2.x = t3.x) filas Texto adicional: (seg0) Longitud de la cadena hash 341,4 promedio, 342 máximo, usando 12 de 262144 depósitos. -> Redistribuir movimiento 3:3 (sección4; segmentos: 3) ( tiempo real =0.040..1.270 =4097 bucles =1) Clave hash: t2.x -> Seq Scan en t t2 ( tiempo real =1.449..19.963 filas =3496 bucles =1) -> Hash ( tiempo real =27.834..27.835 filas =4097 bucles =1) Depósitos: 262144 Lotes: 1 Uso de memoria: 2209kB -> Redistribuir movimiento 3:3 (sección5; segmentos: 3) ( tiempo real =3.836..27.025 filas =4097 bucles =1) Clave hash: t3.x -> Seq Scan en t t3 ( tiempo real =1.537..23.654 filas =3496 loops =1) Tiempo de planificación: 14,425 ms (slice0) Memoria del ejecutor: 328 K bytes (slice1) Memoria del ejecutor: 408 K bytes promedio x 3 trabajadores, 514 K bytes máximo (seg0) Work_mem: 450 K bytes máx. (segmento2) Memoria del ejecutor: 33951 K bytes promedio x 3 trabajadores, 33952 K bytes máximo (seg0). Work_mem: 1026 Kbytes máx. (segmento3) Memoria del ejecutor: 2298 KB de promedio x 3 trabajadores, 2341 KB máximo (seg0). Work_mem: 2209 Kbytes máx. (segmento4) Memoria del ejecutor: 32860 K bytes promedio x 3 trabajadores, 32860 K bytes máximo (seg0). (segmento5) Memoria del ejecutor: 32860 K bytes promedio x 3 trabajadores, 32860 K bytes máximo (seg0). Memoria utilizada: 128000 kB Optimizador: optimizador de consultas Postgres Tiempo de ejecución: 865,305 ms (39 filas)
Al comparar los dos planes de consulta, se puede ver que cuando no hay inserción de agregación (plan de consulta 1), primero deben completarse todas las operaciones de conexión y luego realizar la operación de agregación en el conjunto de datos conectados. El envío de agregación (plan de consulta 2) puede llevar la operación de agregación a la capa de conexión óptima, reduciendo así la cantidad de datos en operaciones de conexión posteriores y mejorando significativamente el rendimiento.
En este ejemplo, "Daqi" presiona hacia abajo la operación de agregación después de la conexión entre t2 y t3, pero antes de la conexión con t1. Al comparar estos dos tiempos de ejecución, podemos ver que el tiempo de ejecución se ha reducido de los 274130,589 ms anteriores a 865,305 ms, logrando una mejora del rendimiento de más de trescientas veces. Cuando la cantidad de datos aumente aún más, o la cantidad de tablas involucradas en la consulta aumente aún más, la mejora del rendimiento del pushdown de agregación será más obvia.
Comparación de Pushdown sin agregación versus Pushdown con agregación
El nuevo optimizador "Daqi" de PieCloudDB proporciona a los usuarios una serie de funciones integrales de optimización lógica, que incluyen inserción de predicados, promoción de subconsultas y eliminación de uniones externas. Como base de datos para escenarios de procesamiento analítico en línea (OLAP), el optimizador "Daqi" no solo admite funciones de agregación y pushdown, sino que también tiene funciones avanzadas como omisión de datos y precálculo para satisfacer las necesidades de diversas consultas complejas. En artículos futuros, presentaremos estas características una por una para brindarle una comprensión más profunda. ¡Manténganse al tanto!
Se lanzó Redis 7.2.0, la versión de mayor alcance, los programadores chinos se negaron a escribir programas de juegos de azar, se extrajeron 14 dientes y el 88% de todo el cuerpo resultó dañado. Se lanzó Flutter 3.13. System Initiative anunció que todo su software Sea de código abierto. Apareció la primera aplicación independiente a gran escala, Grace cambió su nombre a "Doubao". Spring 6.1 es compatible con subprocesos virtuales y JDK 21. Tableta Linux StarLite 5: Ubuntu predeterminado, Chrome 116 de 12,5 pulgadas lanzado oficialmente . Red Hat redistribuyó el escritorio. Desarrollo de Linux, el desarrollador principal fue transferido Kubernetes 1.28 lanzado oficialmente