Relations Tables temporaires Tables non enregistrées Partitions Fichiers temporaires Séquences Objets volumineux Seuils approximatifs

Gestion d'un nombre élevé d'objets dans Amazon RDS pour PostgreSQL Amazon Aurora

Bien que les limites de PostgreSQL soient théoriques, le nombre d'objets extrêmement élevé dans une base de données peut avoir un impact notable sur les performances de diverses opérations. Cette documentation couvre plusieurs types d'objets courants qui, lorsqu'ils ont un nombre total élevé, peuvent avoir plusieurs impacts possibles.

Le tableau suivant fournit un résumé des types d'objets et de leurs impacts potentiels :

Types d'objets et impacts potentiels
Type d'objet	Aspirateur automatique	Réplication logique	Mise à niveau de la version majeure	pg_dumpg/pg_restore	Performance générale	Redémarrage de l'instance
Relations	x		h/24, j/7	h/24, j/7	x
Tables temporaires	x				x
Tables non enregistrées		x				x
Partitions					x
Fichiers temporaires					x
Séquences		x
Objets de grande taille		x	x

Relations

Il n'existe pas de limite stricte spécifique concernant le nombre de tables dans une base de données PostgreSQL. La limite théorique est extrêmement élevée, mais d'autres limites pratiques doivent être prises en compte lors de la conception de la base de données.

Conséquence : Autovacuum prend du retard

Autovacuum peut avoir du mal à faire face à la croissance des numéros de transaction ou à la surcharge de travail en raison du manque de personnel par rapport à la quantité de travail.

Action recommandée : Plusieurs facteurs permettent de régler l'autovacuum afin de s'adapter correctement à un nombre donné de tables et à une charge de travail donnée. Consultez Meilleures pratiques d'utilisation de l'aspirateur automatique PostgreSQL Meilleures pratiques d'utilisation de l'aspirateur automatique PostgreSQL d'aspirateur automatique appropriés. Utilisez l'utilitaire pour surveiller les problèmes liés à la croissance des identifiants de transaction.

Conséquence : mise à niveau de la version majeure /pg_dump et restauration

Amazon RDS utilise l'option « --link » lors de l'exécution de pg_upgrade pour éviter d'avoir à faire des copies des fichiers de données. Les métadonnées du schéma doivent toujours être restaurées dans la nouvelle version de la base de données. Même avec parallel pg_restore, s'il existe un nombre important de relations, cela augmentera le temps d'arrêt.

Conséquence : dégradation générale des performances

Dégradation générale des performances due à la taille du catalogue. Chaque table et ses colonnes associées s'ajouteront pg_class aux pg_attribute pg_depend tables fréquemment utilisées dans les opérations de base de données normales. Aucun événement d'attente spécifique ne sera visible, mais l'efficacité de la mémoire tampon partagée sera affectée.

Action recommandée : Vérifiez régulièrement la saturation des tables pour ces tables spécifiques et effectuez occasionnellement une opération VACUUM FULL sur ces tables spécifiques. Sachez que les tables VACUUM FULL du catalogue nécessitent un ACCESS EXCLUSIVE verrou, ce qui signifie qu'aucune autre requête ne pourra y accéder tant que l'opération ne sera pas terminée.

Conséquence : épuisement du descripteur de fichier

Erreur : « Descripteurs de fichiers insuffisants : trop de fichiers ouverts dans le système ; relâchez-les et réessayez ». Le max_files_per_process paramètre PostgreSQL détermine le nombre de fichiers que chaque processus peut ouvrir. Si un grand nombre de connexions rejoignent un grand nombre de tables, il est possible d'atteindre cette limite.

Action recommandée :

La réduction de la valeur du paramètre max_files_per_process peut contribuer à atténuer cette erreur. Chaque processus et sous-processus (par exemple, une requête parallèle) peut ouvrir ce nombre de fichiers, et si les requêtes joignent plusieurs tables, cette limite peut être dépassée.
Réduisez le nombre total de connexions et utilisez un pool de connexions tel qu'Amazon RDS Proxy, Amazon RDS ou d'autres solutions telles que. PgBouncer Pour en savoir plus, consultez le PgBouncer site Web.

Impact : épuisement des inodes

Erreur : « Il ne reste plus d'espace sur l'appareil ». Si cela se produit alors qu'il y a suffisamment d'espace libre de stockage, cela est dû au manque d'inodes. Amazon RDS Enhanced Monitoring fournit une visibilité sur les inodes utilisés et sur le nombre maximum d'inodes disponibles pour votre hôte.

Seuil approximatif : millions

Tables temporaires

L'utilisation de tables temporaires est utile pour les données de test ou les résultats intermédiaires et constitue un modèle courant observé dans de nombreux moteurs de base de données. Les implications d'une utilisation intensive dans PostgreSQL doivent être comprises pour éviter certains écueils. Chaque table temporaire créée et supprimée ajoute des lignes aux tables du catalogue du système, ce qui, lorsqu'elles deviennent trop volumineuses, entraîne des problèmes de performances généraux.

Conséquence : Autovacuum prend du retard

Les tables temporaires ne sont pas aspirées par autovacuum, mais elles conserveront les transactions IDs pendant leur existence et peuvent être enveloppées si elles ne sont pas retirées.

Action recommandée : Les tables temporaires seront conservées pendant toute la durée de la session qui les a créées ou peuvent être supprimées manuellement. Une bonne pratique consistant à éviter les transactions de longue durée avec des tables temporaires empêchera ces tables de contribuer à la croissance maximale des identifiants de transaction utilisés.

Conséquence : dégradation générale des performances

Dégradation générale des performances due à la taille du catalogue. Lorsque les sessions créent et suppriment continuellement des tables temporaires, elles s'ajoutent à celles pg_attribute qui sont fréquemment utilisées dans le cadre des opérations normales de base de données. pg_class pg_depend Aucun événement d'attente spécifique ne sera visible, mais l'efficacité de la mémoire tampon partagée sera affectée.

Action recommandée :

Vérifiez régulièrement l'excès de volume des tables pour ces tables spécifiques et effectuez de temps en temps une VACUUM FULL sur ces tables spécifiques. Sachez que les tables VACUUM FULL du catalogue nécessitent un ACCESS EXCLUSIVE verrou, ce qui signifie qu'aucune autre requête ne pourra y accéder tant que l'opération ne sera pas terminée.
Si les tables temporaires sont très utilisées, il est vivement recommandé d'utiliser l'une VACUUM FULL de ces tables de catalogue spécifiques avant une mise à niveau majeure de version afin de réduire les temps d'arrêt.

Bonnes pratiques générales :

Réduisez l'utilisation de tables temporaires en utilisant des expressions de table communes pour produire des résultats intermédiaires. Cela peut parfois compliquer les requêtes nécessaires, mais éliminera les impacts énumérés ci-dessus.
Réutilisez les tables temporaires en utilisant la TRUNCATE commande pour effacer le contenu au lieu de suivre des drop/create étapes. Cela éliminera également le problème de croissance des identifiants de transaction causé par les tables temporaires.

Seuil approximatif : dizaines de milliers

Tables non enregistrées

Les tables non enregistrées peuvent offrir des gains de performance car elles ne génèrent aucune information WAL. Ils doivent être utilisés avec précaution car ils n'offrent aucune durabilité lors de la restauration d'une base de données suite à un crash, car ils seront tronqués. Il s'agit d'une opération coûteuse dans PostgreSQL car chaque table délogée est tronquée en série. Bien que cette opération soit rapide pour un petit nombre de tables non enregistrées, lorsqu'elles se comptent par milliers, elle peut commencer à retarder considérablement le démarrage.

Conséquence : réplication logique: Les tables non enregistrées ne sont généralement pas incluses dans la réplication logique, y compris les déploiements bleu/vert Les déploiements .

Conséquence : temps d'arrêt prolongé pendant la restauration

Quel que soit l'état d'une base de données impliquant une restauration après incident, tel que le redémarrage multi-AZ avec basculement, la point-in-time restauration Amazon RDS et la mise à niveau de la version majeure d'Amazon RDS, l'opération sérialisée de troncation des tables non enregistrées se produit. Cela peut entraîner des temps d'arrêt bien plus élevés que prévu.

Action recommandée :

Limitez l'utilisation de tables non enregistrées uniquement aux données susceptibles d'être perdues lors des opérations de restauration après incident de base de données.
Réduisez l'utilisation de tables non enregistrées, car le comportement actuel de troncature en série peut entraîner un temps considérable de démarrage d'une base de données.

Bonnes pratiques générales :

Les tables non enregistrées ne sont pas protégées contre les pannes. Le lancement d'une point-in-time restauration, qui implique une restauration après incident, prend beaucoup de temps dans PostgreSQL car il s'agit d'un processus en série qui tronque chaque table.

Seuil approximatif : en milliers

Partitions

Le partitionnement peut améliorer les performances des requêtes et fournir une organisation logique des données. Dans les scénarios idéaux, le partitionnement est organisé de telle sorte que l'élagage des partitions puisse être utilisé lors de la planification et de l'exécution des requêtes. L'utilisation d'un trop grand nombre de partitions peut avoir un impact négatif sur les performances des requêtes et la maintenance de la base de données. Le choix du mode de partitionnement d'une table doit être fait avec soin, car les performances de planification et d'exécution des requêtes peuvent être affectées négativement par une mauvaise conception. Consultez la documentation de PostgreSQL pour plus de détails sur le partitionnement.

Conséquence : dégradation générale des performances

Parfois, le temps de planification augmente et il devient plus difficile d'expliquer les plans pour vos requêtes, ce qui rend difficile l'identification des opportunités de réglage. Pour les versions de PostgreSQL antérieures à 18, de nombreuses partitions présentant une charge de travail élevée peuvent entraîner des temps d'attente. LWLock:LockManager

Action recommandée : déterminez un nombre minimum de partitions qui vous permettront d'organiser vos données tout en garantissant une exécution performante des requêtes.

Impact : complexité de la maintenance

Un nombre très élevé de partitions entraînera des difficultés de maintenance, telles que la pré-création et la suppression. Autovacuum traitera les cloisons comme des relations normales et devra effectuer un nettoyage régulier, ce qui nécessitera un nombre suffisant de travailleurs pour effectuer la tâche.

Action recommandée :

Assurez-vous de précréer des partitions afin que la charge de travail ne soit pas bloquée lorsqu'une nouvelle partition est nécessaire (par exemple, des partitions mensuelles) et que les anciennes partitions sont supprimées.
Assurez-vous de disposer d'un nombre suffisant d'aspirateurs automatiques pour effectuer l'entretien normal de nettoyage de toutes les cloisons.

Seuil approximatif : centaines

Fichiers temporaires

Contrairement aux tables temporaires mentionnées ci-dessus, les fichiers temporaires sont créés par PostgreSQL lorsqu'une requête complexe peut effectuer plusieurs opérations de tri ou de hachage en même temps, chaque opération utilisant la mémoire d'instance pour stocker les résultats jusqu'à la valeur spécifiée dans le paramètre. work_mem Lorsque la mémoire de l’instance n’est pas suffisante, des fichiers temporaires sont créés pour stocker les résultats. Voir Gestion des fichiers temporaires pour plus de détails sur les fichiers temporaires. Si votre charge de travail génère un grand nombre de ces fichiers, cela peut avoir plusieurs conséquences.

Conséquence : épuisement du descripteur de fichier

Action recommandée :

La réduction de la valeur du paramètre max_files_per_process peut contribuer à atténuer cette erreur. Chaque processus et sous-processus (par exemple, une requête parallèle) peut ouvrir ce nombre de fichiers, et si les requêtes joignent plusieurs tables, cette limite peut être dépassée.
Réduisez le nombre total de connexions et utilisez un pool de connexions tel qu'Amazon RDS Proxy ou d'autres solutions telles que. PgBouncer Pour en savoir plus, consultez le PgBouncer site Web.

Impact : épuisement des inodes

Bonnes pratiques générales :

Surveillez l'utilisation de vos fichiers temporaires avec Performance Insights .
Réglez les requêtes qui génèrent des fichiers temporaires importants pour voir s'il est possible de réduire le nombre total de fichiers temporaires.

Seuil approximatif : en milliers

Séquences

Les séquences sont l'objet sous-jacent utilisé pour l'auto-incrémentation des colonnes dans PostgreSQL. Elles fournissent l'unicité et une clé pour les données. Ils peuvent être utilisés sur des tables individuelles sans aucune conséquence lors des opérations normales, à l'exception de la réplication logique.

Dans PostgreSQL, la réplication logique ne réplique actuellement la valeur actuelle d'une séquence vers aucun abonné. Pour en savoir plus, consultez la page Restrictions de la documentation de PostgreSQL.

Conséquence : délai de transition prolongé

Si vous envisagez d'utiliser les Blue/Green déploiements d'Amazon RDS pour tout type de modification ou de mise à niveau de configuration, il est important de comprendre l'impact d'un grand nombre de séquences sur le passage au numérique. L'une des dernières phases d'une commutation synchronisera la valeur actuelle des séquences, et s'il y en a plusieurs milliers, cela augmentera le temps global de commutation.

Action recommandée : Si la charge de travail de votre base de données autorisait l'utilisation d'un UUID partagé au lieu d'une sequence-per-table approche, cela réduirait l'étape de synchronisation lors d'un basculement.

Seuil approximatif : en milliers

Objets volumineux

Les objets de grande taille sont stockés dans une seule table système nommée pg_largeobject. Chaque objet de grande taille possède également une entrée dans la table système pg_largeobject_metadata. Ces objets sont créés, modifiés et nettoyés de manière très différente des relations standard. Les objets volumineux ne sont pas manipulés par autovacuum et doivent être nettoyés périodiquement via un processus distinct appelé vacuumlo. Voir gestion d'objets volumineux avec le module lo pour des exemples de gestion d'objets de grande taille.

Conséquence : réplication logique: Les objets volumineux ne sont actuellement pas répliqués dans PostgreSQL lors de la réplication logique. Pour en savoir plus, consultez la page Restrictions de la documentation de PostgreSQL. Dans une configuration bleu/vert , cela signifie que les objets volumineux de l'environnement bleu ne sont pas répliqués dans l'environnement vert.
Conséquence : mise à niveau de la version majeure: Une mise à niveau peut manquer de mémoire et échouer s'il existe des millions d'objets volumineux et que l'instance ne peut pas les gérer pendant une mise à niveau. Le processus de mise à niveau de la version majeure de PostgreSQL comprend deux grandes phases : le vidage du schéma via pg_dump et sa restauration via pg_restore. Si votre base de données contient des millions d'objets volumineux, vous devez vous assurer que votre instance dispose de suffisamment de mémoire pour gérer les fichiers pg_dump et pg_restore lors d'une mise à niveau et pour les adapter à un type d'instance plus important.

Bonnes pratiques générales :

Utilisez régulièrement l'utilitaire vacuumlo pour retirer tous les gros objets orphelins que vous pourriez avoir.
Envisagez d'utiliser le type de données BYTEA pour stocker vos objets volumineux dans la base de données.

Seuil approximatif : millions

Seuils approximatifs

Les seuils approximatifs mentionnés dans cette rubrique ne sont utilisés que pour fournir une estimation de la mesure dans laquelle une ressource donnée peut évoluer. Ils représentent la plage générale dans laquelle les impacts décrits sont les plus probables, mais le comportement réel dépend de votre charge de travail, de la taille de l'instance et de la configuration spécifiques. Bien qu'il soit possible de dépasser ces estimations, le soin et l'entretien doivent être respectés afin d'éviter les impacts énumérés.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Explication des messages NOTICE

Gestion de la contention des OID TOAST