Recientemente, la Conferencia de Tecnología China de PostgreSQL comenzó en Hangzhou. Como evento anual en el campo de la tecnología PostgreSQL, la Conferencia de Tecnología China de PostgreSQL se ha llevado a cabo durante 12 años consecutivos y ha brindado una plataforma abierta para la cooperación, el intercambio y la asistencia mutua para todos los pequeños socios amantes de la tecnología de bases de datos. Y esta conferencia, en torno a los temas de seguridad y confiabilidad, avance, evolución, etc., ha convocado a muchos expertos de la industria y expertos técnicos para discutir tecnologías y colisionar ideas aquí.
Como casi unicornio del Día 1 en el campo de datos en la nube y computación de datos en China, Guo Feng, un experto técnico de Tuoshupai, fue invitado a asistir a esta conferencia y pronunciar un discurso de apertura.
En su discurso, Guo Feng presentó un nuevo optimizador construido por PieCloudDB Database - "Daqi". El nombre "Daqi" se originó a partir de un juego popular entre los jóvenes: "Red Dead Redemption". El mantra de un personaje NPC llamado "Daqi" en el juego es "Tengo un plan", que "casualmente coincide con" el papel principal del optimizador.
El optimizador es un componente importante en el sistema de la base de datos, que es "responsable" de analizar, optimizar y generar planes de ejecución para las solicitudes de consulta de los usuarios, de modo que los resultados de la consulta puedan devolverse a la velocidad más rápida y con la mayor eficiencia. El optimizador logra el propósito de optimizar el rendimiento de las consultas al generar un plan de ejecución de consultas óptimo. La calidad del plan de ejecución a menudo da como resultado cientos de diferencias de rendimiento. El optimizador "Daqi" creado por PieCloudDB ha implementado una gran cantidad de funciones de optimización y, como "grupo de expertos" del sistema de base de datos, ayuda a PieCloudDB a mejorar el rendimiento.
Al igual que PostgreSQL, el proceso de optimización de consultas de PieCloudDB generalmente se divide en cuatro etapas: etapa de preprocesamiento, etapa de optimización de escaneo/unión, etapa de optimización distinta del escaneo/unión y etapa de posprocesamiento. "Daqi" ha realizado muchas optimizaciones en estas cuatro etapas de procesamiento.
En la etapa de preprocesamiento, el optimizador "Daqi" convertirá el árbol de consulta en una ecuación más simple y eficiente a través de cambios lógicamente equivalentes. Dado que no se ha obtenido alguna información estadística para ayudar a calcular la información de costos, en esta etapa, generalmente se utilizan algunas reglas comprobadas para realizar operaciones como restricciones de distribución, expresiones simplificadas y árboles de conexión para eliminar conexiones inútiles.
-
Convierta IN, EXISTS y otros tipos de subconsultas en semi-uniones
PieCloudDB divide las subconsultas en subenlaces (SubLink) y subconsultas (SubQuery) según la ubicación y el rol de las subconsultas. Debido a que las subconexiones aparecen en restricciones como WHERE/ON, a menudo van acompañadas de verbos predicados como ANY/ALL/EXISTS. Si el ejecutor lo maneja en forma de subconexión, afectará la eficiencia de la consulta. Y debido a la generación de subplanes (SubPlan), el espacio de optimización es limitado. Por lo tanto, en la etapa de preprocesamiento de la optimización de consultas, PieCloudDB convertirá las subuniones en semi-join o anti-join tanto como sea posible, para tener más espacio para la optimización.
Tome la siguiente consulta SQL como ejemplo:
SELECT … FROM foo WHERE EXISTS (SELECT 1 FROM bar WHERE foo.a = bar.c);Entre ellos, EXISTS es una subconsulta, y PieCloudDB la convertirá en Semi-Join en la etapa de preprocesamiento:
SELECT ... FROM foo *SEMI JOIN* bar ON foo.a = bar.c;- aumentar la subconsulta
Las cláusulas que aparecen después de la palabra clave FROM son declaraciones de subconsulta. Si no se realiza la optimización, al ejecutar este tipo de subconsulta, primero se realizará un plan separado, se generará un escaneo de subconsulta y luego se conectará con la consulta principal, a menudo no se puede encontrar la solución óptima, lo que resulta en un mayor costo de consulta.
Tome el siguiente ejemplo como ejemplo. Si no se realiza ninguna optimización, bar y baz se conectarán JOIN primero. Dado que no hay una condición de conexión, bar y baz serán productos cartesianos directamente, y luego se conectarán JOIN con foo afuera:
SELECT * FROM foo JOIN (SELECT bar.c FROM bar JOIN baz ON TRUE) AS sub ON foo.a = sub.c;Después de la actualización, bar y baz están en el mismo nivel, y la unión de foo y bar se puede generar primero, y luego unirse con baz, para que el costo sea menor:
SELECT * FROM foo JOIN (bar JOIN baz ON TRUE) ON foo.a = bar.c;- Convertir unión externa a unión interna/antiunión
Las uniones externas tienen muchas restricciones en la inserción de predicados y la búsqueda de orden de conexión, por lo que "Daqi" intentará convertir las uniones externas en uniones internas (unión interna) o uniones anti (unión anti) en la etapa de preprocesamiento.
En la siguiente instrucción SQL, el resultado de LEFT JOIN producirá algunas tuplas terminadas en NULL y el signo igual en la condición WHERE es una restricción estricta, lo que significa que si la entrada es NULL, la salida también debe ser NULL o FALSE. Si la columna en la barra es NULL, entonces bar.d = 42 filtra a FALSO. Es decir, la tupla llena de NULL generada por LEFT JOIN será filtrada por la condición WHERE En este momento, LEFT JOIN se convierte semánticamente en INNER JOIN.
SELECT ... FROM foo LEFT JOIN bar ON (...) WHERE bar.d = 42;En este caso, el optimizador PieCloudDB "Daqi" reconoce automáticamente tales consultas y aprovecha tales oportunidades de optimización para convertir uniones externas en uniones internas.
SELECT ... FROM foo INNER JOIN bar ON (...) WHERE bar.d = 42; Para las uniones externas en algunos casos, el optimizador PieCloudDB convertirá las uniones externas en anti-uniones en la etapa de preprocesamiento. Tome la siguiente sentencia SQL como ejemplo:
SELECT * FROM foo LEFT JOIN bar ON foo.a = bar.c WHERE bar.c IS NULL; Igual que en el ejemplo anterior, LEFT JOIN también generará una gran cantidad de conjuntos de resultados de tupla llenos de NULL. En este momento, la condición WHERE solo toma bar.c como resultados NULL. En este momento, semánticamente, LEFT JOIN es un anti-join . PieCloudDB detectará automáticamente esta oportunidad de optimización en la etapa de preprocesamiento y convertirá la conexión externa a la conexión interna:
SELECT * FROM foo *ANTI JOIN* bar on foo.a = bar.c; Además de estas optimizaciones, en la etapa de preprocesamiento, el optimizador "Daqi" también implementa múltiples optimizaciones, entre ellas:
-
restricciones de distribución
-
construir clase de equivalencia
-
Recopilar información de conexión externa
-
Eliminar conexiones inútiles
-
expresión simplificada
esperar…
La fase de optimización de escaneo/unión es posiblemente la fase más compleja del procesamiento del optimizador. En esta etapa, el optimizador "Daqi" será impulsado por el costo para procesar las partes DESDE y DONDE de la declaración de consulta, y también tendrá en cuenta la información de ORDEN POR.
En esta etapa, el procesamiento del optimizador "Daqi" se puede dividir principalmente en dos pasos. En primer lugar, se genera una ruta de exploración para la tabla base y se calcula el costo de la ruta de exploración y el tamaño del conjunto de resultados para obtener el costo de las operaciones de combinación posteriores. En el segundo paso, "Daqi" buscará en todo el espacio de la secuencia de conexión para generar la ruta de conexión óptima para la operación de conexión. La complejidad de este paso es muy alta (nivel n!), PieCloudDB utiliza dos algoritmos de programación dinámica y un algoritmo genético para procesar, y selecciona el algoritmo de acuerdo con el valor de GUC. Si una combinación externa está involucrada en la declaración de consulta, considerando la restricción de la combinación externa en el orden de conexión, el orden de la conexión no se puede cambiar a voluntad como la combinación interna, lo que aumentará la complejidad de este paso.
En comparación con la segunda etapa, aunque esta etapa se ocupa de muchas cosas, su complejidad es relativamente baja. En esta etapa, "Daqi" primero procesará Group By, agregación, función de ventana, DISTINCT, luego procesará operaciones de conjuntos y finalmente procesará ORDER BY. Cada una de las operaciones anteriores generará una o más rutas, y "Daqi" filtrará estas rutas según el costo y agregará LockRows, Limit y ModifyTable a las rutas filtradas.
Después de las primeras tres etapas, "Daqi" ha generado un plan de consulta aproximado. En la etapa de posprocesamiento, "Daqi" convertirá la ruta óptima seleccionada en un plan de consulta y realizará algunos ajustes en el plan óptimo.
Además de las funciones de optimización mencionadas anteriormente, el optimizador de PieCloudDB "Daqi" ha realizado muchas optimizaciones y mejoras en escenarios de consulta complejos y ha realizado muchas funciones distribuidas de alto nivel y nativas de la nube .
Sobre la base de las funciones de optimización anteriores, el optimizador "Daqi" ha ampliado muchas funciones de optimización para la distribución. En primer lugar, "Daqi" introdujo el concepto de Movimiento, de modo que los datos se pueden mover entre diferentes nodos de ejecución (Ejecutor). Con Motion, "Daqi" puede generar planes de consulta distribuidos. Estos planes de consulta se dividen en unidades más pequeñas y se distribuyen a diferentes nodos de ejecución para la ejecución en paralelo. Con la ejecución en paralelo, muchas consultas complejas se pueden optimizar aún más. Por ejemplo, para las operaciones de agregación, aprovechando la distribución, el rendimiento se puede mejorar a través de la agregación de varias etapas entre los nodos de ejecución.
Tome esta consulta como ejemplo para explicar la agregación de varias etapas. Para esta consulta SQL, "Daqi" generará un plan de consulta de este tipo:
Debido a la existencia de una operación de deduplicación, "Daqi" realizará una agregación de tres etapas. En la primera etapa, PieCloudDB primero realizará una agregación local en cada nodo de ejecución con a y b como clave de grupo. Aquí se realiza una operación de deduplicación parcial. terminado. Luego, use Motion para realizar una operación de reorganización y luego realice una operación de agregación en este momento para completar la deduplicación global. Finalmente, complete la operación de agregación final según la clave de grupo para obtener el resultado de la consulta.
Debido a que el motor de almacenamiento de PieCloudDB "Jianmo" adopta el diseño de almacenamiento de objetos, combinado con este diseño, el optimizador de PieCloudDB "Daqi" realiza optimizaciones más avanzadas, que incluyen agregación pushdown, omisión de bloques, precálculo, etc. Aquí hay una introducción a la agregación y la inserción. Con respecto a otras características nativas de la nube de "Daqi", preste atención a otro contenido que se lanzará uno tras otro.
PieCloudDB implementa Aggregate Pushdown, que puede reducir efectivamente la transmisión y el procesamiento de datos en el plan de ejecución de consultas y mejorar la eficiencia de las consultas . En escenarios analíticos, las operaciones de agregación como SUM, AVG, MAX y MIN son operaciones comunes que se pueden usar para agregar datos en tablas de base de datos. Cuando la mayoría de los almacenes de datos procesan operaciones de agregación, generalmente necesitan completar exploraciones de tablas y unir operaciones primero, y luego calcular funciones agregadas. En el caso de una gran cantidad de datos, el rendimiento de dicha consulta será relativamente bajo.
La estrategia de optimización de inserción de agregación implementada por el optimizador PieCloudDB "Daqi" puede reducir en gran medida la cantidad de datos que debe procesar la operación de conexión al empujar la operación de agregación hacia abajo para que se ejecute antes de la operación de conexión. el rendimiento mejorará cientos o incluso miles de veces.
Tome la siguiente consulta SQL como ejemplo. Esta consulta necesita unir la tabla t1 y la tabla t2. Sobre esta base, agrupe por t1.a para obtener el valor promedio de t2.c. En el caso de que no haya optimización pushdown de agregación , la operación de conexión de t1 y t2 se completará primero, y luego la operación de agregación se realizará de acuerdo con la agrupación de t1.a. En este momento, si las tablas t1 y t2 son grandes, el costo de la operación de combinación es muy alto, lo que tendrá un cierto impacto en el rendimiento . Bajo la optimización de agregación y pushdown, la operación de agregación se realizará antes de la conexión. En este momento, si t2.b está muy agregado, la cantidad de datos se reducirá mucho. Si la operación de conexión se realiza en este momento, el rendimiento será mejorado en gran medida .
El optimizador de consultas es uno de los componentes más importantes y complejos de un sistema de base de datos. Como almacén de datos virtual nativo de la nube, PieCloudDB continuará puliendo el optimizador "Daqi" e impulsará continuamente la mejora del rendimiento con la premisa de garantizar el funcionamiento eficiente y estable del sistema de base de datos.
El 14 de marzo, se lanzó oficialmente la versión "Cloud on Cloud" de PieCloudDB basada en la nueva generación de virtualización de almacenamiento de datos nativa de la nube. Le invitamos a iniciar sesión en www.openpie.com para una prueba gratuita.