Melhorar a performance das consultas do Aurora PostgreSQL com o Aurora Optimized Reads - Amazon Aurora

Melhorar a performance das consultas do Aurora PostgreSQL com o Aurora Optimized Reads

É possível acelerar o processamento de consultas do Aurora PostgreSQL com o Aurora Optimized Reads. Uma instância de banco de dados Aurora PostgreSQL que usa o Aurora Optimized Reads oferece até 8 vezes mais latência de consulta e até 30% de economia de custos para aplicações com grandes conjuntos de dados, que excedem a capacidade de memória de uma instância de banco de dados.

Visão geral do Aurora Optimized Reads no PostgreSQL

O Aurora Optimized Reads está disponível por padrão quando você cria um cluster de banco de dados que usa instâncias R6gd baseadas em Graviton e R6id baseadas em Intel com armazenamento de memória expressa não volátil (NVMe). Ele está disponível nas seguintes versões do PostgreSQL:

  • 16.1 e todas as versões posteriores

  • 15.4 e versões posteriores

  • 14.9 e versões posteriores

O Aurora Optimized Reads oferece suporte a dois recursos: cache em camadas e objetos temporários.

Cache em camadas habilitado para o Aurora Optimized Reads: usando o cache em camadas, você pode estender a capacidade de cache da instância de banco de dados em até cinco vezes a memória da instância. Isso mantém automaticamente o cache para conter os dados mais recentes e transacionalmente consistentes, liberando as aplicações da sobrecarga de gerenciar a moeda de dados de soluções externas de armazenamento em cache baseadas em conjuntos de resultados. Ele oferece latência até 8 vezes melhor para consultas que anteriormente buscavam dados do armazenamento Aurora.

No Aurora, o valor para shared_buffers no grupo de parâmetros padrão geralmente é definido como cerca de 75% da memória disponível. No entanto, para os tipos de instância r6gd e r6id, o Aurora reduzirá o espaço de shared_buffers em 4,5% para hospedar os metadados do cache do Optimized Reads.

Objetos temporários habilitados para o Optimized Reads: usando objetos temporários, você pode acelerar o processamento de consultas colocando os arquivos temporários gerados pelo PostgreSQL no armazenamento NVMe local. Isso reduz o tráfego para o Elastic Block Storage (EBS) pela rede. Ele oferece latência e taxa de throughput até duas vezes melhores para consultas avançadas que classificam, unem ou mesclam grandes volumes de dados que não se ajustam à capacidade de memória disponível em uma instância de banco de dados.

Em um cluster otimizado para E/S do Aurora, o Optimized Reads usa tanto o cache em camadas quanto os objetos temporários no armazenamento NVMe. Com o recurso de cache hierárquico habilitado para o Optimized Reads, o Aurora aloca o dobro da memória da instância para objetos temporários, aproximadamente 10% do armazenamento para operações internas e o armazenamento restante como cache em camadas. Em um cluster Aurora Standard, o Optimized Reads usa somente objetos temporários.

Mecanismo Configuração de armazenamento do cluster Objetos temporários habilitados para o Optimized Reads Cache em camadas habilitado para o Optimized Reads Versões compatíveis
Aurora Edição Compatível com PostgreSQL Padrão Sim Não Aurora PostgreSQL versão 16.1 e todas as versões posteriores, 15.4 e posterior, versão 14.9 e posterior
Otimizado para E/S Sim Sim
nota

Uma alternância entre clusters otimizados para E/S e Standard em uma classe de instância de banco de dados baseada em NVMe causa uma reinicialização imediata do mecanismo de banco de dados.

No Aurora PostgreSQL, use o parâmetro temp_tablespaces para configurar o espaço da tabela onde os objetos temporários são armazenados.

Para verificar se os objetos temporários estão configurados, use o seguinte comando:

postgres=> show temp_tablespaces; temp_tablespaces --------------------- aurora_temp_tablespace (1 row)

O aurora_temp_tablespace é um espaço de tabela configurado pelo Aurora que aponta para o armazenamento NVMe local. Não é possível modificar esse parâmetro nem voltar para o armazenamento no Amazon EBS.

Para verificar se o cache de leitura otimizado está ativado, use o seguinte comando:

postgres=> show shared_preload_libraries; shared_preload_libraries -------------------------------------------------------- rdsutils,pg_stat_statements,aurora_optimized_reads_cache

Utilizar o Aurora Optimized Reads

Quando você provisiona uma instância de banco de dados do Aurora PostgreSQL com uma instância de banco de dados baseada em NVMe, a instância de banco de dados utiliza automaticamente o Aurora Optimized Reads.

Para ativar o Aurora Optimized Reads, execute um destes procedimentos:

O Aurora Optimized Reads está disponível em todas as Regiões da AWS onde há suporte para uma ou mais dessas classes de instância de banco de dados com SSD NVMe local. Para ter mais informações, consulte Classes de instância de banco de dados Aurora.

Para voltar para uma instância do Aurora de leituras não otimizadas, modifique a classe de instância de banco de dados da instância do Aurora para a classe de instância semelhante sem o armazenamento efêmero do NVMe para as workloads de banco de dados. Por exemplo, se a classe de instância de banco de dados atual for db.r6gd.4xlarge, selecione db.r6g.4xlarge para voltar. Para ter mais informações, consulte Modificar uma instância de banco de dados do Aurora.

Casos de uso do Aurora Optimized Reads

Cache em camadas habilitado para o Optimized Reads

Veja a seguir alguns casos de uso que podem se beneficiar do Optimized Reads com cache em camadas:

  • Aplicações de escala na Internet, como processamento de pagamentos, cobrança e comércio eletrônico com SLAs altamente rigorosos.

  • Painéis de relatórios em tempo real que executam centenas de consultas pontuais para coleta de métricas/dados.

  • Aplicações de IA generativa com a extensão pgvector para pesquisar vizinhos exatos ou mais próximos em milhões de incorporações vetoriais.

Objetos temporários habilitados para o Optimized Reads

Veja a seguir alguns casos de uso que podem se beneficiar do Optimized Reads com objetos temporários:

  • Consultas analíticas que incluem expressões de tabela comuns (CTEs), tabelas derivadas e operações de agrupamento.

  • Réplicas de leitura que lidam com as consultas não otimizadas de uma aplicação.

  • Consultas de relatórios dinâmicos ou sob demanda com operações complexas, como GROUP BY e ORDER BY, que nem sempre podem usar índices apropriados.

  • Operações CREATE INDEX ou REINDEX de classificação.

  • Outras workloads que usam tabelas temporárias internas.

Monitorar instâncias de banco de dados que utilizam o Aurora Optimized Reads

Você pode monitorar as consultas que usam o cache em camadas habilitado para o Optimized Reads com o comando EXPLAIN, conforme mostrado no seguinte exemplo:

Postgres=> EXPLAIN (ANALYZE, BUFFERS) SELECT c FROM sbtest15 WHERE id=100000000 QUERY PLAN -------------------------------------------------------------------------------------- Index Scan using sbtest15_pkey on sbtest15 (cost=0.57..8.59 rows=1 width=121) (actual time=0.287..0.288 rows=1 loops=1) Index Cond: (id = 100000000) Buffers: shared hit=3 read=2 aurora_orcache_hit=2 I/O Timings: shared/local read=0.264 Planning: Buffers: shared hit=33 read=6 aurora_orcache_hit=6 I/O Timings: shared/local read=0.607 Planning Time: 0.929 ms Execution Time: 0.303 ms (9 rows) Time: 2.028 ms
nota

Os campos aurora_orcache_hit e aurora_storage_read na seção Buffers do plano de explicação são mostrados somente quando o Optimized Reads está ativado e seus valores são maiores que zero. O campo de leitura é o total dos campos aurora_orcache_hit e aurora_storage_read.

Você pode monitorar instâncias de banco de dados que usam o Aurora Optimized Reads com as seguintes métricas do CloudWatch:

  • AuroraOptimizedReadsCacheHitRatio

  • FreeEphemeralStorage

  • ReadIOPSEphemeralStorage

  • ReadLatencyEphemeralStorage

  • ReadThroughputEphemeralStorage

  • WriteIOPSEphemeralStorage

  • WriteLatencyEphemeralStorage

  • WriteThroughputEphemeralStorage

Essas métricas fornecem dados sobre armazenamento de instâncias, IOPS e throughput. Para ter mais informações sobre essas métricas, consulte Métricas no nível da instância do Amazon Aurora.

Também é possível usar a extensão pg_proctab para monitorar o armazenamento NVMe.

postgres=>select * from pg_diskusage(); major | minor | devname | reads_completed | reads_merged | sectors_read | readtime | writes_completed | writes_merged | sectors_written | writetime | current_io | iotime | totaliotime ------+-------+---------------------+-----------------+--------------+--------------+----------+------------------+---------------+-----------------+-----------+------------+---------+------------- | | rdstemp | 23264 | 0 | 191450 | 11670 | 1750892 | 0 | 24540576 | 819350 | 0 | 3847580 | 831020 | | rdsephemeralstorage | 23271 | 0 | 193098 | 2620 | 114961 | 0 | 13845120 | 130770 | 0 | 215010 | 133410 (2 rows)

Práticas recomendadas para o Aurora Optimized Reads

Use as práticas recomendadas a seguir para o Aurora Optimized Reads:

  • Monitore o espaço de armazenamento disponível no armazenamento de instâncias com a métrica do CloudWatch FreeEphemeralStorage. Se o armazenamento de instância estiver atingindo seu limite devido à workload na instância de banco de dados, ajuste a simultaneidade e as consultas que fazem uso intenso de objetos temporários ou modifique para usar uma classe de instância de banco de dados maior.

  • Monitore a métrica do CloudWatch para a taxa de acertos de cache do Optimized Reads. Operações como VACUUM modificam um grande número de blocos muito rapidamente. Isso pode causar uma queda temporária na taxa de acerto. A extensão pg_prewarm pode ser usada para carregar dados no cache de buffer, permitindo que o Aurora grave proativamente alguns desses blocos no cache do Optimized Reads.

  • Você pode ativar o gerenciamento de cache de cluster (CCM) para aquecer o cache de buffer e o cache em camadas em um leitor de nível 0, que será usado como destino de failover. Quando o CCM está ativado, o cache do buffer é escaneado periodicamente para gravar páginas elegíveis para remoção em cache em camadas. Para obter mais informações sobre CCM, consulte Recuperação rápida após failover com o gerenciamento de cache do cluster para o Aurora PostgreSQL.