Amélioration des performances des requêtes pour Aurora PostgreSQL avec Aurora Optimized Reads

Vous pouvez accélérer le traitement des requêtes pour Aurora PostgreSQL avec Aurora Optimized Reads. Une instance de base de données Aurora PostgreSQL qui utilise Aurora Optimized Reads permet d'améliorer jusqu'à 8 fois le temps de latence des requêtes et de réaliser des économies pouvant atteindre 30 % pour les applications comportant des jeux de données volumineux, qui dépassent la capacité de mémoire d'une instance de base de données.

Présentation d'Aurora Optimized Reads dans PostgreSQL

Aurora Optimized Reads est disponible par défaut lorsque vous créez un cluster de base de données qui utilise des instances R6gd basées sur Graviton et des instances R6id basées sur Intel avec un stockage NVMe (Non-Volatile Memory Express). Il est disponible à partir des versions PostgreSQL suivantes :

• 16.1 et toutes les versions supérieures

• Version 15.4 et versions ultérieures

• Version 14.9 et versions ultérieures

Aurora Optimized Reads prend en charge deux fonctionnalités : le cache à plusieurs niveaux et les objets temporaires.

Cache à plusieurs niveaux Optimized Reads : grâce au cache à plusieurs niveaux, vous pouvez étendre la capacité de mise en cache de votre instance de base de données jusqu'à 5 fois la mémoire de l'instance. Cela permet de maintenir le cache à jour automatiquement de manière à ce qu'il contienne les données les plus récentes et les plus homogènes sur le plan transactionnel, et de libérer ainsi les applications de la charge de gestion de la mise à jour des données des solutions de mise en cache externes basées sur des ensembles de résultats. Il réduit jusqu'à 8 fois le temps de latence des requêtes qui récupéraient auparavant des données du stockage Aurora.

Dans Aurora, la valeur du groupe de shared_buffers paramètres par défaut est généralement définie sur environ 75 % de la mémoire disponible. Toutefois, pour les types d'instances r6gd et r6id, Aurora réduira l'shared_buffersespace de 4,5 % pour héberger les métadonnées du cache de lectures optimisées.

Objets temporaires Optimized Reads : grâce aux objets temporaires, vous pouvez accélérer le traitement des requêtes en plaçant les fichiers temporaires générés par PostgreSQL sur le stockage NVMe local. Cela réduit le trafic à destination d'Elastic Block Storage (EBS) sur le réseau. Il offre une latence et un débit jusqu'à deux fois supérieurs pour les requêtes avancées qui trient, joignent ou fusionnent de gros volumes de données qui ne correspondent pas à la capacité de mémoire disponible sur une instance de base de données.

Sur un cluster optimisé E/S Aurora, Optimized Reads utilise à la fois un cache à plusieurs niveaux et des objets temporaires sur le stockage NVMe. Grâce au cache à plusieurs niveaux Optimized Reads, Aurora alloue deux fois la mémoire de l'instance aux objets temporaires, environ 10 % de l'espace de stockage aux opérations internes et le reste du stockage sous forme de cache à plusieurs niveaux. Sur un cluster Aurora standard, Optimized Reads utilise uniquement des objets temporaires.

Engine	Configuration du stockage en cluster	Objets temporaires Optimized Reads	Cache à plusieurs niveaux Optimized Reads	Versions prises en charge
Aurora PostgreSQL-Compatible Edition	Standard	Oui	Non	Aurora PostgreSQL version 16.1 et toutes les versions supérieures, 15.4 et supérieures, versions 14.9 et supérieures
	Optimisé pour les E/S	Oui	Oui

Note

Un basculement entre des clusters optimisés E/S et des clusters standard sur une classe d'instance de base de données basée sur NVMe entraîne le redémarrage immédiat du moteur de la base de données.

Dans Aurora PostgreSQL, utilisez temp_tablespaces le paramètre pour configurer l'espace de table dans lequel les objets temporaires sont stockés.

Pour vérifier si les objets temporaires sont configurés, utilisez la commande suivante :

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

aurora_temp_tablespace est un espace de table configuré par Aurora qui pointe vers le stockage local NVMe. Vous ne pouvez pas modifier ce paramètre ou revenir au stockage Amazon EBS.

Pour vérifier si le cache Optimized Reads est activé, utilisez la commande suivante :

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

Utilisation d'Aurora Optimized Reads

Lorsque vous provisionnez une instance de base de données Aurora PostgreSQL avec l'une des instances de base de données basées sur NVMe, l'instance de base de données utilise automatiquement les lectures optimisées Aurora.

Pour activer Aurora Optimized Reads, effectuez l'une des actions suivantes :

• Créez un cluster de base de données Aurora PostgreSQL en utilisant l'une des classes d'instance de base de données basées sur NVMe. Pour plus d’informations, consultez Création d'un cluster de base de données Amazon Aurora.

• Modifiez un cluster de base de données Aurora PostgreSQL existant pour utiliser l'une des classes d'instance de base de données basées sur NVMe. Pour plus d’informations, consultez Modification d'un cluster de bases de données Amazon Aurora.

Aurora Optimized Reads est disponible partout Régions AWS où une ou plusieurs classes d'instances de base de données avec stockage SSD NVMe local sont prises en charge. Pour plus d’informations, consultez Classes d'instances de base de données Aurora.

Pour revenir à une instance Aurora en lecture non optimisée, modifiez la classe d'instance de base de données de votre instance Aurora en une classe d'instance similaire sans stockage éphémère NVMe pour les charges de travail de votre base de données. Par exemple, si la classe d'instance de base de données actuelle est db.r6gd.4xlarge, choisissez db.r6g.4xlarge pour revenir en arrière. Pour plus d'informations, consultez Modification d'une instance de base de données Amazon RDS.

Cas d'utilisation d'Aurora Optimized Reads

Cache à plusieurs niveaux Optimized Reads

Voici quelques cas d'utilisation du cache à plusieurs niveaux Optimized Reads :

• Applications Internet (traitement des paiements, facturation, commerce électronique, etc.) avec des SLA de performance stricts.

• Tableaux de bord de reporting en temps réel qui exécutent des centaines de requêtes ponctuelles pour la collecte de métriques/données.

• Applications d'IA générative avec l'extension pgvector pour rechercher des voisins exacts ou les voisins les plus proches parmi des millions de vecteurs intégrés.

Objets temporaires Optimized Reads

Voici quelques cas d'utilisation des objets temporaires Optimized Reads :

• Requêtes d'application avec des expressions de table communes (CTE), des tables dérivées et des opérations de regroupement complexes.

• Réplicas en lecture qui gèrent les requêtes non optimisées pour une application.

• Requêtes de création de rapports dynamiques ou à la demande avec des opérations complexes telles que GROUP BY et ORDER BY qui ne peuvent pas toujours utiliser les index appropriés.

• CREATE INDEXou REINDEX des opérations de tri.

• Autres charges de travail utilisant des tables temporaires internes.

Surveillance des instances de base de données qui utilisent Aurora Optimized Reads

Vous pouvez surveiller vos requêtes qui utilisent le cache à plusieurs niveaux Optimized Reads à l'aide de la commande EXPLAIN comme illustré dans l'exemple suivant :

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
            
        

Note

aurora_orcache_hitet aurora_storage_read les champs de la Buffers section du plan d'explication ne sont affichés que lorsque les lectures optimisées sont activées et que leurs valeurs sont supérieures à zéro. Le champ de lecture est le total des aurora_storage_read champs aurora_orcache_hit et.

Vous pouvez surveiller les instances de base de données qui utilisent les lectures optimisées Aurora à l'aide CloudWatch des métriques suivantes :

• AuroraOptimizedReadsCacheHitRatio

• FreeEphemeralStorage

• ReadIOPSEphemeralStorage

• ReadLatencyEphemeralStorage

• ReadThroughputEphemeralStorage

• WriteIOPSEphemeralStorage

• WriteLatencyEphemeralStorage

• WriteThroughputEphemeralStorage

Ces métriques fournissent des données sur le stockage disponible dans le stockage d'instances, les IOPS et le débit. Pour plus d'informations sur ces métriques, consultez Métriques de niveau instance pour Amazon Aurora.

Vous pouvez utiliser l'extension pg_proctab pour surveiller le stockage 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)    

Bonnes pratiques pour Aurora Optimized Reads

Utilisez les bonnes pratiques suivantes pour Aurora Optimized Reads :

• Surveillez l'espace de stockage disponible sur le magasin d'instances à l'aide de la CloudWatch métriqueFreeEphemeralStorage. Si le magasin d'instance atteint sa limite en raison de la charge de travail de l'instance de base de données, ajustez la simultanéité et les requêtes qui utilisent beaucoup d'objets temporaires ou modifiez-le pour utiliser une classe d'instance de base de données plus importante.

• Surveillez la CloudWatch métrique du taux de réussite du cache Optimized Reads. Des opérations telles que VACUUM modifient très rapidement un grand nombre de blocs. Cela peut entraîner une baisse temporaire du taux d'accès. L'extension pg_prewarm peut être utilisée pour charger des données dans le cache de tampon, ce qui permet à Aurora d'écrire de manière proactive certains de ces blocs dans le cache Optimized Reads.

• Vous pouvez activer la gestion du cache de cluster pour réchauffer le cache d tampon et le cache à plusieurs niveaux sur un lecteur de niveau 0, qui sera utilisé comme cible de basculement. Lorsque la gestion du cache de cluster est activée, le cache de tampon est scanné périodiquement pour écrire les pages susceptibles d'être expulsées dans le cache à plusieurs niveaux. Pour plus d'informations sur la gestion du cache de cluster, consultez Récupération rapide après basculement avec la gestion des caches de clusters pour Aurora PostgreSQL.