Performance de PostgreSQL avec uuid comme clé primaire

Bonjour,

Je suis un tout nouveau utilisateur de PostgreSQL. Et j'aimerais savoir si le fait d'utiliser des UUID comme clé primaire peut poser des soucis de performances.
Nous avons à l'heure actuelle beaucoup de clusters MySQL, et de gros soucis de performances avec le stockage des données sous cette forme (c'est surtout en écriture).

J'aimerais savoir si des personnes utilisent des UUID sur de très grosses bases de données PostgreSQL et si les performances ne sont pas altérées.

C'est vrai quelque soit le SGBDR !
L'usage des UUID ou GUID est à proscrire en tant que clef primaire à la fois pour des raisons de performance et de sécurité (dans certaines release d'OS)

En effet un UUID c'est 16 octets nécessitant au minimum 2 passes dans le processeur afin de lire les valeurs, là une une clef de type BIGINT (64 bits) n'en fait qu'une...

En sus le calcul des UUID nécessite d'utiliser la même routine pour toutes les tables (et même pour les autres programmes) ce qui constitue un "hot spot". En effet, la génération des UUID est basé sur une lecture de la carte réseau du PC. C'est donc le même bout de code système qui est appelé pour toutes voas tables et pour d'autres applications....

De plus l'utilisation des UUID, fournissant par nature des valeurs aléatoires, fragmente terriblement les tables et les index. Or en cette matière PG est assez mauvais (VACUUM, REINDEX...) et ces routines provoquent souvent de nombreux verrous mortels.

De plus le tri des UUID (nécessaire pour les index des clefs praires) ne répond pas à une logique triviale....

Pour toutes ces raisons, il est totalement contre performant d'utiliser ce type de données, destinées à identifier des objets dans des systèmes répartis ce qui n'est pas le cas des clefs primaires des tables.

Il y a 10 ans, ayant fait un audit pour la COTOREP nous avions signalé cette utilisation imbécile du GUID et obligé l'éditeur à revoir entièrement la conception de sa base de données tellement cela posait de nombreux problèmes...

A +

Malheureusement l'architecture a été conçue comme ceci, je n'aurais pas fait ce choix personnellement.

De ce que j'ai pu voir sur les discussions de GitHub il devrait normalement pas y avoir de soucis, car PostgreSQL stocke les données d'une autre manière.
MySQL lui utilise les clés primaires pour sauvegarder les tables sur le disque dur .

Je vais faire des tests d'écriture avec PostgreSQL en important une partie de la base de données (~500 Go).
Espérons que tout se passera bien, je ferai un retour des performances.

Bon les testes d'écritures sont une réussite ! Reste plus qu'à migrer le tout :(