# 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 do banco de dados Aurora PostgreSQL que utiliza Leituras Otimizadas do Aurora proporciona até 8 vezes menos latência nas consultas e até 30% de economia para aplicações com grandes volumes de dados que excedem a capacidade de memória da instância do banco de dados.
**Topics**
+ [Visão geral do Aurora Optimized Reads no PostgreSQL](#AuroraPostgreSQL.optimized.reads.overview)
+ [Utilizar o Aurora Optimized Reads](#AuroraPostgreSQL.optimized.reads.using)
+ [Casos de uso do Aurora Optimized Reads](#AuroraPostgreSQL.optimized.reads.usecases)
+ [Monitorar instâncias de banco de dados que utilizam o Aurora Optimized Reads](#AuroraPostgreSQL.optimized.reads.monitoring)
+ [Práticas recomendadas para o Aurora Optimized Reads](#AuroraPostgreSQL.optimized.reads.bestpractices)
## 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 use instâncias R6gd e R8gd 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:
+ 14.12 e versões posteriores, 15.7 e versões posteriores, 16.3 e versões posteriores, 17.4 e versões posteriores das instâncias R8gd.
+ 14.9 e versões posteriores, 15.4 e versões posteriores, 16.1 e todas as versões posteriores das instâncias R6gd e R6id.
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 r8gd, 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.
Os clusters do Aurora otimizados para E/S permitem redimensionar o espaço alocado a objetos temporários habilitados para leituras otimizadas usando o parâmetro dinâmico `aurora_temp_space_size` no nível da instância. O recurso de redimensionamento está disponível nas seguintes versões do PostgreSQL:
+ 16.8 e todas as versões posteriores
+ 15.12 e versões 15 posteriores
+ 14.17 e versões 14 posteriores
Com esse parâmetro, você pode redimensionar a capacidade de memória da instância de duas até seis vezes sem precisar reinicializar o mecanismo de banco de dados. Ao expandir o espaço de objetos temporários, a alteração entra em vigor de imediato, independentemente das workloads simultâneas. Entretanto, ao reduzir o espaço, o ajuste é concluído somente depois que há espaço não utilizado suficiente em objetos temporários para atender à nova solicitação de tamanho. Depois de redimensionar objetos temporários habilitados para leituras otimizadas, o cache em camadas se ajusta automaticamente para usar qualquer espaço disponível.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.optimized.reads.html)
**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:
+ Crie um cluster de banco de dados do Aurora PostgreSQL utilizando uma das classes de instância de banco de dados NVMe. Para obter mais informações, consulte [Criar um cluster de bancos de dados do Amazon Aurora](Aurora.CreateInstance.md).
+ Modifique um cluster de banco de dados do Aurora PostgreSQL para utilizar uma das classes de instância de banco de dados baseada em NVMe. Para obter mais informações, consulte [Modificar um cluster de bancos de dados Amazon Aurora](Aurora.Modifying.md).
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 obter mais informações, consulte [Classes de instâncias de banco de dados do Amazon Aurora](Concepts.DBInstanceClass.md).
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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html).
## 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](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances).
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](AuroraPostgreSQL.cluster-cache-mgmt.md).