Va UUID comme clé primaire dans PostgreSQL donnent le mauvais rendement de l'indice?

Question

J'ai créé une application dans les Rails sur Heroku à l'aide d'une base de données PostgreSQL.

Il a un couple de tableaux conçus pour être en mesure de les synchroniser avec des appareils mobiles, où les données peuvent être créés sur des lieux différents. À cet effet, j'ai un uuid champ est une chaîne de caractères stockant un GUID en plus d'un incrément automatique de la clé primaire. L'uuid est celui qui est à communiquer entre le serveur et les clients.

J'ai réalisé après la mise en œuvre du moteur de synchronisation côté serveur que cela conduit à des problèmes de performances lors avoir besoin de la carte entre les uuid<->id de tous les temps (lors de l'écriture des objets, j'ai besoin de la requête pour l'uuid pour obtenir l'id avant de l'enregistrer et à l'opposé lors de l'envoi des données).

Je suis maintenant à la réflexion sur le passage à l'utilisation d'UUID en clé primaire, ce qui rend l'écriture et de la lecture de beaucoup plus simple et plus rapide.

J'ai lu que UUID comme clé primaire peut parfois donner le mauvais rendement de l'indice (indice de fragmentation) lors de l'utilisation de cluster index de clé primaire. PostgreSQL souffrent de ce problème ou est-ce OK pour utiliser les UUID comme clé primaire?

J'ai déjà un UUID aujourd'hui, la colonne afin de stockage sage, il sera mieux parce que je baisse régulière de l'id de la colonne.

Answer 1

(Je travaille sur Heroku Postgres)

Nous utilisons des Uuid comme clés primaires sur quelques systèmes et il fonctionne très bien.

Je vous recommande d'utiliser l' uuid-ossp extension, et ont même postgres générer des Uuid pour vous:

heroku pg:psql
psql (9.1.4, server 9.1.6)
SSL connection (cipher: DHE-RSA-AES256-SHA, bits: 256)
Type "help" for help.

dcvgo3fvfmbl44=> CREATE EXTENSION "uuid-ossp"; 
CREATE EXTENSION  
dcvgo3fvfmbl44=> CREATE TABLE test (id uuid primary key default uuid_generate_v4(), name text);  
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "test_pkey" for table "test"
CREATE TABLE  
dcvgo3fvfmbl44=> \d test
                 Table "public.test"  
Column | Type |              Modifiers              
--------+------+-------------------------------------  
id     | uuid | not null default uuid_generate_v4()  name   | text |  
Indexes:
    "test_pkey" PRIMARY KEY, btree (id)

dcvgo3fvfmbl44=> insert into test (name) values ('hgmnz'); 
INSERT 0 1 
dcvgo3fvfmbl44=> select * from test;
                  id                  | name  
--------------------------------------+-------   
 e535d271-91be-4291-832f-f7883a2d374f | hgmnz  
(1 row)

MODIFIER les conséquences de performance

Il va toujours dépendre de votre charge de travail.

L'entier de la clé primaire a l'avantage de la localité où l'instar de données se trouve plus près ensemble. Cela peut être utile pour par exemple: type de plage à des requêtes WHERE id between 1 and 10000 bien que le verrouillage est pire.

Si votre lecture de la charge de travail est totalement aléatoire dans que vous faites toujours de la clé primaire recherches, il ne devrait pas être mesurables dégradation de la performance: vous ne payez que pour le plus grand type de données.

Ne vous écris beaucoup pour ce tableau, et est ce tableau très grand? Il est possible, bien que je n'ai pas mesuré, qu'il y a des implications dans le maintien de l'indice. Pour beaucoup de jeux de données Uuid sont juste très bien cependant, et en l'utilisant comme des identificateurs Uuid a quelques belles propriétés.

Enfin, j'ai peut-être pas la personne la plus qualifiée pour discuter ou des conseils sur ce, comme je n'ai jamais couru une table assez grande avec un UUID PK où il est devenu un problème. YMMV. (Cela dit, j'aimerais entendre des personnes qui rencontrent des problèmes avec l'approche!)