Este artículo es compartido por la comunidad de la nube de Huawei " [GaussTech Número 2] Análisis del proceso de ejecución de la declaración de consulta SQL de GaussDB ", autor: base de datos GaussDB.
La importancia de SQL para las bases de datos relacionales es evidente. Como director de orquesta, orienta la correcta interpretación de la obra y la armonía y unidad del ritmo. Como nueva generación de bases de datos distribuidas relacionales, Huawei Cloud GaussDB tiene un excelente rendimiento técnico y competitividad en la industria. Mucha gente siente curiosidad por las tecnologías clave de GaussDB y ha dejado mensajes en el foro:
Hoy comenzaremos con el motor SQL de GaussDB y aprenderemos sobre el proceso de ejecución de las declaraciones de consulta SQL de GaussDB, incluidos los principios y puntos técnicos clave del motor SQL de GaussDB.
Si tiene alguna pregunta o punto de interés técnico clave durante el proceso de comprensión, puede participar en [Preguntas y respuestas de Yunka] para descubrir el misterio del motor SQL GaussDB, interactuar y ganar regalos , y dejar mensajes para que los expertos se reúnan uno a uno. -one Responde preguntas y tendrás la oportunidad de obtener recompensas por hacer preguntas.
↓↓↓↓ El siguiente es el texto
Primero, introduzcamos brevemente la estructura del sistema de GaussDB y luego analicemos el proceso de ejecución de las declaraciones de consulta SQL de GaussDB.
Arquitectura del sistema GaussDB
Figura (1) Centralizado
Figura (2) Distribución
Durante la ejecución de sentencias SQL de GaussDB, están involucradas las siguientes funciones clave:
| GTM |
El Administrador de transacciones globales es responsable de generar y mantener información global única, como ID de transacciones globales, instantáneas de transacciones, marcas de tiempo e información de secuencia. |
| CN |
Nodo Coordinador. Responsable de recibir solicitudes de acceso de las aplicaciones y devolver los resultados de la ejecución al cliente, responsable de descomponer las tareas y programar los fragmentos de tareas que se ejecutarán en paralelo en cada DN. Cada CN está conectado a cada DN y cada CN contiene una copia de metadatos con el mismo contenido de metadatos. |
| DN |
Nodo de datos. Responsable de almacenar datos comerciales (compatible con el almacenamiento de filas, el almacenamiento de columnas y el almacenamiento híbrido), ejecutar tareas de consulta de datos y devolver los resultados de la ejecución a CN. |
Entre ellos, DN es el principal responsable de la ejecución de declaraciones SQL de GaussDB. Su arquitectura lógica se muestra en la siguiente figura:
Figura (3) Arquitectura lógica de GaussDB
GaussDB incluye dos motores principales: SQL Engine y Storage Engine . El motor SQL a veces se denomina procesador de consultas y sus funciones principales son el análisis de SQL, la optimización de consultas y la ejecución de consultas. El análisis de SQL realiza análisis léxico, análisis de sintaxis y análisis semántico en la declaración SQL de entrada para generar un árbol de consultas. Después de que el árbol de consultas se somete a optimización de reglas (RBO) y optimización de costos (CBO), se genera un plan de ejecución. El ejecutor realiza operaciones como extraer, calcular, actualizar y eliminar datos relevantes según el plan de ejecución para lograr los resultados deseados por la consulta del usuario.
El motor de almacenamiento es responsable de administrar todas las E/S de datos. Incluye el procesamiento de lectura y escritura de datos (procesamiento de solicitudes de E/S para filas, índices, páginas, asignaciones y versiones de filas), administración del búfer de datos (Buffer Pool) y transacciones. gerente. Entre ellos, la gestión de transacciones implica el mecanismo de bloqueo (Lock) y la gestión del registro de transacciones (XLOG) que mantienen los atributos ACID.
Entre el motor SQL y el motor de almacenamiento se encuentra la capa AM (método de acceso). AM encapsula la capa de almacenamiento para admitir múltiples motores de almacenamiento (Astore, Ustore, etc.). La capa SQL no llama a la capa de almacenamiento directamente, sino a través de la capa AM. La capa AM llamará a diferentes cuerpos de ejecución según los diferentes motores de almacenamiento.
Se puede ver en el diagrama de arquitectura lógica de GaussDB que el diseño de la arquitectura de GaussDB sigue los principios de diseño de la abstracción y el desacoplamiento jerárquico del sistema de software moderno, que incluyen: mecanismo de transacción unificado, sistema de registro unificado, sistema de control de concurrencia unificado, sistema de metainformación unificado y Sistema unificado de gestión de caché. Por tanto, la arquitectura técnica de GaussDB tiene las siguientes características principales:
-
Admite optimización, ejecución y desacoplamiento de la capa de almacenamiento de SQL;
-
Admite motores de almacenamiento conectables.
Proceso de ejecución de la declaración de consulta SQL.
El proceso de ejecución de una declaración de consulta SQL (SELECT) es el siguiente:
Figura (4) Proceso de ejecución de la declaración de consulta
Como se puede ver en la figura anterior, una declaración SQL necesita generar un árbol de consultas mediante el análisis SQL, optimizar la consulta para generar un plan de ejecución y luego transferir el plan de ejecución al ejecutor de consultas para realizar operaciones de ejecución del operador físico.
SQL es un lenguaje descriptivo entre el cálculo relacional y el álgebra relacional. Absorbe la descripción de algunos operadores lógicos en el álgebra relacional y abandona la parte "procedimental" del álgebra relacional. La función principal del análisis SQL es compilar una declaración SQL en un árbol de consulta compuesto por operadores relacionales, que generalmente incluye submódulos de análisis léxico, de sintaxis y de análisis semántico.
La optimización de reglas (RBO) realiza una transformación de álgebra relacional equivalente sobre la base del árbol de consultas, convirtiendo una declaración SQL en un SQL equivalente más eficiente y desempeña un papel clave en el optimizador de la base de datos. Especialmente en consultas complejas, puede aportar mejoras de gran magnitud en el rendimiento.
La ejecución de consultas consiste en ejecutar declaraciones de consulta SQL de acuerdo con el plan de ejecución. La racionalidad de la elección del método de almacenamiento subyacente afectará la eficiencia de la ejecución de consultas.
analizador
1. Análisis léxico : Identifique las palabras clave, identificadores, operadores, terminales, etc. admitidos por el sistema a partir de la declaración de consulta y determine la parte gramatical inherente de cada palabra.
El estándar SQL define palabras clave SQL e información de reglas gramaticales. Durante el proceso de análisis léxico, GaussDB divide una declaración SQL en unidades atómicas independientes según la información de palabras clave y la información de intervalo, y cada unidad se muestra como una palabra.
2. Análisis gramatical : De acuerdo con las reglas gramaticales SQL definidas, utilice las palabras generadas en el análisis léxico para que coincidan con las reglas gramaticales y genere el árbol de sintaxis abstracta (AST) correspondiente.
3. Análisis semántico : verifique la validez del árbol de sintaxis, verifique si las tablas, columnas, funciones y expresiones correspondientes en el árbol de sintaxis tienen metadatos correspondientes y convierta el árbol de sintaxis abstracta en un árbol de consulta.
El proceso de análisis semántico es también el proceso de vinculación semántica de validez. Mediante la inspección del análisis semántico, el árbol de sintaxis abstracta se convierte en un árbol de consulta. Los árboles de consulta se pueden representar en forma de expresiones de álgebra relacional.
optimizador
El optimizador es un medio muy importante para mejorar la eficiencia de las consultas. Incluye dos partes: optimización de reglas y optimización de consultas.
La optimización de reglas es una transformación de álgebra relacional equivalente basada en el árbol de consultas. Dado que es una forma de optimización basada en álgebra relacional, también se puede llamar optimización algebraica. Aunque los resultados obtenidos por dos expresiones de álgebra relacional son exactamente iguales, sus costos de ejecución pueden ser muy diferentes, lo que forma la base de la optimización de reglas.
La optimización de reglas sigue dos principios básicos:
(1) Equivalencia: los resultados de salida de la declaración original y la declaración reescrita son los mismos.
(2) Eficiencia: la declaración reescrita tarda menos en ejecutarse que la declaración original y utiliza los recursos de manera más eficiente.
GaussDB implementa algunas técnicas clave de optimización de reglas, como:
Predicado pushdown : activa el filtrado condicional antes y reduce el número de filas procesadas
Eliminación de operaciones redundantes : Elimine tablas y columnas redundantes para reducir la cantidad de cálculos.
Promoción de subconsulta : después de la promoción, se pueden igualar más pedidos de unión
Conversión de exterior a interior : la unión interna puede coincidir con más órdenes de unión
Promoción de subvínculos : reduce las operaciones de subplan y transmisión
Elimine las uniones desiguales : reduzca las operaciones de NestLoop y Broadcast
En el proceso de atender a una gran cantidad de clientes, GaussDB abstrae los patrones de uso de SQL empresarial e implementa algunas reglas de reescritura avanzadas. En columnas futuras, presentaremos en detalle la tecnología de optimización de reglas de GaussDB.
Optimización de consultas
La optimización de consultas se basa en el resultado de la "optimización de reglas" y se combina con la información estadística interna de la base de datos para planificar el método de ejecución específico de la declaración SQL, es decir, el plan de ejecución. Según diferentes métodos de optimización, la tecnología de optimización de consultas se puede dividir en:
(1) CBO (optimización basada en costos, optimización de consultas basada en costos): estime el costo de las rutas de ejecución candidatas correspondientes a la declaración SQL y seleccione la ruta de ejecución de menor costo de las rutas candidatas como plan de ejecución final.
(2) ABO (optimización basada en IA, optimización de consultas basada en aprendizaje automático): a través del aprendizaje continuo de la experiencia histórica, ABO abstrae el patrón del escenario objetivo, forma un modelo dinámico y optimiza de forma adaptativa el escenario real del usuario, obteniendo así el. plan de ejecución óptimo.
GaussDB utiliza tecnología de optimización basada en CBO y la combina con ABO para explorar activamente la eficiencia del modelado, la precisión de la estimación y la adaptabilidad.
Figura (5) Pasos de optimización de consultas
Modelo de información estadística : la información estadística es la piedra angular del cálculo del costo de la ruta del plan. La precisión de la información estadística juega un papel crucial en la estimación del número de filas y la estimación de costos en el modelo de estimación de costos, lo que afecta directamente la calidad del plan de consulta. Las características de los datos de la tabla base de GaussDB incluyen valores distintos, valores MCV (valores más comunes), histogramas, etc.
Estimación de filas : después de que una restricción determina la tasa de selección, se puede determinar la cantidad de filas que se deben procesar para cada ruta planificada y se puede calcular la cantidad de páginas que se deben procesar en función de la cantidad de filas para las que se debe preparar. estimación de costos.
Estimación de costos : Estima los costos de ejecución de diferentes operadores en función de la cantidad de datos. La suma de los costos de cada operador es el costo total del plan.
Cuando la ruta planificada procesa páginas, hay un costo de E/S, y cuando la ruta planificada procesa tuplas (por ejemplo, evaluación de expresiones en tuplas), hay un costo de CPU. Dado que GaussDB es una base de datos distribuida, la transmisión de datos entre CN y DN generará costos de comunicación. Por lo tanto, el costo total de un plan se puede expresar como:
Costo total = costo de IO + costo de CPU + costo de comunicación
-
Búsqueda de ruta: procese el proceso de búsqueda de ruta de conexión resolviendo el algoritmo de ruta óptima (programación dinámica, algoritmo genético) y encuentre la ruta de conexión óptima con el espacio de búsqueda mínimo.
GaussDB utiliza una combinación de modos de búsqueda aleatoria y ascendente. El proceso de búsqueda también es un proceso de transformación de un árbol de consultas a un plan de ejecución. Por ejemplo, cada tabla puede tener diferentes operadores de escaneo y los operadores de unión lógica también se pueden convertir en una variedad de operadores de unión físicos diferentes.
-
Generación del plan: convierta la ruta de ejecución de la consulta en un plan de ejecución (PlanTree) y entréguelo al ejecutor para su ejecución.
La optimización de consultas puede llevar mucho tiempo, especialmente cuando se trata de consultas complejas. El almacenamiento en caché del plan es una característica importante de GaussDB. Puede almacenar en caché el plan de ejecución de una declaración de consulta para que el plan de ejecución en el caché pueda usarse directamente la próxima vez que se ejecute la misma consulta, evitando así cálculos repetidos y optimizando el rendimiento de la consulta.
Optimización de consultas distribuidas
Como base de datos distribuida nativa, la tecnología de optimización de consultas distribuidas es particularmente importante.
La arquitectura distribuida GaussDB aprovecha al máximo los recursos informáticos de cada nodo y su rendimiento general aumenta linealmente a medida que se expande la escala del nodo. Para maximizar el rendimiento y la utilización de recursos bajo una arquitectura distribuida, GaussDB admite cuatro planes distribuidos, a saber, el plan ligero CN, el plan FQS (Fast Query Shipping), el plan Stream y el plan Remote-Query, como se muestra en la siguiente figura:
Figura (6) Cuatro planes distribuidos
-
CN ligero: las declaraciones se envían directamente a un único DN para su ejecución (LIGHT_PROXY)
-
Principio de ejecución: CN entrega directamente el mensaje QPBE de declaración al DN correspondiente a través del socket.
-
-
Escenarios aplicables: la declaración se puede ejecutar directamente en un DN (declaración de fragmento único).
-
Emisión de declaraciones FQS (Fast Query Shipping): plan para emitir declaraciones SQL
(REMOTE_FQS_QUERY)
-
Principio de ejecución: CN genera directamente un plan RemoteQuery sin pasar por el optimizador y lo envía a DN a través de la lógica del ejecutor. Cada DN genera un plan de ejecución basado en la declaración pushdown y lo ejecuta, y los resultados de la ejecución se resumen en el CN.
-
-
-
Escenarios aplicables: las declaraciones se pueden enviar completamente a varios DN para su ejecución y no se requiere interacción de datos entre los DN.
-
-
Entrega del plan STREAM: plan de distribución del plan SQL distribuido (STREAM)
-
Principio de ejecución: CN genera un plan de ejecución con operadores de flujo basado en la declaración original a través del optimizador y lo envía a DN para su ejecución. Hay interacción de datos (nodo de flujo) durante el proceso de ejecución de DN. El operador de flujo establece conexiones entre DN para el intercambio de datos y CN resume los resultados de la ejecución. DN realiza la mayoría de los cálculos.
-
-
-
Escenarios aplicables: declaraciones complejas con interacción de datos entre CN y DN, y entre DN y DN durante la ejecución .
-
-
Plan de consulta remota: plan distribuido para emitir algunas declaraciones SQL (REMOTE_QUERY)
-
Principio de ejecución: CN genera un plan RemoteQuery a partir de parte de la declaración original a través del optimizador y envía cada RemoteQuery a DN. Después de ejecutar DN, los datos del resultado intermedio se envían a CN. Después de que CN los recopila, realiza el cálculo de ejecución. el resto del plan de ejecución, por lo tanto, CN realiza la mayoría de los cálculos.
-
-
Escenarios aplicables: hay muy pocos escenarios que no cumplan con las tres primeras condiciones de generación y el rendimiento es muy pobre.
En una arquitectura distribuida, los datos de la misma tabla se distribuirán a diferentes nodos de datos. Al crear una tabla, puede optar por realizar hash o distribuir aleatoriamente los datos en cada tabla. Para realizar correctamente una operación de unión entre dos tablas, puede ser necesario redistribuir los datos de las dos tablas. Por lo tanto, el plan de ejecución distribuida de GaussDB agrega tres operadores Stream que hacen que los datos formen un método de distribución específico.
Figura (7) Operador de flujo
Al generar una ruta distribuida, se considerará si los datos en las dos tablas y las condiciones de conexión están en el mismo nodo de datos. De lo contrario, se agregará el operador de distribución de datos correspondiente. El operador Stream de redistribución se selecciona según el principio de reducir el flujo de datos entre los nodos DN.
Precisamente basándose en el uso razonable de los operadores Stream, GaussDB puede procesar datos a gran escala en una arquitectura distribuida. La optimización de los operadores Stream también es una parte importante de la optimización de consultas de GaussDB.
Figura (8) Tecnología de optimización de consultas distribuidas GaussDB
[ Puntos técnicos clave ] Optimización de consultas distribuidas: cuatro planes de ejecución distribuida y tres operadores Stream.
Solenoide
La instrucción recibida por el ejecutor es el plan de ejecución generado por el optimizador para la declaración de consulta SQL. El plan de ejecución se compone de algunos operadores de ejecución (Operadores), expresiones, etc. Opera principalmente en el conjunto de relaciones y finalmente genera lo que el usuario desea. resultados. Los siguientes son varios tipos comunes de operadores de ejecución:
1. Nodo del plan de escaneo
El nodo de escaneo es responsable de extraer datos de fuentes de datos subyacentes, que pueden ser del sistema de archivos o de la red. En términos generales, los nodos de escaneo están ubicados en los nodos hoja del árbol de ejecución y sirven como fuente de entrada de datos para la ejecución y generalmente representan SeqScan, IndexScan y SubQueryScan.
Características clave: datos de entrada, nodos hoja, filtrado de expresiones.
2. Nodo Plan de Control
Los operadores de control generalmente no asignan operadores algebraicos, pero son operadores introducidos para que el ejecutor complete algunos procesos especiales, como Límite, Unión recursiva y Unión.
Características clave: Se utiliza para controlar el flujo de datos.
3. Materializar el nodo del plan
Los operadores materializados generalmente se refieren a los requisitos del algoritmo. Al realizar el procesamiento lógico del operador, es necesario almacenar en caché los datos de la capa inferior. Debido a que la cantidad de datos devueltos por los operadores de la capa inferior no se puede predecir de antemano, es necesario considerarlos. algoritmo que no se pueden colocar todos los datos Condiciones de memoria, como Agg, Sort.
Característica clave: todos los datos deben escanearse antes de regresar
4. Plan de unión Los operadores de nodo están diseñados para manejar las operaciones de asociación más comunes en bases de datos. Se dividen en MergeJoin, NestLoop Join y HashJoin según diferentes algoritmos de procesamiento y fuentes de entrada de datos.
Características clave: consulta relacionada
5. Otros operadores
La arquitectura y la tecnología del ejecutor también determinan la eficiencia operativa general de la ejecución de consultas de la base de datos. El motor de ejecución GaussDB combina completamente las características de la tecnología de hardware moderna y utiliza una variedad de tecnologías de software modernas, como motores de vectorización y LLVM, para una ejecución eficiente.
Figura (9) Arquitectura de ejecución totalmente paralela de GaussDB
GaussDB también utiliza una variedad de tecnologías para mejorar el rendimiento de la ejecución de consultas durante la ejecución de planes distribuidos. Por ejemplo, al ejecutar consultas complejas, el operador de reejecución se enviará al nodo DN para su ejecución, como el operador AGG. Cuando se ejecuta el operador pushdown, se considerará la localidad de los datos y el cálculo se realizará localmente tanto como sea posible para reducir la sobrecarga de transmisión de datos en la red.
Si tiene alguna pregunta o está interesado en puntos técnicos clave, puede revelar el misterio del motor SQL GaussDB en [Preguntas y respuestas de Yunka], interactuar entre sí y dejar un mensaje en la publicación para ganar regalos. Los expertos responderán sus preguntas. uno a uno, y también tener la oportunidad de recibir incentivos por hacer preguntas.
Haga clic para seguir y conocer las nuevas tecnologías de Huawei Cloud lo antes posible ~
Linus tomó el asunto en sus propias manos para evitar que los desarrolladores del kernel reemplacen las pestañas con espacios. Su padre es uno de los pocos líderes que puede escribir código, su segundo hijo es el director del departamento de tecnología de código abierto y su hijo menor es un núcleo. Colaborador de código abierto Huawei: tomó 1 año convertir 5000 aplicaciones móviles de uso común Migración completa a Hongmeng Java es el lenguaje más propenso a vulnerabilidades de terceros Wang Chenglu, el padre de Hongmeng: el código abierto Hongmeng es la única innovación arquitectónica. En el campo del software básico en China, Ma Huateng y Zhou Hongyi se dan la mano para "eliminar rencores". Ex desarrollador de Microsoft: el rendimiento de Windows 11 es "ridículamente malo " " Aunque lo que Laoxiangji es de código abierto no es el código, las razones detrás de él. Son muy conmovedores. Meta Llama 3 se lanza oficialmente. Google anuncia una reestructuración a gran escala.