Consulta paralela do Amazon Aurora MySQL - Amazon Aurora
Visão geral de consultas paralelas

Consulta paralela do Amazon Aurora MySQL

Este tópico descreve a performance de consultas paralelas do Amazon Aurora edição compatível com MySQL. Este recurso usa um caminho de processamento especial para determinadas consultas com muitos dados, aproveitando a arquitetura de armazenamento compartilhada do Aurora. As consultas paralelas funcionam melhor com clusters de bancos de dados Aurora MySQL que têm tabelas com milhões de linhas e consultas analíticas que levam minutos ou horas para concluir.

Tópicos

Visão geral de consultas paralelas do Aurora MySQL

A consulta paralela do Aurora MySQL é uma otimização que paraleliza uma parte da E/S e da computação envolvidas nas consultas de processamento com muitos dados. O trabalho que é paralelizado inclui linhas de recuperação de armazenamento, extração de valores de colunas e determinação de quais linhas correspondem às condições na cláusula WHERE e em cláusulas de junção. O trabalho com muitos dados é delegado (em termos de otimização de banco de dados, empurrado) para vários nós na camada de armazenamento distribuído do Aurora. Sem as consultas paralelas, cada consulta traz todos os dados de varredura para um nó único dentro do cluster do Aurora MySQL (o nó de cabeçalho) e realiza todo o processamento de consultas lá.

dica

O mecanismo de banco de dados PostgreSQL também tem um recurso denominado “consulta paralela”. Esse recurso não está relacionado à consulta paralela do Aurora.

Quando o recurso de consulta paralela está habilitado, o mecanismo do Aurora MySQL determina automaticamente quando as consultas podem se beneficiar, sem exigir alterações de SQL como avisos ou atributos de tabela. Nas seções a seguir, você encontrará uma explicação sobre quando uma consulta paralela é aplicada a uma consulta. Você também descobrirá como garantir que a consulta paralela seja aplicada onde ela pode oferecer o maior benefício.

nota

A otimização de consultas paralelas oferece o maior benefício para consultas de longa duração que levam minutos ou horas para serem concluídas. Geralmente, o Aurora MySQL não executa a otimização de consulta paralela para consultas pouco dispendiosas. Normalmente, ele também não executa otimização de consultas paralelas se outra técnica de otimização faz mais sentido, como o armazenamento em cache de consultas, armazenamento em cache de grupos de buffer ou pesquisas de índice. Se o recurso de consulta paralela não estiver sendo usado quando você espera, consulte Verificar quais declarações usam consulta paralela para Aurora MySQL.

Benefícios

Com a consulta paralela, você pode executar consultas analíticas com uso intensivo de dados em tabelas do Aurora MySQL. Em muitos casos, você pode obter uma melhoria de performance de ordem de grandeza em relação à divisão tradicional de trabalho para processamento de consultas.

Os benefícios da consulta paralela incluem o seguinte:

  • Melhor performance de E/S devido ao paralelismo de solicitações de leitura físicas entre vários nós de armazenamento.

  • Menor tráfego de rede. O Aurora não transmite páginas inteiras de dados dos nós de armazenamento até o nó de cabeçalho para depois filtrar as linhas e colunas desnecessárias. Em vez disso, o Aurora transmite tuplas compactas que contêm somente os valores das colunas necessários para o conjunto de resultados.

  • Uso reduzido de CPU no nó de cabeçalho, pois o processamento da função, a filtragem de linhas e a projeção de colunas para a cláusula WHERE são delegadas (ou “empurradas”).

  • Pressão reduzida da memória no grupo de buffers. As páginas processadas pela consulta paralela não são adicionadas ao grupo de buffer. Essa abordagem reduz a chance de uma verificação intensiva de dados despejar dados usados com frequência do grupo de buffer.

  • Possível redução da duplicação de dados em seu pipeline de extração, transformação e carga (ETL), ao tornar mais prática a realização de consultas analíticas de longa execução em dados existentes.

Arquitetura

O recurso de consulta paralela usa os princípios de arquitetura mais importantes do Aurora MySQL: desacoplamento do mecanismo de banco de dados do subsistema de armazenamento e redução do tráfego de rede com a simplificação dos protocolos de comunicação. O Aurora MySQL usa essas técnicas para acelerar operações de gravação intensiva, como processamento de log de refazimento. A consulta paralela aplica os mesmos princípios nas operações de leitura.

nota

A arquitetura da consulta paralela do Aurora MySQL é diferente da arquitetura de outros recursos semelhantes em outros sistemas de banco de dados. A consulta paralela do Aurora MySQL não envolve o multiprocessamento simétrico (SMP) e, portanto, não depende da capacidade da CPU do servidor de banco de dados. O processamento paralelo ocorre na camada de armazenamento, de forma independente do servidor do Aurora MySQL que funciona como o coordenador de consultas.

Por padrão, sem a consulta paralela, o processamento de uma consulta do Aurora envolve a transmissão de dados brutos para um nó único dentro do cluster do Aurora (o nó do cabeçalho). Depois, o Aurora executa todo o processamento adicional para essa consulta em um único thread desse nó único. Com a consulta paralela, a maior parte do trabalho intensivo de E/S e da CPU é delegado aos nós na camada de armazenamento. Somente as linhas compactas do conjunto de resultados são transmitidas de volta ao nó de cabeçalho, com as linhas já filtradas e os valores das colunas já extraídos e transformados. O benefício com relação à performance vem com a redução no tráfego da rede, a redução do uso de CPU no nó de cabeçalho e o paralelismo da E/S entre os nós de armazenamento. A quantidade de E/S, filtragem e projeção que são paralelizados independe do número de instâncias de banco de dados no cluster do Aurora que executa a consulta.

Pré-requisitos

O uso de todos os recursos da consulta paralela exige um cluster de bancos de dados do Aurora MySQL que esteja executando a versão 2.09 ou posterior. Se você já tiver um cluster que deseja utilizar com consultas paralelas, será possível atualizá-lo para uma versão compatível e habilitar consultas paralelas posteriormente. Nesse caso, siga o procedimento de atualização em Considerações sobre atualização para consultas paralelas porque os nomes de definição da configuração e os valores padrão são diferentes nessas versões mais recentes.

As instâncias de banco de dados no cluster devem usar as classes de instância db.r*.

A otimização da junção de hash deve estar ativada para o cluster. Para saber como, consulte Habilitar a junção de hash para clusters de consulta paralela.

Para personalizar parâmetros como aurora_parallel_query e aurora_disable_hash_join, é necessário ter um grupo de parâmetros personalizado usado com o cluster. É possível especificar esses parâmetros individualmente para cada instância de banco de dados usando um grupo de parâmetros de banco de dados. No entanto, recomendamos que você os especifique em um grupo de parâmetros do cluster de banco de dados. Dessa forma, todas as instâncias de banco de dados no cluster herdam as mesmas configurações para esses parâmetros.

Limitações

Os seguintes limitações se aplicam ao recurso de consulta paralela:

  • A consulta paralela não é compatível com a configuração de armazenamento do cluster de banco de dados do Aurora I/O-Optimized.

  • Não é possível usar a consulta paralela com as classes de instância db.t2 ou db.t3. Essa limitação se aplica mesmo se você solicitar a consulta paralela usando a variável de sessão aurora_pq_force.

  • A consulta paralela não se aplica a tabelas que usam os formatos de linha COMPRESSED ou REDUNDANT. Use os formatos de linha COMPACT ou DYNAMIC para tabelas que você planeja usar com a consulta paralela.

  • O Aurora usa um algoritmo baseado em custo para determinar se deve usar o mecanismo de consulta paralela para cada instrução SQL. Usar certas construções de SQL em uma instrução pode impedir a consulta paralela ou torná-la improvável para essa instrução. Para obter informações sobre a compatibilidade de construções de SQL com a consulta paralela, consulte Constructos do SQL para consulta paralela no Aurora MySQL.

  • Cada instância de bancos de dados Aurora só pode executar um determinado número de sessões de consultas paralelas de cada vez. Se uma consulta tiver várias partes que usam a consulta paralela, como subconsultas, junções ou operadores UNION, essas fases serão executadas em sequência. A instrução só conta com uma sessão de consulta paralela única de cada vez. Você pode monitorar o número de sessões ativas usando as variáveis de status de consulta paralela. Você pode verificar o limite de sessões simultâneas para uma determinada instância de banco de dados consultando a variável de status Aurora_pq_max_concurrent_requests.

  • A consulta paralela está disponível em todas as regiões da AWS que oferecem suporte ao Aurora. Para a maioria das regiões da AWS, a versão mínima necessária do Aurora MySQL para usar a consulta paralela é a 2.09.

  • A consulta paralela foi projetada para melhorar a performance de consultas com uso intenso de dados. Ela não foi projetada para consultas leves.

  • Recomendamos que você use nós de leitor para instruções SELECT, especialmente para as que fazem uso intenso de dados.

Os custos de E/S com a consulta paralela

Se seu cluster do Aurora MySQL usar consulta paralela, você poderá ver um aumento nos valores de VolumeReadIOPS. As consultas paralelas não usam o grupo de buffers. Assim, embora as consultas sejam rápidas, esse processamento otimizado pode resultar em aumento nas operações de leitura e nas cobranças associadas.

Os custos de E/S de consulta paralela para uma consulta são medidos na camada de armazenamento e serão iguais ou maiores com a consulta paralela ativada. Seu benefício é a melhoria na performance da consulta. Os custos de E/S de consultas paralelas podem aumentar por dois motivos:

  • Mesmo que alguns dos dados em uma tabela estejam no grupo de buffers, a consulta paralela exige que todos os dados sejam escaneados na camada de armazenamento, gerando custos de E/S.

  • A execução de uma consulta paralela não aquece o grupo de buffers. Por isso, execuções consecutivas da mesma consulta paralela contribuem para o custo total de E/S.