Este artigo é compartilhado pela Huawei Cloud Community " [GaussTech Issue 2] Análise do processo de execução de instrução de consulta SQL do GaussDB ", autor: banco de dados GaussDB.
A importância do SQL para bancos de dados relacionais é evidente. Como um maestro de orquestra, ele orienta a correta interpretação da obra e a harmonia e unidade do ritmo. Como uma nova geração de banco de dados relacional distribuído, o Huawei Cloud GaussDB possui excelente desempenho técnico e competitividade no setor. Muitas pessoas estão curiosas sobre as principais tecnologias do GaussDB e deixaram mensagens no fórum:
Hoje começaremos com o mecanismo SQL do GaussDB e aprenderemos sobre o processo de execução das instruções de consulta SQL do GaussDB, incluindo os princípios e os principais pontos técnicos do mecanismo SQL do GaussDB.
Se você tiver alguma dúvida ou pontos técnicos importantes de interesse durante o processo de compreensão, você pode participar de [Yunka Q&A] para descobrir o mistério do mecanismo SQL do GaussDB, interagir e ganhar presentes e deixar mensagens para interação. -one Responda às perguntas e você terá a chance de receber recompensas por fazer perguntas.
↓↓↓↓ A seguir está o texto
Primeiro, vamos apresentar brevemente a estrutura do sistema do GaussDB e, em seguida, analisar o processo de execução das instruções de consulta SQL do GaussDB.
Arquitetura do sistema GaussDB
Figura (1) Centralizado
Figura (2) Distribuição
Durante a execução das instruções SQL do GaussDB, as seguintes funções principais estão envolvidas:
| GTM |
O Global Transaction Manager é responsável por gerar e manter informações globalmente exclusivas, como IDs de transações globais, instantâneos de transações, carimbos de data/hora e informações de sequência. |
| NC |
Nó Coordenador. Responsável por receber solicitações de acesso das aplicações e retornar resultados de execução ao cliente responsável por decompor tarefas e agendar shards de tarefas para serem executadas em paralelo em cada DN; Cada CN está conectado a cada DN e cada CN contém uma cópia dos metadados com o mesmo conteúdo de metadados. |
| DN |
Nó de dados. Responsável por armazenar dados de negócios (suportando armazenamento de linhas, armazenamento de colunas e armazenamento híbrido), executar tarefas de consulta de dados e retornar resultados de execução ao CN. |
Entre eles, o DN é o principal responsável pela execução das instruções SQL do GaussDB. Sua arquitetura lógica é mostrada na figura a seguir:
Figura (3) Arquitetura lógica GaussDB
GaussDB inclui dois motores principais: SQL Engine e Storage Engine . O mecanismo SQL às vezes é chamado de processador de consulta e suas funções principais são análise de SQL, otimização de consulta e execução de consulta. A análise SQL executa análise lexical, análise de sintaxe e análise semântica na instrução SQL de entrada para gerar uma árvore de consulta. Após a árvore de consulta passar pela otimização de regras (RBO) e otimização de custos (CBO), um plano de execução é gerado. O executor extrai, opera, atualiza, exclui e outras operações em dados relevantes com base no plano de execução para alcançar os resultados que o usuário deseja consultar.
O mecanismo de armazenamento é responsável por gerenciar toda a E/S de dados. Inclui processamento de leitura e gravação de dados (processamento de solicitações de E/S para linhas, índices, páginas, alocações e versões de linha), gerenciamento de buffer de dados (Buffer Pool) e transação. gerente. Entre eles, o gerenciamento de transações envolve o mecanismo de bloqueio (Lock) e o gerenciamento de log de transações (XLOG) que mantêm atributos ACID.
Entre o mecanismo SQL e o mecanismo de armazenamento está a camada AM (Método de Acesso). AM encapsula a camada de armazenamento para suportar vários mecanismos de armazenamento (Astore, Ustore, etc.). A camada SQL não chama a camada de armazenamento diretamente, mas através da camada AM, a camada AM chamará diferentes corpos de execução de acordo com os diferentes mecanismos de armazenamento.
Pode ser visto no diagrama de arquitetura lógica do GaussDB que o design da arquitetura do GaussDB segue os princípios de design da abstração do sistema de software moderno e do desacoplamento hierárquico, incluindo: mecanismo de transação unificado, sistema de log unificado, sistema de controle de simultaneidade unificado, sistema de meta-informação unificado e sistema unificado de gerenciamento de cache. Portanto, a arquitetura técnica do GaussDB possui as seguintes características principais:
-
Suporta otimização de SQL, execução e desacoplamento da camada de armazenamento;
-
Suporta mecanismos de armazenamento conectáveis.
Processo de execução da instrução de consulta SQL
O processo de execução de uma instrução de consulta SQL (SELECT) é o seguinte:
Figura (4) Processo de execução da instrução de consulta
Como pode ser visto na figura acima, uma instrução SQL precisa gerar uma árvore de consulta por meio de análise SQL, otimização de consulta para gerar um plano de execução e, em seguida, transferir o plano de execução para o executor de consulta para realizar operações de execução do operador físico.
SQL é uma linguagem descritiva entre cálculo relacional e álgebra relacional. Ela absorve a descrição de alguns operadores lógicos na álgebra relacional, abandonando a parte "procedural" da álgebra relacional. A principal função da análise SQL é compilar uma instrução SQL em uma árvore de consulta composta de operadores relacionais, que geralmente inclui submódulos de análise lexical, análise de sintaxe e análise semântica.
A otimização de regras (RBO) realiza uma transformação de álgebra relacional equivalente com base na árvore de consulta, convertendo uma instrução SQL em um SQL equivalente mais eficiente e desempenha um papel fundamental no otimizador de banco de dados. Especialmente em consultas complexas, pode trazer melhorias de ordem de magnitude no desempenho.
A execução da consulta consiste em executar instruções de consulta SQL de acordo com o plano de execução. A racionalidade da escolha do método de armazenamento subjacente afetará a eficiência da execução da consulta.
analisador
1. Análise lexical : Identifique as palavras-chave, identificadores, operadores, terminais, etc. suportados pelo sistema a partir da instrução de consulta e determine a classe gramatical inerente de cada palavra.
O padrão SQL define palavras-chave SQL e informações de regras gramaticais Durante o processo de análise lexical, o GaussDB divide uma instrução SQL em unidades atômicas independentes com base nas informações de palavras-chave e informações de intervalo, e cada unidade é exibida como uma palavra.
2. Análise gramatical : De acordo com as regras gramaticais SQL definidas, use as palavras geradas na análise lexical para corresponder às regras gramaticais e gerar a Árvore de Sintaxe Abstrata (AST) correspondente.
3. Análise semântica : verifique a validade da árvore sintática, verifique se as tabelas, colunas, funções e expressões correspondentes na árvore sintática possuem metadados correspondentes e converta a árvore sintática abstrata em uma árvore de consulta.
O processo de análise semântica é também o processo de vinculação semântica de validade. Através da inspeção da análise semântica, a árvore sintática abstrata é convertida em uma árvore de consulta. As árvores de consulta podem ser representadas na forma de expressões de álgebra relacional.
otimizador
O otimizador é um meio muito importante para melhorar a eficiência da consulta. Ele inclui duas partes: otimização de regras e otimização de consulta.
A otimização de regras é uma transformação de álgebra relacional equivalente baseada na árvore de consulta. Por ser uma forma de otimização baseada na álgebra relacional, também pode ser chamada de otimização algébrica. Embora os resultados obtidos por duas expressões de álgebra relacional sejam exatamente iguais, seus custos de execução podem ser muito diferentes, o que constitui a base da otimização de regras.
A otimização de regras segue dois princípios básicos:
(1) Equivalência: Os resultados de saída da declaração original e da declaração reescrita são os mesmos.
(2) Eficiência: A instrução reescrita leva menos tempo para ser executada do que a instrução original e utiliza recursos de forma mais eficiente.
GaussDB implementa algumas técnicas importantes de otimização de regras, como:
Pushdown de predicado : acione a filtragem condicional mais cedo e reduza o número de linhas processadas
Eliminação de operações redundantes : Elimine tabelas e colunas redundantes para reduzir a quantidade de cálculos
Promoção de subconsulta : após a promoção, mais pedidos de adesão podem ser correspondidos
Conversão externa para interna : a junção interna pode corresponder a mais pedidos de junção
Promoção de sublink : reduza subplanos e operações de transmissão
Elimine junções desiguais : reduza as operações NestLoop e Broadcast
No processo de atender um grande número de clientes, o GaussDB abstrai os padrões de uso de SQL de negócios e implementa algumas regras avançadas de reescrita. Nas colunas futuras, apresentaremos detalhadamente a tecnologia de otimização de regras do GaussDB.
Otimização de consulta
A otimização de consulta é baseada na saída da “otimização de regras” e combinada com as informações estatísticas internas do banco de dados para planejar o método de execução específico da instrução SQL, ou seja, o plano de execução. Com base em diferentes métodos de otimização, a tecnologia de otimização de consultas pode ser dividida em:
(1) CBO (Otimização Baseada em Custo, otimização de consulta baseada em custo): Estime o custo dos caminhos de execução candidatos correspondentes à instrução SQL e selecione o caminho de execução de menor custo dos caminhos candidatos como o plano de execução final.
(2) ABO (AI Based Optimization, otimização de consulta baseada em aprendizado de máquina): Através do aprendizado contínuo da experiência histórica, ABO abstrai o padrão do cenário alvo, forma um modelo dinâmico e otimiza adaptativamente o cenário real do usuário, obtendo assim o cenário real. plano de execução ideal.
GaussDB usa tecnologia de otimização baseada em CBO e combina-a com ABO para explorar ativamente a eficiência da modelagem, precisão de estimativa e adaptabilidade.
Figura (5) Etapas de otimização de consulta
Modelo de informação estatística : A informação estatística é a base do cálculo do custo do caminho do plano. A precisão da informação estatística desempenha um papel crucial na estimativa do número de linhas e na estimativa de custos no modelo de estimativa de custos, o que afeta diretamente a qualidade do plano de consulta. As características dos dados da tabela base do GaussDB incluem valores distintos, valores MCV (valores mais comuns), histogramas, etc.
Estimativa de linha : depois que uma restrição determina a taxa de seleção, o número de linhas que precisam ser processadas para cada caminho planejado pode ser determinado e o número de páginas que precisam ser processadas pode ser calculado com base no número de linhas para preparar estimativa de custo.
Estimativa de Custos : Estime os custos de execução de diferentes operadoras com base na quantidade de dados. A soma dos custos de cada operadora é o custo total do plano.
Quando o caminho planejado processa páginas, há um custo de E/S, e quando o caminho planejado processa tuplas (por exemplo, avaliação de expressão em tuplas), há um custo de CPU. Como o GaussDB é um banco de dados distribuído, a transmissão de dados entre CN e DN incorrerá em custos de comunicação. Portanto, o custo total de um plano pode ser expresso como:
Custo total = custo de IO + custo de CPU + custo de comunicação
-
Pesquisa de caminho: processe o processo de pesquisa do caminho de conexão resolvendo o algoritmo ideal do caminho (programação dinâmica, algoritmo genético) e encontre o caminho de conexão ideal com o espaço de pesquisa mínimo.
GaussDB usa uma combinação de modos de pesquisa ascendente e aleatória. O processo de pesquisa também é um processo de transformação de uma árvore de consulta em um plano de execução. Por exemplo, cada tabela pode ter diferentes operadores de varredura e os operadores de junção lógica também podem ser convertidos em uma variedade de operadores de junção física diferentes.
-
Geração de plano: Converta o caminho de execução da consulta em um plano de execução (PlanTree) e forneça-o ao executor para execução.
A otimização de consultas pode levar muito tempo, especialmente ao lidar com consultas complexas. O cache de plano é um recurso importante do GaussDB. Ele pode armazenar em cache o plano de execução de uma instrução de consulta para que o plano de execução no cache possa ser usado diretamente na próxima vez que a mesma consulta for executada, evitando assim cálculos repetidos e otimizando o desempenho da consulta.
Otimização de consulta distribuída
Como um banco de dados distribuído nativo, a tecnologia de otimização de consultas distribuídas é particularmente importante.
A arquitetura distribuída GaussDB faz uso total dos recursos computacionais de cada nó e seu desempenho geral aumenta linearmente à medida que a escala do nó se expande. Para maximizar o desempenho e a utilização de recursos em uma arquitetura distribuída, o GaussDB oferece suporte a quatro planos distribuídos, ou seja, plano leve CN, plano FQS (Fast Query Shipping), plano Stream e plano de consulta remota, conforme mostrado na figura a seguir:
Figura (6) Quatro planos distribuídos
-
CN leve: as instruções são enviadas diretamente para um único DN para execução (LIGHT_PROXY)
-
Princípio de execução: CN entrega diretamente a mensagem QPBE da instrução ao DN correspondente através do soquete.
-
-
Cenários aplicáveis: A instrução pode ser executada diretamente em um DN (instrução de fragmento único).
-
Emissão de instrução FQS (Fast Query Shipping): plano para emissão de instruções SQL
（REMOTE_FQS_QUERY）
-
Princípio de execução: CN gera diretamente um plano RemoteQuery sem passar pelo otimizador e o envia para DN através da lógica do executor. Cada DN gera um plano de execução baseado na instrução pushdown e o executa, e os resultados da execução são resumidos no CN.
-
-
-
Cenários aplicáveis: as instruções podem ser completamente enviadas para vários DNs para execução e nenhuma interação de dados é necessária entre os DNs.
-
-
Entrega do plano STREAM: Plano de distribuição do plano SQL distribuído (STREAM)
-
Princípio de execução: CN gera um plano de execução com operadores de fluxo baseado na instrução original por meio do otimizador e o envia ao DN para execução. Há interação de dados (nó de fluxo) durante o processo de execução do DN. O operador stream estabelece conexões entre DNs para troca de dados e o CN resume os resultados da execução. O DN realiza a maior parte dos cálculos.
-
-
-
Cenários aplicáveis: instruções complexas com interação de dados entre CN e DN, e entre DN e DN durante a execução .
-
-
Plano de Consulta Remota: plano distribuído para emissão de algumas instruções SQL (REMOTE_QUERY)
-
Princípio de execução: CN gera um plano RemoteQuery a partir de parte da instrução original por meio do otimizador e envia cada RemoteQuery para DN. Após a execução do DN, os dados do resultado intermediário são enviados para CN. Após a coleta, o CN executa o cálculo de execução. o restante plano de execução Portanto, a CN realiza a maior parte dos cálculos.
-
-
Cenários aplicáveis: Existem muito poucos cenários que não atendem às três primeiras condições de geração e o desempenho é muito ruim.
Em uma arquitetura distribuída, os dados da mesma tabela serão distribuídos para diferentes nós de dados. Ao criar uma tabela, você pode optar por fazer hash ou distribuir aleatoriamente os dados em cada tabela. Para realizar corretamente uma operação de junção entre duas tabelas, pode ser necessário redistribuir os dados das duas tabelas. Portanto, o plano de execução distribuída do GaussDB adiciona três operadores Stream que fazem com que os dados formem um método de distribuição específico.
Figura (7) Operador de fluxo
Ao gerar um caminho distribuído, será considerado se os dados das duas tabelas e as condições de conexão estão no mesmo nó de dados. Caso contrário, será adicionado o operador de distribuição de dados correspondente. O operador de redistribuição Stream é selecionado com base no princípio de redução do fluxo de dados entre os nós DN.
É precisamente com base no uso razoável de operadores Stream que é possível ao GaussDB processar dados em larga escala em uma arquitetura distribuída. A otimização dos operadores Stream também é uma parte importante da otimização de consultas do GaussDB.
Figura (8) Tecnologia de otimização de consulta distribuída GaussDB
[ Principais pontos técnicos ] Otimização de consulta distribuída: quatro planos de execução distribuídos e três operadores Stream.
Atuador do
A instrução recebida pelo executor é o plano de execução gerado pelo otimizador para a instrução de consulta SQL. O plano de execução é composto por alguns operadores de execução (Operadores), expressões, etc. conjunto de resultados desejado. A seguir estão vários tipos comuns de operadores de execução:
1. Nó do Plano de Varredura
O nó de varredura é responsável por extrair dados de fontes de dados subjacentes, que podem ser do sistema de arquivos ou da rede. De modo geral, os nós de varredura estão localizados nos nós folha da árvore de execução, servindo como fonte de entrada de dados para execução, normalmente representando SeqScan, IndexScan e SubQueryScan.
Principais recursos: dados de entrada, nós folha, filtragem de expressão
2. Nó Plano de Controle
Os operadores de controle geralmente não mapeiam operadores algébricos, mas são operadores introduzidos para o executor completar alguns processos especiais, como Limit, RecursiveUnion e Union.
Principais recursos: Usado para controlar o fluxo de dados
3. Materializar o nó do plano
Os operadores materializados geralmente se referem aos requisitos do algoritmo. Ao realizar o processamento da lógica do operador, os dados da camada inferior devem ser armazenados em cache. Como a quantidade de dados retornados pelos operadores da camada inferior não pode ser prevista com antecedência, é necessário considerar no. algoritmo que todos os dados não podem ser colocados em condições de memória, como Agg, Sort.
Característica principal: Todos os dados precisam ser digitalizados antes de retornar
4. Os operadores Join Plan Node são projetados para lidar com as operações de associação mais comuns em bancos de dados. Eles são divididos em MergeJoin, NestLoop Join e HashJoin de acordo com diferentes algoritmos de processamento e fontes de entrada de dados.
Principais recursos: consulta relacionada
5. Outros operadores
A arquitetura e a tecnologia do executor também determinam a eficiência operacional geral da execução de consultas ao banco de dados. O mecanismo de execução GaussDB combina totalmente as características da tecnologia de hardware moderna e usa uma variedade de tecnologias de software modernas, como mecanismos de vetorização e LLVM para uma execução eficiente.
Figura (9) Arquitetura de execução totalmente paralela do GaussDB
GaussDB também usa uma variedade de tecnologias para melhorar o desempenho de execução de consultas durante a execução de planos distribuídos. Por exemplo, ao executar consultas complexas, o operador de reexecução será enviado ao nó DN para execução, como o operador AGG. Quando o operador pushdown for executado, a localidade dos dados será considerada e o cálculo será realizado localmente tanto quanto possível para reduzir o overhead de transmissão de dados na rede.
Se você tiver alguma dúvida ou estiver interessado nos principais pontos técnicos, você pode desvendar o mistério do mecanismo SQL GaussDB em [Yunka Q&A], interagir uns com os outros e deixar uma mensagem na postagem do evento para ganhar presentes, e especialistas responderão perguntas individualmente e também têm a oportunidade de receber incentivos para fazer perguntas.
Clique para seguir e conhecer as novas tecnologias da Huawei Cloud o mais rápido possível~
Linus resolveu resolver o problema por conta própria para evitar que os desenvolvedores do kernel substituíssem tabulações por espaços. Seu pai é um dos poucos líderes que sabe escrever código, seu segundo filho é o diretor do departamento de tecnologia de código aberto e seu filho mais novo é um núcleo. contribuidor de código aberto Huawei: Demorou 1 ano para converter 5.000 aplicativos móveis comumente usados A migração abrangente para Hongmeng Java é a linguagem mais propensa a vulnerabilidades de terceiros Wang Chenglu, o pai de Hongmeng: Hongmeng de código aberto é a única inovação arquitetônica. no campo de software básico na China. Ma Huateng e Zhou Hongyi apertam as mãos para "remover rancores". Ex-desenvolvedor da Microsoft: o desempenho do Windows 11 é "ridiculamente ruim" " Embora o que Laoxiangji seja de código aberto não seja o código, as razões por trás disso são muito emocionantes. Meta Llama 3 é lançado oficialmente. Google anuncia uma reestruturação em grande escala.