Este artículo se comparte desde la comunidad HUAWEI CLOUD " Huawei Cloud GaussDB (for Influx) Revelación del quinto problema: subconsulta de mejores prácticas ", autor: base de datos GaussDB.
"¡Alerta! ¡Alerta!".
"¿Cuál es la alarma?" Xiao Wang, que estaba aturdido mientras dormía, fue despertado repentinamente por una llamada telefónica de un colega de operación y mantenimiento, y su rostro estaba sobresaltado.
"¡Consulta lenta! ¡El cliente ha informado de una falla! ¡Date prisa y resuélvelo!"
Xiao Wang abrió rápidamente el portátil, se conectó de forma remota al entorno para encontrar el problema y finalmente descubrió que la consulta lenta era una subconsulta. "No, ¿la misma declaración no informó una consulta lenta ayer?"
Pero Xiao Wang rápidamente descubrió por qué. El problema con esta consulta lenta es que la consulta interna de la subconsulta podría haber agregado los datos y luego enviarlos a la consulta externa, pero como no hay agregación, será muy lento cuando la cantidad de datos sea grande.
Al encontrar el quid, Xiao Wang inmediatamente pasó la declaración SQL optimizada al cliente a través de los colegas de operación y mantenimiento, y finalmente se resolvió la alarma.
"¡Parece que es hora de resolver la consulta!" Aprovechando su pensamiento claro, Xiao Wang comenzó a resolverlo...
0 1 ¿Qué es una subconsulta?
Una subconsulta es una consulta anidada dentro de otra consulta y generalmente se coloca en la instrucción from en la sintaxis de InfluxQL para mejorar la flexibilidad del código. Las subconsultas se dividen principalmente en las siguientes categorías:
Subconsulta escalar (scalarsubquery) : devuelve un valor en 1 fila y 1 columna
Subconsulta de fila (subconsulta de fila) : el conjunto de resultados devuelto es 1 fila y N columnas
Subconsulta de columna (columnsubquery) : el conjunto de resultados devuelto es N filas y 1 columna
Subconsulta de tabla (tablesubquery) : el conjunto de resultados devuelto es N filas y N columnas
Por ejemplo, en la instrucción de consulta:
select first(sum_f1)/first(sum_f2) from (select sum(f1) as sum_f1 from mst), (select sum(f2) as sum_f2 from mst)Se utilizan dos subconsultas, que son para obtener la suma de las dos columnas f1 y f2 de la tabla mst, respectivamente, y utilizar los resultados sum_f1 y sum_f2 como origen de la consulta externa para la instrucción de consulta externa.
La sintaxis general para una subconsulta de GaussDB (para Influx) es SELECT_clause FROM (SELECT_statement) [...]. La lógica en el procesamiento de subconsultas se muestra en la siguiente figura.
El sistema primero procesará la declaración de la subconsulta y el resultado de la subconsulta se almacenará en caché como fuente de datos de la consulta externa. Finalmente, se procesará la consulta externa y el resultado se devolverá al cliente.
0 2 Escenarios de uso de subconsulta
Las subconsultas se utilizan cuando no se puede procesar una consulta simple, o para un procesamiento posterior basado en los datos de una consulta, por ejemplo, para encontrar los tres mayores entre los valores mínimos de cada grupo:
SELECT top (v,3)
FROM (
SELECT min (value) AS v
FROM mst
GROUP BY tag1
)Las subconsultas nos dan mucha flexibilidad, pero en principio no se recomiendan las subconsultas. La razón es muy simple: en comparación con las consultas ordinarias, las subconsultas tienen llamadas a funciones más profundas y volúmenes de datos más grandes, lo que consume más recursos y aumenta la latencia.
0 3 Análisis de casos
En el proceso de desarrollo con GaussDB (para Influx), a menudo enfrentamos algunas dificultades en las subconsultas, como:
1. ¿Cuándo usar subconsultas?
2. Ante un escenario complejo, ¿cómo descomponerlo en subconsultas para solucionarlo?
3. ¿La subconsulta escrita es óptima? ¿Se puede volver a optimizar?
A continuación, combinamos un caso específico para analizar brevemente cómo usar de manera eficiente las subconsultas y las ideas de análisis.
Un usuario de HUAWEI CLOUD usa GaussDB (para Influx) para escribir alrededor de 540 millones de puntos todos los días, y la línea de tiempo es de más de 100 w. En la consulta de negocios, tiempo y espacio, consulta de tasa de éxito de solicitudes y consulta de topN.
Tome los siguientes datos insensibilizados como datos de muestra para el análisis de casos y la práctica:
-
Caso 1 ¿Cuándo usar subconsultas?
El usuario utiliza subconsultas para la agrupación espaciotemporal y como origen de la consulta externa, que agrega los resultados de la agrupación espaciotemporal. La sentencia de consulta es:
SELECT SUM(req_nums)
FROM(
SELECT requestNum AS req_nums
FROM req_table
WHERE statement=’SUCCESS’ AND time >= 1629129600000000000
AND time<=1629129611000000000 )
WHERE time>=1629129600000000000 AND time<=1629129611000000000
AND req_nums < 50
GROUP BY time(1s), group
ORDER BY time ASCEl problema resultante:
En el escenario de uso del usuario, se puede encontrar que la subconsulta de consulta solo implementa el filtrado condicional y el cambio de nombre de columna, por lo que la consulta interna es equivalente a SELECT requestNum AS req_nums + filtering.La consulta en el escenario de no agregación requiere un gran cantidad de datos sin procesar a recuperar, lo que resulta en la velocidad de consulta Lenta, por lo que la eficiencia de la consulta no cumple con los requisitos del usuario.
Soluciones:
Al analizar la declaración de consulta, se puede ver que la demanda del usuario es agregar los datos que cumplen las condiciones (statement='SUCCESS' AND requestNum < 50) en una agregación de espacio-tiempo (GROUPBY TAG, time(5m)), y después de clarificar el destino de la consulta, se puede escribir más claramente Declaración de consulta eficiente: junte todas las condiciones de filtro y realice la agregación de espacio-tiempo directamente.
Mejoras gramaticales:
SELECT SUM(requestNum)
FORM req_table
WHERE statement=’SUCCESS’ AND requestNum < 50
AND time>=1629129600000000000 AND time<=1629129611000000000
GROUP BY time(1s), group
ORDER BY time ASC-
Caso 2 Uso de subconsultas para resolver problemas complejos
En el escenario comercial del usuario, se debe calcular la tasa de éxito de la solicitud, es decir, se filtra y se cuenta una determinada columna de datos de acuerdo con diferentes condiciones de filtro y, finalmente, se calcula la proporción. GaussDB (para Influx) no admite la declaración case when, por lo que es difícil filtrar diferentes datos en la misma columna según los diferentes casos. Cuando muchos desarrolladores se encuentran con ese problema, no tienen ni idea.
Soluciones:
Paso 1: use la función de subconsulta + tabla múltiple para cambiar la misma columna de datos en dos columnas de acuerdo con las condiciones del filtro:
SELECT * FROM
(SELECT requestNum AS success_requestNum FROM req_table WHERE statement=’SUCCESS’ AND time>=1629129600000000000 AND time<=1629129611000000000),
(SELECT requestNum AS total_requestNum FROM req_table WHERE time>=1629129600000000000 AND time<=1629129611000000000)
Paso 2: Cuente los datos consultados:
SELECT SUM(success_requestNum) AS total_success_reqNum, SUM(total_requestNum) AS total_requestNum
FROM
(SELECT requestNum AS success_requestNum FROM req_table WHERE statement=’SUCCESS’ AND time>=1629129600000000000 AND time<=1629129611000000000),
(SELECT requestNum AS total_requestNum FROM req_table WHERE time>=1629129600000000000 AND time<=1629129611000000000)
GROUP BY time ASC
Paso 3: escriba una declaración de consulta para la tasa de éxito final:
SELECT SUM(success_requestNum)/SUM(total_requestNum) AS success_ratio
FROM
(SELECT requestNum AS success_requestNum FROM req_table WHERE statement=’SUCCESS’ AND time>=1629129600000000000 AND time<=1629129611000000000),
(SELECT requestNum AS total_requestNum FROM req_table WHERE time>=1629129600000000000 AND time<=1629129611000000000)
GROUP BY time ASC
-
Caso 3 ¿Cómo optimizar la declaración de la subconsulta?
Con base en el caso 2, obtuvimos el método para encontrar la tasa de éxito. La declaración de consulta es la siguiente:
SELECT SUM(success_requestNum)/SUM(total_requestNum) AS success_ratio
FROM
(SELECT requestNum AS success_requestNum FROM req_table WHERE statement=’SUCCESS’ AND time>=1629129600000000000 AND time<=1629129611000000000),
(SELECT requestNum AS total_requestNum FROM req_table WHERE time>=1629129600000000000 AND time<=1629129611000000000)
GROUP BY time ASCEl problema resultante:
La declaración de consulta escrita por el usuario cuyo tiempo de consulta es superior a 120 s no cumple con los requisitos comerciales y debe optimizarse aún más.
Mejoras gramaticales
De acuerdo con los principios y las soluciones de la subconsulta descritos anteriormente, la consulta agregada debe colocarse dentro de la subconsulta para reducir la cantidad de datos y acelerar la consulta. La declaración de consulta optimizada es la siguiente:
SELECT SUM(success_requestNum)/SUM(total_requestNum) AS success_ratio
FROM
(SELECT SUM(requestNum) AS success_requestNum FROM req_table WHERE statement=’SUCCESS’ AND time>=1629129600000000000 AND time<=1629129611000000000),
(SELECT SUM(requestNum) AS total_requestNum FROM req_table WHERE time>=1629129600000000000 AND time<=1629129611000000000)
GROUP BY time ASCLos resultados de la consulta son los mismos:
Efecto de optimización:
La consulta no optimizada tarda 126 segundos, la consulta optimizada tarda 2,7 segundos y el rendimiento mejora 47 veces.
*Darse cuenta
Usando SUM(success_requestNum), el propósito de SUM(total_requestNum) es alinear los datos. Usar SELECTsuccess_requestNum / total_requestNum directamente dará como resultado resultados incorrectos porque los datos al mismo tiempo no se pueden alinear:
SELECT *
FROM
(SELECT SUM(requestNum) AS success_requestNum FROM req_table WHERE statement=’SUCCESS’ AND time>=1629129600000000000 AND time<=1629129611000000000),
(SELECT SUM(requestNum) AS total_requestNum FROM req_table WHERE time>=1629129600000000000 AND time<=1629129611000000000)
GROUP BY time ASC
El volumen total de datos de la consulta está positivamente relacionado con la velocidad de la consulta. Cuanto mayor sea el volumen de la consulta de datos, más lenta será la velocidad de la consulta. Por lo tanto, ya sea que esté escribiendo una subconsulta o una declaración de consulta no subconsulta, la primera El principio es tratar de reducir el volumen de datos en la consulta. , lo que significa que las consultas agregadas (generalmente consultas que reducen la cantidad de datos) deben colocarse dentro de las subconsultas tanto como sea posible.
0 4 Subconsultas flexibles y alto rendimiento
GaussDB (para Influx) no solo proporciona capacidades de subconsultas flexibles, sino que también utiliza vectorización, reutilización de memoria y otras tecnologías para mejorar continuamente la eficiencia de las consultas, cumpliendo con los requisitos de rendimiento de consultas de los usuarios en escenarios de datos masivos.
Consulta vectorizada: GaussDB (para Influx) utiliza el conjunto de instrucciones SIMD para mejorar el grado de paralelismo del procesamiento de datos. Al mismo tiempo, utilizando el modelo de datos vectorizados, una iteración puede procesar un lote de puntos, lo que reduce en gran medida el número de iteraciones de cálculo y lo acelera.
Reutilización de la memoria: el reciclaje y la asignación de memoria por parte del GC se reducen tanto como sea posible durante el proceso de consulta, y la memoria solicitada se administra por separado, lo que resuelve el problema de la expansión de la memoria durante el proceso de consulta, lo que hace que el GC reduzca la consulta con frecuencia. velocidad.
0 5 Resumen
GaussDB (para Influx) es compatible con la función de subconsulta, lo que nos brinda una gran flexibilidad para manejar problemas y también tiene altos requisitos para los usuarios. Las subconsultas irrazonables a menudo conducen a problemas como un alto retraso en la consulta y un alto consumo de recursos. , por lo que debe prestar atención a los siguientes puntos cuando utilice subconsultas de GaussDB (para Influx):
1. Comprender la lógica empresarial aplicable a las subconsultas. Las subconsultas son adecuadas para escenarios en los que los datos consultados se procesan dos veces (varias veces);
2. Trate de evitar el uso de subconsultas en escenarios en los que no se pueden usar subconsultas. 3. Debe usarse En el escenario de subconsulta ,
la consulta que reduce la cantidad de datos se coloca en la subconsulta tanto como sea posible para reducir el volumen general de datos de la consulta y, por lo tanto, acelerar la consulta.
0 6 fin
El autor de este artículo: HUAWEI CLOUD Database Innovation Lab y HUAWEI CLOUD Spatiotemporal Database Team
¡Bienvenido a unirse a nosotros!
Cloud Database Innovation Lab (Chengdu, Beijing) Correo electrónico de entrega de currículum: [email protected]
HUAWEI CLOUD Equipo de base de datos espaciotemporal (Xi'an, Shenzhen) Correo electrónico de entrega de currículum: [email protected]
Haga clic en Seguir para conocer las nuevas tecnologías de HUAWEI CLOUD por primera vez ~