O Amazon Aurora é, atualmente, o serviço AWS que cresce mais rápido!

Como um banco de dados relacional projetado para a nuvem (leia Amazon Aurora – New Cost-Effective MySQL-Compatible Database Engine for Amazon RDS para saber mais), o Aurora oferece um excelente desempenho, dimensionamento fácil do armazenamento até 64 TB, durabilidade e alta disponibilidade. Uma vez que o Aurora foi projetado para ser compatível com o MySQL, os nossos clientes têm sido capazes de mover suas aplicações existentes e construir novas com facilidade.

Com a compatibilidade do MySQL “em cima” e a arquitetura voltada para nuvem do Aurora “embaixo”, temos um monte de espaço para inovar. Podemos tornar o Aurora ainda mais eficiente e ainda mantê-lo compatível com todas as aplicações.

Hoje estamos fazendo três melhorias de desempenho no Aurora; cada uma delas para tornar o o seu desempenho maior em uma ampla gama de cargas de trabalho comumente executados pelos clientes da AWS. Aqui está um resumo:

• Leitura paralela adiantada – Seleção de intervalo, varreduras completas de tabelas, alterações de tabela e geração de índices são agora até 5x mais rápidas;
• Construção de Indexação rápida – A geração de índices é agora cerca de 75% mais rápida;
• Agendamento consciente-NUMA – Quando executado em instâncias com mais de um chip de CPU, leituras a partir do cache de consultas e o cache de buffer são mais rápidos, melhorando o rendimento geral em até 10%.

Agora, vamos mergulhar de cabeça…

Leitura paralela adiantada

O mecanismo de armazenamento InnoDB, usado pelo MySQL, organiza as linhas da tabela e o armazenamento subjacente (páginas de disco) utilizando as chaves de índice. Isso torna as varreduras sequenciais sobre as tabelas completas rápidas e eficientes para as tabelas recém-criadas.

No entanto, como as linhas são atualizadas, inseridas e excluídas ao longo do tempo, o armazenamento se torna fragmentado, as páginas não são mais fisicamente sequenciais e as varreduras podem ser dramaticamente retardadas. O recurso linear de leitura paralela adiantada do InnoDB busca lidar com esta fragmentação, trazendo até 64 páginas para a memória antes que elas sejam realmente necessárias. Embora bem-intencionado, esse recurso não fornece uma melhoria de desempenho significativo em cargas de trabalho em escala empresarial.

Com a atualização de hoje, o Aurora agora lida bem melhor com esta situação muito comum. Quando o Aurora verifica uma tabela, ele identifica logicamente (em oposição a fisicamente) e, em seguida, efetua uma pré-busca paralela das páginas adicionais. A pré-busca paralela tira proveito da arquitetura de armazenamento replicado do Aurora (duas cópias em cada uma das três zonas de disponibilidade) e ajuda a assegurar que as páginas no cache do banco de dados são relevantes para a operação de varredura.

Como resultado dessa mudança, a seleção de intervalos, a varredura completa de tabelas, a operação ALTER TABLE e a geração de índices são até 5 vezes mais rápidas do que antes.

Você verá que o desempenho melhorou assim que você atualizar para o Aurora 1.7 (veja abaixo para mais informações).

Construção de indexação rápida

Quando você cria um índice primário ou secundário em uma tabela, o mecanismo de armazenamento cria uma estrutura de árvore que contém as novas chaves. Este processo implica em uma série de buscas top-down nas árvores e uma abundância de páginas de divisão a medida que a árvore é reestruturada para acomodar mais e mais chaves.

Aurora agora constrói as árvores de uma forma de baixo para cima, construindo as folhas em primeiro lugar e, em seguida, adicionando páginas pai, conforme necessário. Isto reduz a quantidade de vai-e-vem ao armazenamento e também previne a necessidade de dividir as páginas, já que cada página é preenchida por vez.

Com esta mudança, a adição de índices e a reconstrução das tabelas é agora até 4 vezes mais rápida do que antes, dependendo do esquema da tabela. Por exemplo, a equipe do Aurora criou uma tabela com o seguinte esquema e acrescentou 100 milhões de linhas, resultando em uma tabela de 5 GB:

create table test01 (id int not null auto_increment primary key, i int, j int, k int);

Em seguida, eles acrescentaram quatro índices adicionais:

alter table test01 add index (i), add index (j), add index (k), add index comp_idx(i, j, k);

Em uma instância db.r3.large, o tempo para executar esta consulta caiu de 67 para 25 minutos. Em uma instância db.r3.8xlarge, o tempo caiu de 29 para 11,5 minutos.

Este é um recurso novo e nós gostaríamos que você experimentasse em suas cargas de trabalho de não-produção. Você precisará atualizar para o Aurora 1,7 e, em seguida, definir o aurora_lab_mode como 1 no grupo DB Instance Parameter (veja  DB Cluster and DB Instance Parameters para saber mais):

A equipe está muito interessada nos seus comentários sobre essa melhoria de desempenho. Por favor, sinta-se à vontade para postar suas observações na Fórum do Amazon RDS.

Agendamento consciente-NUMA

A maior Instância DB (db.r3.8xlarge) tem dois chips de CPU e uma característica comumente conhecidos como NUMA, abreviação de Non-Uniform Memory Access. Em sistemas deste tipo, cada fração igual de memória principal é diretamente acessível e eficiente para cada CPU. A memória restante é acessível através de um caminho de acesso cross-CPU um pouco menos eficiente.

O Aurora agora faz um trabalho melhor de agendamento de tópicos através das CPUs, a fim de aproveitar essa disparidade de tempos de acesso. Os tópicos não precisam mais lutar uns contra os outros para o acesso à memória menos eficiente, associadas a outros processadores. Como resultado, as operações vinculadas à CPU que fazem uso pesado do cache de consultas e o cache de buffer agora executam até 10% mais rápido.

A melhoria de desempenho será mais aparente quando você estiver fazendo centenas ou milhares de ligações para a mesma instância de banco de dados. Como exemplo, o desempenho no benchmark oltp.lua da Sysbench cresceu de 570.000 leituras/segundo para 625.000 leituras/segundo.  O teste foi executado em uma Instância DB db.r3.8xlarge com os seguintes parâmetros:

• oltp_table_count=25
• oltp_table_size=10000
• num-threads=1500

Você verá uma melhora no desempenho assim que você atualizar para o Aurora 1.7.

Atualizando para o Aurora 1,7

Instâncias de banco de dados recém-criadas serão automaticamente executadas no Aurora 1.7. Para instâncias de banco de dados existentes, você pode optar por instalar a atualização imediatamente ou durante a sua janela de manutenção seguinte.

Você pode confirmar se você está executando Aurora 1.7 executando a seguinte consulta:

mysql> show global variables like "aurora_version";
+----------------+-------+
| Variable_name  | Value |
+----------------+-------+
| aurora_version | 1.7   |
+----------------+-------+