Forum du club des développeurs et IT Pro - PostgreSQL https://www.developpez.net/forums/ F.A.Q PostGreSQL Tutoriels PostGreSQL]]> fr Mon, 19 Oct 2026 18:07:44 GMT vBulletin 15 https://forum.developpez.be/images/misc/rss.png Forum du club des développeurs et IT Pro - PostgreSQL https://www.developpez.net/forums/ PostgreSQL 19 est disponible en version bêta avec de nombreuses nouvelles fonctionnalités et améliorations https://www.developpez.net/forums/showthread.php?t=2185541&goto=newpost Tue, 08 Sep 2026 14:45:22 GMT *PostgreSQL 19, la dernière... PostgreSQL 19, la dernière version de la base de données open source, est disponible en version bêta avec de nombreuses nouvelles fonctionnalités et améliorations

PostgreSQL 19 est désormais disponible en version bêta et propose de nombreuses nouvelles fonctionnalités et améliorations. Cette version inclut notamment la prise en charge des requêtes sur les graphes de propriétés (SQL/PGQ), une nouvelle commande REPACK permettant de libérer efficacement de l'espace disque et des capacités de réplication logique améliorées. Elle offre également de meilleures performances dans de nombreux domaines, comme les vérifications des clés étrangères et la mise à l'échelle automatique du nombre de processus de travail d'E/S, et apporte de nouvelles optimisations au niveau de la planification et de l'exécution.

Une base de données relationnelle est une base de données fondée sur le modèle relationnel des données, tel que proposé par E. F. Codd en 1970. Un système de gestion de bases de données relationnelles (SGBDR) est un type de système de gestion de bases de données qui stocke les données sous un format structuré, à l'aide de lignes et de colonnes. De nombreux SGBDR offrent la possibilité d'utiliser le langage SQL (Structured Query Language) pour interroger et mettre à jour la base de données.

PostgreSQL, également connu sous le nom de Postgres, est un SGBDR libre et open source qui met l'accent sur l'extensibilité et la conformité au langage SQL. PostgreSQL prend en charge les transactions présentant les propriétés d'atomicité, de cohérence, d'isolation et de durabilité (ACID), ainsi que les vues mises à jour automatiquement, les vues matérialisées, les déclencheurs, les clés étrangères et les procédures stockées. Il est pris en charge sur tous les principaux systèmes d'exploitation et gère une large gamme de charges de travail, allant des machines individuelles aux entrepôts de données, en passant par les lacs de données ou les services web accueillant de nombreux utilisateurs simultanés.


PostgreSQL 19 est actuellement en version bêta et propose un large éventail de fonctionnalités de base de données ainsi que des améliorations en termes de performances.

Cette version prend en charge les requêtes sur les graphes de propriétés (SQL/PGQ). Elle apporte également une nouvelle commande REPACK qui libère de l'espace disque et réorganise le contenu des tables, en combinant les fonctionnalités des commandes existantes VACUUM FULL et CLUSTER. Son option CONCURRENTLY permet notamment d'effectuer le recompressage sans bloquer les opérations de lecture et d'écriture sur la table.

La réplication logique réplique désormais les valeurs de séquence et peut être activée sans redémarrage du serveur lorsque le paramètre wal_level est défini sur replica. L'autovacuum peut désormais utiliser des processus de travail parallèles pour nettoyer les index d'une table et un nouveau système de notation attribue la priorité aux tables qui ont le plus besoin d'être nettoyées ou analysées.


Cette version de PostgreSQL permet d'activer ou de désactiver les checksums de données pendant que le serveur de base de données est en cours d'exécution. Une nouvelle commande, WAIT FOR, qui attend qu'un serveur de secours ait répercuté les modifications jusqu'à un point donné, est disponible. Elle permet de prendre en charge les modèles de requêtes de type « read-your-writes » sur les serveurs de secours.

Par ailleurs, PostgreSQL prend désormais en charge les mises à jour et les suppressions des données temporelles via la nouvelle clause FOR PORTION OF. Une nouvelle extension pg_plan_advice permettant de stabiliser et de contrôler les décisions du planificateur de requêtes, ainsi qu'une extension complémentaire, pg_stash_advice, qui applique automatiquement ces conseils en fonction de la requête, sont également disponibles.

Finalement, PostgreSQL 19 offre de meilleures performances dans de nombreux domaines, notamment la mise à l'échelle automatique du nombre de processus de travail d'E/S, des vérifications plus rapides des clés étrangères, ainsi que de nouvelles optimisations au niveau de la planification et de l'exécution.

Source : Notes de mise à jour de PostgreSQL 19 Beta

Et vous ?

:fleche: Quel est votre avis sur le sujet ?
:fleche: Que pensez-vous des nouveautés proposées par cette version de PostgreSQL ? Les trouvez-vous utiles et intéressantes ?

Voir aussi :

:fleche: PostgreSQL 18 est disponible, la dernière version de la base de données open source apporte un sous-système d'entrée/sortie asynchrone, des améliorations de performances et la prise en charge d'OAuth

:fleche: PostgreSQL 17 est disponible avec une nouvelle structure de mémoire interne et des améliorations de performance

:fleche: Mise à l'échelle de PostgreSQL pour prendre en charge 800 millions d'utilisateurs ChatGPT, par Bohan Zhang ]]> PostgreSQL Anthony https://www.developpez.net/forums/d2185541/bases-donnees/postgresql/postgresql-19-disponible-version-beta-nombreuses-nouvelles-fonctionnalites-ameliorations/ Problème PostgreS avec Windows 11 24H2 https://www.developpez.net/forums/showthread.php?t=2182994&goto=newpost Thu, 02 Apr 2026 13:28:05 GMT Bonjour

J'ai installé postgresql 18 sous windows 11 normal, tout marchait bien pgadmin s'ouvrait rapidement, mais une fois que la mise à jour WINDOWS 24H2 a été installée, rien ne fonctionnait plus, pgadmin restait planté, et j'ai même essayé de me connecter à la BDD via DBeaver, mais sans succès.
Alors j'ai desactivé le firewall, l'antivirus, j'ai ouvert le port 5432 dans le firewall, windows defender, ... etc , j'ai même changé de port, rien ne fonctionne.

J'ai désinstallé la mise à jour 24H2, et tout est à nouveau fonctionnel (pgadmin et même DBeaver),

c'est quoi le problème de cette mise à jour? ]]> PostgreSQL scholes https://www.developpez.net/forums/d2182994/bases-donnees/postgresql/probleme-postgres-windows-11-24h2/ Débuter avec Pgbench https://www.developpez.net/forums/showthread.php?t=2182671&goto=newpost Mon, 16 Mar 2026 13:29:52 GMT bonjour, Je suis perdu... bonjour,

Je suis perdu pour utiliser pgbench ?
On trouve des tuto, mais c'est des lignes de commandes et souvent c'est pour des install sur Linux

Je ne connais que Pgadmin, j'ai ouvert l'outil PSQL et je tape pgbench -i nom_base, pour créér les tables, mais il ne se passe rien ?


Cordialement ]]> PostgreSQL looping https://www.developpez.net/forums/d2182671/bases-donnees/postgresql/debuter-pgbench/ <![CDATA[Mise à l'échelle de PostgreSQL pour prendre en charge 800 millions d'utilisateurs ChatGPT]]> https://www.developpez.net/forums/showthread.php?t=2181748&goto=newpost Tue, 27 Jan 2026 09:53:28 GMT Mise à l'échelle de PostgreSQL pour prendre en charge 800 millions d'utilisateurs ChatGPT, par Bohan Zhang

PostgreSQL, également connu sous le nom de Postgres, est un système de gestion de base de données relationnelle (SGBDR) libre et open source qui met l'accent sur l'extensibilité et la conformité SQL. PostgreSQL offre des transactions avec des propriétés d'atomicité, de cohérence, d'isolation et de durabilité (ACID), des vues automatiquement actualisables, des vues matérialisées, des déclencheurs, des clés étrangères et des procédures stockées. Il est pris en charge par tous les principaux systèmes d'exploitation, notamment Windows, Linux, macOS, FreeBSD et OpenBSD, et gère toute une gamme de charges de travail, des machines individuelles aux entrepôts de données, aux lacs de données ou aux services web avec de nombreux utilisateurs simultanés.

ChatGPT est un chatbot génératif basé sur l'intelligence artificielle développé par OpenAI. Il a été lancé en novembre 2022. Il utilise des transformateurs génératifs pré-entraînés (GPT), tels que GPT-5, pour générer du texte, de la parole et des images en réponse aux demandes des utilisateurs. OpenAI exploite le service selon un modèle freemium. Les utilisateurs peuvent interagir avec ChatGPT par le biais de requêtes textuelles, audio et visuelles. Le service a gagné 100 millions d'utilisateurs en deux mois, ce qui en fait l'application logicielle grand public à la croissance la plus rapide de l'histoire. Le site web de ChatGPT figure parmi les 5 sites web les plus visités au monde.

Depuis des années, PostgreSQL est l'un des systèmes de données les plus critiques et les plus discrets qui alimentent des produits phares tels que ChatGPT et l'API d'OpenAI. À mesure que notre base d'utilisateurs s'est rapidement développée, les exigences imposées à nos bases de données ont également augmenté de manière exponentielle. Au cours de l'année dernière, notre charge PostgreSQL a été multipliée par plus de 10 et continue d'augmenter rapidement.

Nos efforts pour faire évoluer notre infrastructure de production afin de soutenir cette croissance ont révélé une nouvelle perspective : PostgreSQL peut être mis à l'échelle pour prendre en charge de manière fiable des charges de travail beaucoup plus importantes que ce que beaucoup pensaient possible auparavant. Ce système (initialement créé par une équipe de scientifiques de l'université de Californie à Berkeley) nous a permis de prendre en charge un trafic mondial massif avec une seule instance de serveur flexible Azure PostgreSQL primaire⁠ et près de 50 répliques en lecture réparties dans plusieurs régions du monde. Voici comment nous avons évolué PostgreSQL chez OpenAI afin de prendre en charge des millions de requêtes par seconde pour 800 millions d'utilisateurs grâce à des optimisations rigoureuses et une ingénierie solide. Nous aborderons également les principaux enseignements que nous avons tirés au cours de ce processus.

Les failles de notre conception initiale

Après le lancement de ChatGPT, le trafic a augmenté à un rythme sans précédent. Pour y faire face, nous avons rapidement mis en œuvre des optimisations approfondies au niveau des couches applicatives et de la base de données PostgreSQL, augmenté la taille des instances et ajouté des répliques en lecture. Cette architecture nous a bien servi pendant longtemps. Grâce à des améliorations continues, elle continue d'offrir une marge de manœuvre suffisante pour la croissance future.

Il peut sembler surprenant qu'une architecture à primaire unique puisse répondre aux exigences d'OpenAI en termes d'échelle, mais la mise en œuvre pratique n'est pas simple. Nous avons constaté plusieurs SEV causés par une surcharge de Postgres, qui suivent souvent le même schéma : un problème en amont provoque une augmentation soudaine de la charge de la base de données, comme des échecs de cache généralisés dus à une défaillance de la couche de mise en cache, une augmentation des jointures multivoies coûteuses saturant le CPU ou une tempête d'écritures due au lancement d'une nouvelle fonctionnalité. À mesure que l'utilisation des ressources augmente, la latence des requêtes augmente et les demandes commencent à expirer. Les nouvelles tentatives amplifient alors encore la charge, déclenchant un cercle vicieux susceptible de dégrader l'ensemble des services ChatGPT et API.

Nom : 1.jpg Affichages : 51469 Taille : 55,3 Ko

Bien que PostgreSQL s'adapte bien à nos charges de travail à forte intensité de lecture, nous rencontrons encore des difficultés pendant les périodes de trafic d'écriture élevé. Cela est principalement dû à la mise en œuvre du contrôle de concurrence multiversion (MVCC) de PostgreSQL, qui le rend moins efficace pour les charges de travail à forte intensité d'écriture. Par exemple, lorsqu'une requête met à jour un tuple ou même un seul champ, la ligne entière est copiée pour créer une nouvelle version. Sous des charges d'écriture importantes, cela entraîne une amplification significative de l'écriture. Cela augmente également l'amplification de la lecture, car les requêtes doivent parcourir plusieurs versions de tuples (tuples morts) pour récupérer la dernière. Le MVCC introduit des défis supplémentaires tels que le gonflement des tables et des index, l'augmentation des frais généraux de maintenance des index et le réglage complexe de l'autovacuum. (Vous trouverez une analyse approfondie de ces questions dans un blog que j'ai rédigé avec le professeur Andy Pavlo de l'université Carnegie Mellon, intitulé « The Part of PostgreSQL We Hate the Most » (La partie de PostgreSQL que nous détestons le plus), cité dans la page Wikipédia consacrée à PostgreSQL.

Faire évoluer PostgreSQL à des millions de QPS

Pour atténuer ces limitations et réduire la pression d'écriture, nous avons migré, et continuons à migrer, les charges de travail fragmentables (c'est-à-dire celles qui peuvent être partitionnées horizontalement) et à forte intensité d'écriture vers des systèmes fragmentés tels qu'Azure Cosmos DB, en optimisant la logique des applications afin de minimiser les écritures inutiles. Nous n'autorisons également plus l'ajout de nouvelles tables au déploiement PostgreSQL actuel. Les nouvelles charges de travail sont par défaut transférées vers les systèmes fragmentés.

Même si notre infrastructure a évolué, PostgreSQL est resté non fragmenté, avec une seule instance principale servant toutes les écritures. La raison principale est que la fragmentation des charges de travail des applications existantes serait très complexe et prendrait beaucoup de temps, nécessitant des modifications sur des centaines de points de terminaison d'applications et pouvant prendre des mois, voire des années. Comme nos charges de travail sont principalement lourdes en lecture et que nous avons mis en œuvre des optimisations importantes, l'architecture actuelle offre encore une marge suffisante pour soutenir la croissance continue du trafic. Bien que nous n'excluions pas le partitionnement de PostgreSQL à l'avenir, ce n'est pas une priorité à court terme étant donné que nous disposons d'une marge de manœuvre suffisante pour notre croissance actuelle et future.

Dans les sections suivantes, nous aborderons les défis auxquels nous avons été confrontés et les optimisations importantes que nous avons mises en œuvre pour y faire face et prévenir de futures pannes, en poussant PostgreSQL à ses limites et en le faisant évoluer à des millions de requêtes par seconde (QPS).

Réduire la charge sur le primaire

Défi : avec un seul rédacteur, une configuration à primaire unique ne peut pas faire évoluer les écritures. Les pics d'écriture importants peuvent rapidement surcharger le primaire et avoir un impact sur des services tels que ChatGPT et notre API.

Solution : nous minimisons autant que possible la charge sur le primaire, tant en lecture qu'en écriture, afin de nous assurer qu'il dispose d'une capacité suffisante pour gérer les pics d'écriture. Le trafic de lecture est déchargé vers des répliques dans la mesure du possible. Cependant, certaines requêtes de lecture doivent rester sur le primaire car elles font partie de transactions d'écriture. Pour celles-ci, nous nous efforçons de garantir leur efficacité et d'éviter les requêtes lentes. Pour le trafic d'écriture, nous avons migré les charges de travail fragmentables et à forte intensité d'écriture vers des systèmes fragmentés tels qu'Azure CosmosDB. Les charges de travail plus difficiles à fragmenter mais qui génèrent néanmoins un volume d'écriture élevé prennent plus de temps à migrer, et ce processus est toujours en cours. Nous avons également optimisé de manière agressive nos applications afin de réduire la charge d'écriture. Par exemple, nous avons corrigé les bogues d'application qui provoquaient des écritures redondantes et avons introduit des écritures différées, lorsque cela était approprié, afin de lisser les pics de trafic. De plus, lors du remplissage des champs des tables, nous appliquons des limites de débit strictes afin d'éviter une pression excessive sur l'écriture.

Optimisation des requêtes

Défi : nous avons identifié plusieurs requêtes coûteuses dans PostgreSQL. Dans le passé, les pics de volume soudains de ces requêtes consommaient d'importantes quantités de CPU, ralentissant à la fois ChatGPT et les requêtes API.

Solution : quelques requêtes coûteuses, telles que celles qui joignent plusieurs tables, peuvent dégrader considérablement, voire paralyser l'ensemble du service. Nous devons optimiser en permanence les requêtes PostgreSQL afin de garantir leur efficacité et d'éviter les anti-modèles courants du traitement des transactions en ligne (OLTP). Par exemple, nous avons déjà identifié une requête extrêmement coûteuse qui joignait 12 tables, dont les pics étaient responsables de SEV de haute gravité dans le passé. Nous devons éviter autant que possible les jointures complexes entre plusieurs tables. Si des jointures sont nécessaires, nous avons appris à envisager de décomposer la requête et de déplacer la logique de jointure complexe vers la couche application. Bon nombre de ces requêtes problématiques sont générées par des frameworks de mappage objet-relationnel (ORM). Il est donc important d'examiner attentivement le code SQL qu'ils produisent et de s'assurer qu'il se comporte comme prévu. Il est également courant de trouver des requêtes inactives de longue durée dans PostgreSQL. La configuration de délais d'expiration tels que idle_in_transaction_session_timeout est essentielle pour éviter qu'elles ne bloquent l'autovacuum.

Atténuation du point de défaillance unique

Défi : si une réplique en lecture tombe en panne, le trafic peut toujours être acheminé vers d'autres répliques. Cependant, le fait de s'appuyer sur un seul rédacteur signifie qu'il existe un point de défaillance unique : s'il tombe en panne, l'ensemble du service est affecté.

Solution : la plupart des requêtes critiques ne concernent que des requêtes de lecture. Pour atténuer le point de défaillance unique dans le primaire, nous avons déchargé ces lectures du rédacteur vers les répliques, garantissant ainsi que ces requêtes puissent continuer à être traitées même si le primaire tombe en panne. Bien que les opérations d'écriture échouent toujours, l'impact est réduit ; il ne s'agit plus d'un SEV0 puisque les lectures restent disponibles.

Pour atténuer les pannes du serveur principal, nous l'exécutons en mode haute disponibilité (HA) avec une réplique de secours active, une réplique synchronisée en continu qui est toujours prête à prendre le relais pour traiter le trafic. Si le serveur principal tombe en panne ou doit être mis hors ligne pour maintenance, nous pouvons rapidement promouvoir la réplique de secours afin de minimiser le temps d'indisponibilité. L'équipe Azure PostgreSQL a accompli un travail considérable pour garantir la sécurité et la fiabilité de ces basculements, même en cas de charge très élevée. Pour gérer les pannes de répliques en lecture, nous déployons plusieurs répliques dans chaque région avec une marge de capacité suffisante, afin de garantir qu'une seule panne de réplique n'entraîne pas une panne régionale.

Isolation des charges de travail

Défi : nous sommes souvent confrontés à des situations où certaines requêtes consomment une quantité disproportionnée de ressources sur les instances PostgreSQL. Cela peut entraîner une dégradation des performances des autres charges de travail exécutées sur les mêmes instances. Par exemple, le lancement d'une nouvelle fonctionnalité peut introduire des requêtes inefficaces qui consomment beaucoup de CPU PostgreSQL, ralentissant ainsi les requêtes pour d'autres fonctionnalités critiques.

Solution : pour atténuer le problème du « voisin bruyant », nous isolons les charges de travail sur des instances dédiées afin de garantir que les pics soudains de requêtes gourmandes en ressources n'aient pas d'impact sur le reste du trafic. Plus précisément, nous divisons les requêtes en niveaux de priorité faible et élevée, puis les acheminons vers des instances distinctes. De cette façon, même si une charge de travail à faible priorité devient gourmande en ressources, elle ne dégradera pas les performances des requêtes à haute priorité. Nous appliquons la même stratégie à différents produits et services, afin que l'activité d'un produit n'affecte pas les performances ou la fiabilité d'un autre.

Mise en commun des connexions

Défi : chaque instance a une limite maximale de connexions (5 000 dans Azure PostgreSQL). Il est facile d'épuiser les connexions ou d'accumuler trop de connexions inactives. Nous avons déjà connu des incidents causés par des tempêtes de connexions qui ont épuisé toutes les connexions disponibles.

Solution : nous avons déployé PgBouncer comme couche proxy pour mettre en pool les connexions à la base de données. Son exécution en mode de mise en pool des instructions ou des transactions nous permet de réutiliser efficacement les connexions, ce qui réduit considérablement le nombre de connexions client actives. Cela réduit également la latence de configuration des connexions : dans nos benchmarks, le temps de connexion moyen est passé de 50 millisecondes (ms) à 5 ms. Les connexions et les requêtes interrégionales peuvent être coûteuses, c'est pourquoi nous regroupons le proxy, les clients et les répliques dans la même région afin de minimiser la charge réseau et le temps d'utilisation des connexions. De plus, PgBouncer doit être configuré avec soin. Des paramètres tels que les délais d'inactivité sont essentiels pour éviter l'épuisement des connexions.

Nom : 2.jpg Affichages : 3423 Taille : 86,1 Ko

Chaque réplique en lecture dispose de son propre déploiement Kubernetes exécutant plusieurs pods PgBouncer. Nous exécutons plusieurs déploiements Kubernetes derrière le même service Kubernetes, qui équilibre la charge du trafic entre les pods.

Mise en cache

Défi : une augmentation soudaine des échecs de cache peut déclencher une surge de lectures sur la base de données PostgreSQL, saturant le CPU et ralentissant les requêtes des utilisateurs.

Solution : pour réduire la pression de lecture sur PostgreSQL, nous utilisons une couche de mise en cache pour traiter la plupart du trafic de lecture. Cependant, lorsque les taux de réussite du cache chutent de manière inattendue, la vague de cache misses peut envoyer un volume important de requêtes directement à PostgreSQL. Cette augmentation soudaine des lectures de la base de données consomme des ressources importantes, ce qui ralentit le service. Pour éviter la surcharge lors des tempêtes de cache manqué, nous mettons en œuvre un mécanisme de verrouillage (et de location) du cache afin que seul un lecteur qui manque une clé particulière récupère les données de PostgreSQL. Lorsque plusieurs requêtes manquent la même clé de cache, une seule requête acquiert le verrou et procède à la récupération des données et au remplissage du cache. Toutes les autres requêtes attendent que le cache soit mis à jour plutôt que d'atteindre PostgreSQL en même temps. Cela réduit considérablement les lectures redondantes de la base de données et protège le système contre les pics de charge en cascade.

Mise à l'échelle des répliques de lecture

Défi : le primaire transmet les données du journal d'écriture préalable (WAL) à chaque réplique de lecture. À mesure que le nombre de répliques augmente, le primaire doit envoyer le WAL à davantage d'instances, ce qui augmente la pression sur la bande passante du réseau et le CPU. Cela entraîne un décalage plus important et plus instable des répliques, ce qui rend le système plus difficile à mettre à l'échelle de manière fiable.

Solution : nous exploitons près de 50 répliques de lecture dans plusieurs régions géographiques afin de minimiser la latence. Cependant, avec l'architecture actuelle, le primaire doit diffuser le WAL vers chaque réplique. Bien qu'il s'adapte actuellement bien aux très grands types d'instances et à une bande passante réseau élevée, nous ne pouvons pas continuer à ajouter indéfiniment des répliques sans finir par surcharger le primaire. Pour remédier à cela, nous collaborons avec l'équipe Azure PostgreSQL sur la réplication en cascade⁠(s'ouvre dans une nouvelle fenêtre), où les répliques intermédiaires relaient le WAL vers les répliques en aval. Cette approche nous permet d'évoluer vers plus d'une centaine de répliques sans surcharger le serveur principal. Cependant, elle introduit également une complexité opérationnelle supplémentaire, en particulier en ce qui concerne la gestion des basculements. Cette fonctionnalité est encore en phase de test ; nous nous assurerons qu'elle est robuste et qu'elle peut basculer en toute sécurité avant de la déployer en production.

Nom : 3.jpg Affichages : 3396 Taille : 35,3 Ko

Limite de débit

Défi : une augmentation soudaine du trafic sur des points de terminaison spécifiques, une recrudescence de requêtes coûteuses ou une avalanche de tentatives de reconnexion peuvent rapidement épuiser les ressources critiques telles que le CPU, les E/S et les connexions, ce qui entraîne une dégradation généralisée du service.

Solution : nous avons mis en place une limitation du débit à plusieurs niveaux (application, pool de connexions, proxy et requêtes) afin d'éviter que des pics de trafic soudains ne saturent les instances de base de données et ne déclenchent des défaillances en cascade. Il est également essentiel d'éviter des intervalles de réessai trop courts, qui peuvent déclencher des tempêtes de réessais. Nous avons également amélioré la couche ORM afin de prendre en charge la limitation du débit et, si nécessaire, de bloquer complètement certains résumés de requêtes. Cette forme ciblée de délestage permet une récupération rapide après des pics soudains de requêtes coûteuses.

Gestion des schémas

Défi : même une petite modification du schéma, telle que la modification du type d'une colonne, peut déclencher une réécriture complète de la table⁠. Nous appliquons donc les modifications de schéma avec prudence, en les limitant à des opérations légères et en évitant celles qui réécrivent des tables entières.

Solution : seules les modifications légères du schéma sont autorisées, telles que l'ajout ou la suppression de certaines colonnes qui ne déclenchent pas une réécriture complète de la table. Nous appliquons un délai d'expiration strict de 5 secondes pour les modifications de schéma. La création et la suppression simultanées d'index sont autorisées. Les modifications de schéma sont limitées aux tables existantes. Si une nouvelle fonctionnalité nécessite des tables supplémentaires, celles-ci doivent se trouver dans des systèmes fragmentés alternatifs tels qu'Azure CosmosDB plutôt que PostgreSQL. Lors du remplissage d'un champ de table, nous appliquons des limites de débit strictes afin d'éviter les pics d'écriture. Bien que ce processus puisse parfois prendre plus d'une semaine, il garantit la stabilité et évite tout impact sur la production.

Résultats et perspectives

Cet effort démontre qu'avec une conception et des optimisations appropriées, Azure PostgreSQL peut être mis à l'échelle pour gérer les charges de travail de production les plus importantes. PostgreSQL gère des millions de QPS pour les charges de travail à forte intensité de lecture, alimentant les produits les plus critiques d'OpenAI tels que ChatGPT et la plateforme API. Nous avons ajouté près de 50 répliques en lecture, tout en maintenant le décalage de réplication proche de zéro, en conservant des lectures à faible latence dans les régions géographiquement distribuées et en créant une marge de capacité suffisante pour soutenir la croissance future.

Cette mise à l'échelle fonctionne tout en minimisant la latence et en améliorant la fiabilité. Nous offrons en permanence une latence côté client de l'ordre de quelques millisecondes (p99) et une disponibilité de 99,999 % en production. Au cours des 12 derniers mois, nous n'avons connu qu'un seul incident SEV-0 PostgreSQL (il s'est produit lors du lancement viral⁠ de ChatGPT ImageGen, lorsque le trafic d'écriture a soudainement été multiplié par plus de 10, plus de 100 millions de nouveaux utilisateurs s'étant inscrits en une semaine).

Bien que nous soyons satisfaits des progrès réalisés grâce à PostgreSQL, nous continuons à repousser ses limites afin de nous assurer une marge de manœuvre suffisante pour notre croissance future. Nous avons déjà migré les charges de travail fragmentables à forte intensité d'écriture vers nos systèmes fragmentés tels que CosmosDB. Les charges de travail restantes à forte intensité d'écriture sont plus difficiles à fragmenter, mais nous les migrons également de manière active afin de décharger davantage le système principal PostgreSQL. Nous travaillons également avec Azure pour permettre la réplication en cascade afin de pouvoir évoluer en toute sécurité vers un nombre nettement plus important de répliques en lecture.

À l'avenir, nous continuerons à explorer d'autres approches pour évoluer davantage, notamment PostgreSQL fragmenté ou d'autres systèmes distribués, à mesure que les besoins de notre infrastructure continuent de croître.

Source : "Scaling PostgreSQL to power 800 million ChatGPT users"

Et vous ?

:fleche: Pensez-vous que ce rapport est crédible ou pertinent ?
:fleche: Quel est votre avis sur le sujet ?

Voir aussi :

:fleche: Le chatbot IA ChatGPT d'OpenAI était hors service, les utilisateurs ont signalé une panne mondiale, les conversations ont disparu. La panne était due à « une erreur de configuration du routage »

:fleche: Redéfinir la base de données pour l'IA : pourquoi MongoDB a acquis Voyage AI, par Dev Ittycheria, PDG de MongoDB

:fleche: Apprendre à raisonner avec le nouveau LLM OpenAI o1 formé avec l'apprentissage par renforcement pour effectuer des raisonnements complexes, car o1 réfléchit avant de répondre
Images attachées
   
]]> PostgreSQL Bohan Zhang https://www.developpez.net/forums/d2181748/bases-donnees/postgresql/mise-l-echelle-postgresql-prendre-charge-800-millions-d-utilisateurs-chatgpt/